This topic was marked solved by its starter, on April 1st, 2014, 08:07 PM
[Poll] Board status icons: what's the point?
Poll

Fix or remove the "unread" status?

Fix!
3 (17.6%)
Remove and replace with what you suggested!
13 (76.5%)
Remove everything!
1 (5.9%)
Total Members Voted: 14

Nao

  • Dadman with a boy
  • Posts: 16,079
[Poll] Re: Board status icons: what's the point?
« Reply #60, on April 4th, 2014, 11:53 PM »
'kay, I'll try #3 as an alternative for the current stuff.

Yes Farjo, just the pictures.

Regarding the feature, I've hit a wall, and I don't know what to do.
- Spending 0.15s to 0.3s per page doing that query is out of the question for me.
- I tried to optimize it. I failed.
- Then I decided I'd give a try to retrieving only the EXISTENCE of an unread message for every board, instead of the number of unread messages. That would be faster, wouldn't it..? Wrong. At best, I get the same performance. At worst, I "optimize" the query even more and I end up with a 0.4s query... Uh, uh.
- Unless someone can help with optimizing (@Pandos?), I have to give up on this one.
- So, I also tried to cache the results... Of course, it's super fast this way. However, I'd have to clear the cache every time either log_topics or log_mark_read tables are modified... *And* every time a new message is posted, of course. I suspect that Wedge would thus spend way more time invalidating the cache, than actually reading from it.
- Finally, the last alternative is to add a user setting, disabled by default (to help with performance). This is a bit of a cop-out, and doesn't have the same 'wow' factor.
- Oh yes, yet another alternative would be that I restore log_boards... Ah, ah! Just kidding. Not only is it too late, but I removed the table for a reason.
- Also the possibility of just removing the feature, at the cost of upsetting Johnny54. I've spent a couple of days on this, and I don't know what's worse to me... Spending another couple of days on it (with the risk that it fails to work), or just accepting that Wedge won't please everyone.

Please feel free to comment on any of the points I mentioned in this post. I'm at a complete loss, and honestly if I don't get feedback on this, I'm prepared to remove the feature without second thoughts.

Pandos

  • Living on the edge of Wedge
  • Posts: 635
# dpkg-reconfigure brain
error: brain is not installed or configured

[Poll] Re: Board status icons: what's the point?
« Reply #62, on April 5th, 2014, 10:58 AM »
No matter what you decide, I thank you for trying to implement something you already had discarded just to satisfy a few members.
If it can't be done in a normal way without to many consequences than it simply can't be done.
It's like you said. It's impossible to make something that pleases everybody.

Please allow one last stupid question on this.
There's already a list with all unread topics, complete with boardnames etc.
What makes it so hard to have a indication per board that the board has unread topics.
I'm not hindered with any knowledge of programming and would think that it's just a matter of looking in that list en put a mark somewhere.
Is that to time consuming, or is it more complicated than I think.
[Poll] Re: Board status icons: what's the point?
« Reply #63, on April 5th, 2014, 09:34 PM »
I know this not Wedge and It's only how I like things to appear, this is on my main site SMF. Just look see!

Not saying wedge should be like this, just saying I don't care for holding hands so to speak, I can't see where anyone would need anymore info than is there! :)
Screen below:

regards,
Maxx

 -BUILD-AND-TELL-Index 2014-04-05 14-17-23.png - 22.32 kB, 988x216, viewed 180 times.


Nao

  • Dadman with a boy
  • Posts: 16,079
[Poll] Re: Board status icons: what's the point?
« Reply #64, on April 6th, 2014, 12:22 AM »
Update is online here...

Can you spell "boring"?!

I don't know what you'll think. I'm not happy with it, personally. I do like the effect on the main menu, though. Also maybe on the notification popups. The rest... Not so much. Not enough visible on topic pages, not enough on unread counters either.

Please share opinions.
Or, even better, screenshots of how you think it could be improved!

