suggested features for mlf 2.4 (Project organisation)

by glorifyday, Friday, October 07, 2016, 20:40 (2751 days ago) @ Auge

Hi, thanks for your extensive reply. Let me try to defend some points ;-)

There is a half-way-implemented (?) feature to store the information about the users last 200 read entries. I have no clue, in wich way it works or was intended to work...

As far as I observe the forum's behaviour, this works a bit inconsistently and depends on a browser. Let me suggest something, just as a wild idea to think of. You might not support the idea first, yet please give it a deeper thought.

First solution. Maybe not good for everyone (so it might be optional), but elegant and requires minimum coding and storing minimum information.
For each user you store only a timestamp (or alternatively just a few timestamps - one timestamp per category).
Posts that are older than the timestamp are rendered as read, the newer ones are rendered as unread.
The forum provides a toolbar button called "Mark all as read".
Clicking this button, user updates its timestamp (maybe category-based if a category is selected) to the current time. The button also re-renders the page, and all posts will be seen as read.

Second solution. Maybe a bit more flexible, but requires storing more data.
You store up to 200 timestamps per user. The 200 is for the 200 newest threads, not posts. The posts in the newest threads will be rendered read/unread basing on their thread's timestamp. The posts in the older threads will be rendered read/unead based on the maximum of all stored user's timestamps.
If one of the older threads receives a new post, it promotes to the list of 200 newest threads, degrading the current oldest one in the list.
The thread's timestamp gets increased when the user visits its posts (to the post creation time) or when the user opens the whole thread's view (to the current time).

This solution does not require to lock old threads. And in fact, I think that the arbitrary number of 200 can be significantly reduced without sacrificing the comfort of forum's use.

Anyway, I opt for the first solution. I was using a custom forum that behaved this way and it was very comfortable to use. Unluckily, this forum does not exist anymore, so I cannot show you how it behaved.

Possibility to show the bubbles on hover over the post title.

I'm not willing to support that. Yes, it saves one click per entry but on the other hand it can – and I'm convinced it will – lead to many faulty operations, when users move the mouse cursor, pass over the titles of entries and opens numerous preview bubbles unintentionally.

Before you say "no" permanently, please note that your current solution has already solved the problem. Notice that the old bubble disappears when the new is shown. The only change would consider the event that triggers showing the bubble. It seems that all the rest is already there and should work just perfect! It still might be an optional behaviour, in favour of the current forum users.

Attention: These are not the smilies you can insert into the entries body with the buttons!

Yes... that's exactly my point. This creates inconsistency. You write the subject and the body different, you see it different and it behaves different. Both entries might just as well behave the same and it would only increase flexibility, consistency and mean less if's in the code. Even hyperlinks inside subjects are possible (this part of the subject directs to a different href).

Thanks again, I hope I have convinced you in some way.

Please note that I don't want to encourage anybody to do the changes in the near future. I just wanted to share my visions, and this thread seemed a right place. Maybe some of the developers on our forum could actively contribute to your great work in the future, if you find it useful.

Best,
Glorifyday

locked
56380 views

Complete thread:

 RSS Feed of thread