This topic was marked solved by its starter, on February 18th, 2014, 12:07 PM
« Parse error: syntax error, unexpected '?', expecting ')'
Some thoughts on notifications
Error on Skin/Theme Select »

Nao

  • Dadman with a boy
  • Posts: 16,080
Some thoughts on notifications
« on February 7th, 2014, 11:18 AM »
Just wanted to discuss two things in notifications... The user side has many questions, so get prepared!

- On the code side: yesterday, I was a bit disappointed that it took so long (about an hour) for me to re-figure out how the system worked. I was expected to re-use Like_Notifier for thoughts, but it wasn't possible because thoughts don't have a topic ID. I'm okay with that, as most notifications won't have this problem anyway, but still... Isn't this whole OOP code a TAD too complicated..? I know that Dragooon (who wrote the original code) likes it, but I'm just wondering if there couldn't be a simpler way of doing things. Or, at the very least, ensuring there are LESS files to play with... Seriously, I still can't grasp why there's Class-Notifier, Class-Notification, Notification and Notify PHP files. I'd be willing to accept two files, but four is a bit much for me...
As I'm not planning to add class auto-loading to Wedge (first and foremost because I don't like the idea! Laziness is for users, not developers!), we could at least merge all classes into one file. Like I did for Class-Skeleton.php, which has both the dynamic weSkeleton class, and the wetem static class which is build on it, and renders the whole damn page.

- On the user side: should I make notifications closer to the Facebook system..? Well, I don't know, but if there's one thing that I don't think is questionable in usability over at FB, it's notifications. I'm okay with them. In fact, current notifications in Wedge are closer to FB's than Dragooon's original implementation. But there are things that I want to get opinions on.

a) Is it better to decrease the notification count once you've previewed a notification and it's marked as read, OR to reset it to zero when you've opened the notification popup, like on Facebook..? Notifications would still show as unread and all, and I could even still show the unread count once the popup is opened, but maybe it would be easier to catch your attention when the counter turns orange from gray, rather than increasing from 6 to 7 while staying orange. I tend to remember my latest number of notifications, but... Well, I'm still at 25 unread notifications, and 20 unanswered PMs. (So, if you're wondering why I'm not answering your PM(s)... Please, I prefer forum posts, where it's easier for me to keep track of things, and reply with my phone if needed! The mobile skin has yet to do things about the PM template, it's just not usable on mobile right now.)

b) There's currently a small bug in grouped notifications. Again, this feature was implemented by Dragooon, and I haven't touched it at all (I think), and I think it's a good thing and all, but I'd rather see, in addition to what's already shown, the number of likes I've gotten since last time on a particular post, instead of just the name of the first liker. I think it would be swell. I don't remember if that number is stored, though, but I can always do something about that... However, UI-wise... If more than 1 like, should I show a name at all? Maybe '2 persons liked your post', and then if you click Preview, Wedge shows you a list of all recent likers, and then the preview of the post...? Or just show like now, just one name, and a number next to it? That would need explaining... Or show "Dragooon and 2 others liked your post"? But that one implies additional language strings, and for each of the notification types.

c) Should I add a 'Mark all as read' button at the bottom of the notification popup...?

d) I'm still planning for a 'Mark unread' button to show up below post previews in notifications, to revert an automatic markread. And a 'Mark read' below PM previews, to force a markread, obviously. What else should be there next to these options..?

MultiformeIngegno

  • Posts: 1,337
Re: Some thoughts on notifications
« Reply #1, on February 7th, 2014, 11:27 AM »
a) I think Facebook-like is better (reset count when opening popup but leaving unread unless preview is opened).

c) definitely!!

Pandos

  • Living on the edge of Wedge
  • Posts: 635
Re: Some thoughts on notifications
« Reply #2, on February 7th, 2014, 11:38 AM »
On the code side it would be better to merge it into one file.
It's easyier and cleaner.

On the user side, it would be great if notifications would work like Facebook notifications.
If you open the popup, then it gets marked as read.
Also likes in topics. It's pretty cool to show the name and/or X persons like your post. And a click to preview to see all likers.
Who cares about language strings? :)

Mark all as read? Hmm... yes. Facebook style please.
So there's no need to implement a mark all as read button.
That's soemthing the user is already familiar with.
The only exception should be PMs. It should be left aside, because it's already the best solution.

