[Plugin] Notifications system (1.0)

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #135, on May 29th, 2013, 02:42 PM »
This is pretty nice, I really like it :D. Although get_single_post can cause a lot of queries, perhaps some caching or grouping can be useful here? This can get slightly tricky given the modular nature of notifications. Or store the body in data column of notifications for preview?

PS: Bug, marking a notification as read when the preview is open doesn't remove the preview container but just the notification
Posted: May 29th, 2013, 02:37 PM

I had another idea though, make the notification's preview appear on hover and on swipedown event for touch devices? That'll be pretty cool.
The way it's meant to be

Nao

  • Dadman with a boy
  • Posts: 16,061
[Plugin] Re: Notifications system (1.0)
« Reply #136, on May 29th, 2013, 03:51 PM »
- Pete: if you have large videos, then it creates a scrollbar, but the other notifications will still be readable in the same pane -- they won't take the entire width, only the overflowing elements will actually overflow, so I thought it was fine, but would you rather I overflow:hidden the entire preview..?

- Shitiz:

- get_single_post is a single query, using a very obvious index key, so it's fast to execute... And, it's only executed once per Ajax query, so you shouldn't be worried about THAT query, more about the queries that are executed before get_single_post even gets to be executed, eh... ;)

- I'm still waiting for your updated code to store the notification issuer in a row, rather than in the data field... If you want to update it, of course... :^^;:

- I'm aware of this issue, and I actually wrote a fix for it, but I couldn't figure out whether it was "all right", or if I could do a better animation... I'll probably end up using this, as it's really short and sweet: just add .next('.n_prev').andSelf() right before the .hide() call in the mark read code path.
Posted: May 29th, 2013, 03:50 PM
Quote from icari on May 28th, 2013, 11:54 PM
i have not had to really see how the notification system works that well, but does that preview also parse bbc? it might be worth not parsing bbc especially if it only shows a small preview of a message
Showing unparsed messages should never happen... It's okay if you're the author, of course, but the viewer (guest or whatever), should never see the cogs in the machine, it just doesn't make sense to make them wonder what they're reading.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #137, on May 29th, 2013, 03:58 PM »
Yeah, I'm inclined to think overflow:hidden might help but I still think it makes it overly long vertically.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #138, on May 29th, 2013, 04:04 PM »
Quote
- I'm still waiting for your updated code to store the notification issuer in a row, rather than in the data field... If you want to update it, of course... :^^;:
I know, I have my last entrance exam on 2nd June (2 papers, 3 hours each and an hour break in between) so once I'm through with that I'm back on programming :D. I'll work on the patches after that.

agent47

  • Now I see the changes you're talking about.
  • Posts: 115
[Plugin] Re: Notifications system (1.0)
« Reply #139, on May 30th, 2013, 06:10 PM »
I don't know if you've moved passed this and have already come up with an idea for this but there needs to be some sort of indication that a preview is available. If you've come up with something, do share if you don't mind.

P.S: If I may, the top [orange and white] loading bar looks very old-school and doesn't go along with the feel of Wedge.

Nao

  • Dadman with a boy
  • Posts: 16,061
[Plugin] Re: Notifications system (1.0)
« Reply #140, on May 30th, 2013, 06:19 PM »
Nope, haven't moved past this... I'm just taking a break from notifications, after working on them for so long... :P

Anyway!

And yes, the show_ajax is old-school, I even said so in this topic I believe, but what alternative can you offer..? My current plan is to use Zoomedia's ajax stuff as replacement, but... Well, it's not my priority.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #141, on May 30th, 2013, 06:38 PM »
Has it even been modified style-wise since we inherited it? At least it's not the white-on-green on 1.1.x...

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #142, on May 31st, 2013, 03:20 PM »
Okay, so I take a lot of inspiration from Android these days (see SMF4Mobile 1.2 for example), even the notifications area is somewhat inspired (centralised notifications for all) from Android as well as XF's implementation. One new nifty feature in Android (since 4.1) is the ability for notifications to have actions, so you can do stuff right from the notifications without going into the app (archive e-mail, share a new screenshot etc), and I think it can be useful for this as well? Like for reported post one can provide actions to close, delete post etc.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #143, on May 31st, 2013, 03:51 PM »
I know the plan is to migrate all principle notifications to the shiny notifications system, but I actually found myself intrigued by what IPB offers in this direction.

They allow for notifications being controlled by admin as to whether email or notification is sent, and whether the user has a choice in the matter.

The other aspect about it that's quite important is that I don't really see how board/topic (set to notify etc.) will fit into what the notifications configuration currently has... right now there's facilities for selecting whether you want it or not and whether you want emails on it as well/or not. But boards/topics explicitly require more complex notifications.

Right now the choices are 'new topics in a board I have set to notify me about' and 'new replies to topics I have set to notify me about' but I can well imagine that people would also want 'notifications of topics I've previously replied to' (which amounts to turning notifications on for a topic when replying, at least by default)

And since there are likely to be many... we come back to the other notifications page that we haven't killed off yet.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #144, on May 31st, 2013, 03:53 PM »
I already got that covered, that's what the notification subscriptions core is all about (and the topic subscription automatically subscribes as well), I just need to make an up to date patch.
Quote
They allow for notifications being controlled by admin as to whether email or notification is sent, and whether the user has a choice in the matter.
I've always meant to improve email handling, so this is a pretty good idea.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #145, on May 31st, 2013, 04:12 PM »
I'm not so bothered by the core part of it, because I know it can handle it - it's the UI for the user, selecting what topics they want - and more importantly opting out of topics - that I'm a bit fuzzier on. Essentially we need to somehow splice the old thing into the shiny thing :P

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #146, on May 31st, 2013, 04:12 PM »
Quote from Arantor on May 31st, 2013, 04:12 PM
I'm not so bothered by the core part of it, because I know it can handle it - it's the UI for the user, selecting what topics they want - and more importantly opting out of topics - that I'm a bit fuzzier on. Essentially we need to somehow splice the old thing into the shiny thing :P
Well I'm currently keeping the UI more or less the same, if you got any better ideas I'm all ears.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #147, on May 31st, 2013, 04:15 PM »
All in one page? Right now having two pages is confusing ;) I got no problems with AJAXifying stuff as needed.

Also, something I noticed... the notifications core plus all notifications that hook into it are all loaded every page load... do we need to load them every page load or only if we're actually going to send notifications (or do something else notification related)?

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
[Plugin] Re: Notifications system (1.0)
« Reply #148, on May 31st, 2013, 04:29 PM »
Quote from Arantor on May 31st, 2013, 04:15 PM
All in one page? Right now having two pages is confusing ;) I got no problems with AJAXifying stuff as needed.

Also, something I noticed... the notifications core plus all notifications that hook into it are all loaded every page load... do we need to load them every page load or only if we're actually going to send notifications (or do something else notification related)?
Ah, okay. I'll look into simplifying them. Yes, they're required to view the notifications as well.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
[Plugin] Re: Notifications system (1.0)
« Reply #149, on May 31st, 2013, 04:34 PM »
Yes, they're required to view notifications, however the notifications are pulled AJAXively, yes? In which case that would presume you only need to load it for the cases when a user is actually viewing them (i.e. as part of the AJAX service) rather than every page load.