Note: I've reached the 100-day milestone on github's "longest streak", and as I promised myself I wouldn't go beyond that (I only kept committing everyday because I didn't want to end my longest streak on an unlucky number, but above 100 means I'd have to do that every six months, err, don't bother), I probably won't commit anything tomorrow. Or, if I do, I'll try to rewrite history so that it shows as from the day before... :P
Posted: April 6th, 2014, 12:08 AM
Quote from Pandos on April 4th, 2014, 11:58 PM
@Nao:
I'll take a look into it.
But not before Monday. Hope this is OK for you.
Well, I gave up yesterday, so you're my only hope at this point. :lol:

Honestly, I'd be happy with just a quick query that finds at least one unread post in every board, and stops after that. But I don't think it'll work in making the query faster.

Right now, here's what the query does:
- Gather all id_msg
- Gather all read positions (log_topics...)
- For each msg, determine if its topic is in the read topics list. If yes, if current msg is > msg of the read topics list, then consider we have unread posts in that topic. Mark as unread.
- If not, then try to find the same in log_mark_read.
- If not, then it means we never marked the topic as read, so it's unread. Mark as unread.
- Then, we just group by board.

One of the things that could be done to improve everything, is to store the last id_msg that was sent at the time of our registration. This would serve as a 'threshold', i.e. any posts sent BEFORE my registration should be marked as read.

I don't remember what log_mark_read does. I think it marks a board as read, meaning it makes our work much easier.
However, wasn't that what log_boards was supposed to do..? Hmm... I don't really remember. I'm tired. Bed time!
Posted: April 6th, 2014, 12:19 AM
Quote from Johnny54 on April 5th, 2014, 10:58 AM
Please allow one last stupid question on this.
There's already a list with all unread topics, complete with boardnames etc.
What makes it so hard to have a indication per board that the board has unread topics.
Well, that's what it's doing right now... If it has a number, then it's unread.
It's more precise than the old system. But it's also much slower.

And whether I store read status or number of unread posts, it's the same: it's very slow. I tried to cache that data, it makes it very fast of course, but it requires a load of work that I'm unwilling to put in for now. (Emptying the whole cache everytime a new post is sent somewhere or any of many other actions is performed, seems like unnecessary crap.)

 old_note.png - 79.85 kB, 934x608, viewed 300 times.

 new_note.png - 81.32 kB, 938x609, viewed 313 times.