That's all :)
For my personal point of view it doesn't need more features. But we will see what other opinions ideas will be thrown in.
# dpkg-reconfigure brain
error: brain is not installed or configured

Wanchope

  • Posts: 234
Re: Some thoughts on notifications
« Reply #3, on February 7th, 2014, 12:10 PM »
Facebook pattern of notification should be about the best. Also I don't know if this is how it was programmed, after reading the post I got notification on, the notification number will still be there until the user manually removes it.
On the like display, I suggest it be left untouched. Wedge likes display is the cleanest, no 'stupid-user, annoying-user and 179 others like your post', just 181 Likes.

txcas

  • Bug Zapper
  • Posts: 202

havok

  • Posts: 29
Re: Some thoughts on notifications
« Reply #5, on February 8th, 2014, 09:14 AM »
i would prefer a notification that changes colour (orange to gray) when you click on it but still show the number of unread posts, if a new notification comes in it would then revert to the other colour.(orange) with option to mark all as read
the colour changes would definitely catch your eye.

Farjo

  • "a valuable asset to the community"
  • Posts: 492
Re: Some thoughts on notifications
« Reply #6, on February 9th, 2014, 01:36 AM »
a) The grey numbers is a good idea.
b) 2 people liked your post seems sensible and simple, with a click or hover for all the names.
c) Yes.
d) Can't think of anything.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Some thoughts on notifications
« Reply #7, on February 12th, 2014, 06:51 PM »
Okay, I've implemented (a), and am relatively happy with it. When you click a notification button, it'll pop it up, and turn gray. Until another notification comes up, it'll remain gray. The number of notifications will still remain in place, so no resetting. Best of both worlds. :)

I need to talk about my implementation, though... I started off by putting the boolean into the member's data field, which is ready-made for this kind of unindexed data. Unfortunately, it turned out that this data still needed to be set on multiple users: a notification can be sent to multiple users, and a PM as well. So I tweaked my code to allow for a relatively fast implementation, but it still requires an extra UPDATE per member concerned with this.

So, I can do one of two things:
- leave it as is, and expect that it'll never impact performance, because notification updates aren't the slowest queries ever...
- or give up on my current implementation, and add one or two extra fields to the members table.

The advantage of the former is that plugin authors can easily add more stuff. The advantage of the latter is that plugin authors can even more easily add more stuff. Uh... And it's probably faster, too.

The big drawbacks of the latter (to me) are that (1) it forces testers to add the fields manually (or reinstall from scratch), (2) have you seen the SIZE of that members table, already...?! I've always wanted to make it shorter. Not longer...!

Opinions welcomed!

txcas

  • Bug Zapper
  • Posts: 202
Re: Some thoughts on notifications
« Reply #8, on February 12th, 2014, 07:52 PM »
IMHO I would go with the second implementation.  We are still on Alpha, so it should not be a big deal for us to add a couple of fields to the members table.  I am sure a simple SQL alter table script can be posted here to make the process easier.

Pandos

  • Living on the edge of Wedge
  • Posts: 635

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Some thoughts on notifications
« Reply #10, on February 12th, 2014, 11:59 PM »
Well, or maybe it's time for me to get started on that automatic DB update script... :P

Something like, in index.php, if ($db_version < 123) update_database();, and then increase that integer by one each time I'm doing a database change... Then, in that update_database() function, I'd simply go through all tests geared towards $db_version < 123, and call the database update accordingly every time.
That's how I have it in my mind, but I couldn't bother with writing the whole damn thing.

Okay, I've reverted the files here because there's no point in storing more variables I'll never be using (and a visit = a variable for life... I'll probably need to clean up the DB), but I'll still need to determine whether I add one or two columns.

hey = 'not,pm' indicates both the notifications button and pm button should be orange.
Or,
hey_not = 1 (bit) indicates the notifications button should be orange.
hey_pm = 1 (bit) indicates the pm button should be orange.

First solution is easier for plugins to add more choices without having to add more database columns. (Just do an explode, then array_merge or array_diff, then implode.) Second solution takes a bit less space in the DB, and will make it easier to mass-update the rows (multiple recipients for pm, etc.)

Second, I guess..?

I want to make that table shorteeeeeeeeeeeeeeeeeer...... >_<
Same goes for the topic and message tables, of course... Oh well, they're not as aggravated as this one, really.

Bed time!
« Parse error: syntax error, unexpected '?', expecting ')'
Error on Skin/Theme Select »