[Poll] Re: Board status icons: what's the point?
« Reply #65, on April 6th, 2014, 12:56 AM »
Yes now that I see it... looks boring. would another color be out of the question, orange, ( I don't how to describe sloppy for me) maybe a medium green : #8A9C92, or medium, Blue ? and less radius. but I would not spend allot of time on this. If need to keep it orange then. let it be!

regards,
Maxx

Nao

  • Dadman with a boy
  • Posts: 16,079

CerealGuy

  • Posts: 343
[Poll] Re: Board status icons: what's the point?
« Reply #68, on April 6th, 2014, 12:58 PM »
Theres too much lookin the same. Messages & Notifications & Likes in Thoughts have the same style. I prefered the old way of the look. But the feature at itself is nice, even if i think its only interesting for latest topics or topics where i have "contact" to. For example if i replied on it or liked something of it. Otherwise its too much information.

Nao

  • Dadman with a boy
  • Posts: 16,079
[Poll] Re: Board status icons: what's the point?
« Reply #69, on April 6th, 2014, 01:21 PM »
Quote from CerealGuy on April 6th, 2014, 12:58 PM
Theres too much lookin the same. Messages & Notifications & Likes in Thoughts have the same style.
It's always been the case...!
They were all orange. The only thing I changed is the notification buttons. They used to be either orange or gray, now they're either orange or white.
Quote from CerealGuy on April 6th, 2014, 12:58 PM
I prefered the old way of the look. But the feature at itself is nice, even if i think its only interesting for latest topics or topics where i have "contact" to. For example if i replied on it or liked something of it. Otherwise its too much information.
Hmm... Dunno. Why not just use "Unread Replies", then...? Regular users never participate in MANY topics, and as such, they won't be overwhelmed by the information in that area...
[Poll] Re: Board status icons: what's the point?
« Reply #70, on April 6th, 2014, 01:28 PM »
Quote from Pandos on April 4th, 2014, 11:58 PM
@Nao:
I'll take a look into it.
But not before Monday. Hope this is OK for you.
Okay, regarding optimization, I was able to slash the 0.2s query time down to about 0.02s at most... That's a factor of ten.
How did I do it..? Ahem.
I added an index on {db_prefix}messages.poster_time, and then simply added "m.id_msg > UNIX_TIMESTAMP() - 30 * 24 * 3600" before the big id_msg tests.
As a result, only the unread posts sent in the last month are shown, of course. But it's much better than taking the entire database into account.

Also, I turned the LEFT JOINs into sub-selects. I don't think it's helping with performance, though. It's only making it easier to understand. In fact, EXPLAIN gives me the exact same output (Using where; using filesort) if I don't use the timestamp index.

For reference, here's the new query.

Code: [Select]
SELECT COUNT(DISTINCT m.id_msg) AS co, m.id_board
FROM {db_prefix}messages AS m
WHERE m.poster_time > UNIX_TIMESTAMP() - 30 * 24 * 3600
   AND (
      m.id_msg >
      IFNULL(
         (SELECT lt.id_msg FROM {db_prefix}log_topics AS lt WHERE (lt.id_topic = m.id_topic AND lt.id_member = 1)),
         IFNULL(
            (SELECT lmr.id_msg FROM {db_prefix}log_mark_read AS lmr WHERE (lmr.id_board = m.id_board AND lmr.id_member = 1)),
            0
         )
      )
   )
GROUP BY m.id_board

What do you think..?
As a reminder, the unread topic counter is pretty much the same query, it only replaces 'id_board' with 'id_topic', and EXPLAIN doesn't give me a "Using filesort". Well, of course it's probably because it's reduced to a very limited number of messages to begin with... ;)

madfitz

  • Elite Class Non Coder
  • Posts: 97
[Poll] Re: Board status icons: what's the point?
« Reply #71, on April 6th, 2014, 11:34 PM »
FWIW, I was happy with orange or grey. I don't know what might be visually "better" but... yeah, the new look is boring ;)

Pandos

  • Living on the edge of Wedge
  • Posts: 635
[Poll] Re: Board status icons: what's the point?
« Reply #72, on April 7th, 2014, 12:01 PM »Last edited on April 7th, 2014, 12:14 PM
@Nao
is the new query live?
Can't see it in my repo.
I like the idea of using subselects. :)
Perhaps we can simply return poster_time with a limit by 30? So we get rid of the restriction for the last month?

If not we can perhaps replace GROUP BY to prevent filesorts.

Will look into this today.

Nao

  • Dadman with a boy
  • Posts: 16,079
[Poll] Re: Board status icons: what's the point?
« Reply #74, on April 7th, 2014, 06:51 PM »
With my new query? Well yeah of course it's faster. Often faster than the unread topics query, as I expected...

I just wanted to find a way to GI through all topics with it.
Also, I think subselects slow it down.
With a couple of left joins, we're sure it'll run these once per query. With a sub, I don't know if it'll cache the results. These tables are probably not big enough I think to justify getting rid of the left joins.
Try coming back to a left join, and benchmark. ;)

File sort is only used on the full query. And if we get hundreds of results, it's most certainly faster to do the sort by sqp rather than php...

Also I'm thinking. Instead of taking the last month worth of posts... Maybe just the new posts since last session..? Like unread topics by default in SMF (this was removed from Wedge but peter forgot to remove the corresponding database field.)