Notifications preflet changes

Can you point me to a more standard header example?

Yes I’m going to play with the list look a bit. Still thinking of ideas, I just got the basic info there for now. One thing I have to consider is people like YOU who change the list colors :slight_smile: , so I have to be sure to pick colors that are pretty much guaranteed to have correct contrast. Which makes my choices limited to the selected list item text/background color or the unselected ones.

I probably need to make the list items multiple lines. We have Group, Title and Content text to consider. First two are optional. A second line would also allow space below the time for an icon or status text to indicate when a message was “muted” or if it timed out without the user closing it. That way it could easily be seen which notifications were missed.

No. :slight_smile:
I don’t think there’s an example for headers in lists yet. I meant the rounded rect around the header looks more like something you find on the web.

Here’s a quick mockup of what I’d consider more in line with Haiku’s style:

For the time, I’d say down to the minute is precise enough.
(Hey, and mind the sentence-casing… :slight_smile: )

I don’t think it should become too colourful. Just using the standard named colours and tint a bit up or down depending on that colour (light/dark).

Not sure going multiline is best; it doubles the length of the list… :slight_smile:

Maybe going for a column list view is nicer. I also like the alternate light/dark rows of the e.g. Repositories prefs.
With columns people could make the columns they’re not that interested in narrower (maybe truncating the contents) or even hide them. After all, there’s still the preview at the bottom. That preview might be put in a split or expando view, so people that are just fine with only the list can hide that.

One column could hold the notification caller’s icon, so people could hide the respective column. That icon could be superimposed with a “mute” symbol when the notification came in when muted.
Your popup menu at the top can then hold “All”, “Muted” and maybe other categories.
You could add a filter text control like in HaikuDepot, to have a full text search through all entries and only show the hits.

I’d also rather have the timeline reversed: most recent on top.

Just brain-storming… :slight_smile:

3 Likes

Looks good, Perelandra0x309! Thanks for making these changes, and writing this post.

I like all these ideas. Using a column list would add a lot of flexibility and enhance the user experience.

How about adding icons to notification history? This way it would be easier to distinguish between apps.

1 Like

Maybe grouping according notification sources (eg. Apps)

Lots of great suggestions here, thanks. I’ve completed a lot with this, maybe I’ll put up a screenshot tonight.

-Date headers now have solid background, lightened some from the selected item background color (need to add code to detect if I need to darken instead)
-Time in the form of 12:34 PM

  • Use use the colors defined in Appearance, so it’s as colorful as you decide :slight_smile:
    -Stayed single lined, and I like the item list better, it is cleaner looking. I could do something like add a menu bar where you could select what data elements to show:
    Show
    *Time
    *Icon
    *Application name
    *Title
    *Content
    -The top menu has “All” and “Muted” now. I may add a “Missed” for notifications that reach the timeout (were no clicked to dismiss them) which likely means the user missed seeing them.
    -Search is a planned feature.
    -Reversal of order- OK, maybe another menu to choose sort order:
    Sort
    *Ascending
    *Descending
    -Grouping by app: perhaps, I will have to play around and see how that would work. Perhaps the search function could serve as a way to filter a certain app if you search by app name.

Edit:
Oh also wanted to add, clicking on an item shows the preview on the bottom. Clicking a date header or clicking the notification’s close X hides the preview (Neato!).

Rather than menus everywhere, I would add my vote to using a standard BColumnListView which provides sorting (with primary and secondary columns), configurable columns, etc. Please don’t reimplement this with a BListView.

If you don’t like the looks, maybe change the BColumnListView code to make it look better.

As for “missed” notifications, I’m not sure about that: usually when I get a notification from Vision, either I read it and there is not much to do (the full message is included anyway), or I use Alt+F1 to get to my IRC workspace and reply there. As a result I very rarely click notifications.

2 Likes

No, there won’t be menus everywhere. If more options are added they will all be put up into a menu bar. But I think this is all I am going to do for now, just choosing either All notification or Muted notifications, and the search control.

For using column list we would need columns for Date, icon, Application name, Group text, Title and Content. A lot of times, Application name and Group are identical. Sometimes there is not group, or no title. So I think it will look very poor with lots of empty spaces, some rows having groups and titles and some having empty spaces with none. With an list view I have added logic to present all the information in a more condensed and consistent looking manner:

Perhaps the missed notifications are best left for when we get a true notification shelf to place them onto.

1 Like

I, too, almost never actively close a notification. Only if the damned thing obscures something - most of the time a download notification from Web+ keeping me from a tab behind it…
Therefore I second your notion to leave “missed” ones for the shelf.

This “Notification history” will eventually be a tab in the Notification prefs, right?

What do you think of putting another slider in the “General” tab there with the label “Retain history for:” with 0 to 14 days? “0” means no history, i.e. clears the history.
I first thought about an added button “Clear history” in the history tab, but figured that there’s really no need to completely purge the history and most of the time, you just want to have old notifications removed. Setting a retaining time in the “General” tab seems more practical.

The “Retain history” setting should be respected when switching to the History tab, i.e. showing only the set amount of days. But actually removing older entries should only be done when quitting the Notification prefs. That way, I can go back and change the setting again, if I’d have removed too many entries…
(Did I express myself clearly here…? :slight_smile: )

The history will be saved in a separate file, I expect? That way people can easily purge their history, if they need to.

1 Like

The history window is totally separate from the preflet. It doesn’t really fit in with the concept of changing settings.

Actually adding history settings to the preflet was my very next task. I was going to add a checkbox to "Keep history for _____ " (that last part is a text view) and a menu to choose “days” or “weeks”. Retain is a good alternate word.

If I set it to only keep/retain 7 days, I don’t want to have to go to the preflet every time to clear the old data, it should be automatic. That would be my expectation as a user. So I am going to put a recurring daily message runner in the server to kick off a task to clear old cached history older than the setting in the preflet. There is one file for each day saved in ~/config/cache/Notifications and the History viewer will just read everything in that directory. The cache cleaning task simply deletes the files older than the preflet setting. That makes it easy if someone wants to turn off the feature in the preflet and clean the files up manually or with a script.

And did you notice the alternating shading on rows :slight_smile: Just for you! Actually it was a great suggestion.

Sounds all good. I assume the history (as well as eventually the shelf) will be accessable from a replicant icon in the Deskbar? I wouldn’t like to have the History and Shelf under Applications and the prefs under Preferences. That’d feel a bit too fractured…

I’m not sure if we need such micro-precize setting. A slider is very user-friendly, if it supplies sensible values. Maybe:
never
1,2,3,4,5,6 days
1,2,3 weeks
1,2,3 months
forever

“Never” would disable the history, “forever” never deletes anything leaving the user to manually clear things.

Humdinger,
Yes on the deskbar icon, see my screenshots here:

Do you mean one slider with all those option? Hmm I’d have to try that to see how it works, probably would have to use it asynchronously to automatically update the label. Could there be a legend below the tick marks? Like:

     |-----------------------------------------------------------------|
           1    2    3    4    5    6    1    2    3    1    2    3
   Never  |             Days           |    Weeks     |    Months    |  All

Or do something like your cool BurnItNow bar graph as the legend. I think we’re in uncharted slider territory here.

Can applications control the history archiving via API, i.e. opt out of it?

If you consider e.g. an instant messenger, then a lot of messages would generate notifications, probably even containing the message texts. If these are archived, it would pretty much create a second (one-sided) chat history in the notification history… not all that useful. Or if you downloaded lots of things with Web+, what’s the use case for having a long history of “download completed” messages?

As for the notification shelf… something like that has been in KDE (probably still is), and I found it quite unplesant. For example, things like file copy operations got their progress indicator moved into a notification (their notifications can also contain progress bars and such). Sounds useful, in theory. But then, in practice, every file operation generates a notification. And they all go into this notification shelf of KDE, waiting for me. And then I had to manually dismiss them, often dozens at a time, whenever I sorted through a bunch of files with the file manager. Quite annoying! So I reconfigured it, setting that the notifications automatically go away after some seconds. Then all’s good right? I found out, no: because then things like instant messenger notifications were lost too if I didn’t see them in time.

What I want to say is, I guess there’s no one-size-fits-all solution for this. Different applications have different needs. Some notifications are important and should be seen, maybe even manually acknowledged by the user, others are ephemeral and lose all relevance after a few seconds already. So maybe it could work with a good API, putting each application in control of the behaviour itself.

2 Likes

regarding time it should use one of the short formats defined in localization preferences

I don’t think there needs to be a legend or anything spiffy. It will have to be asynchonous, though. People immediately get it when the label changes when they drag the slider knob.
So the label would change from “Don’t keep a history” over “Keep history for 1|2|3|… days|weeks|months” to “Don’t limit history”, for example.

Jua makes a very good point.

Would it be as easy as adding another notification_type, see Notification.h:

enum notification_type {
	B_VIEW_AND_FORGET_NOTIFICATION,
	B_INFORMATION_NOTIFICATION,
	B_IMPORTANT_NOTIFICATION,
	B_ERROR_NOTIFICATION,
	B_PROGRESS_NOTIFICATION
};

The new B_VIEW_AND_FORGET_NOTIFICATION and the existing B_PROGRESS_NOTIFICATION wouldn’t be archived in the History or Shelf.

[Edited: …or maybe keep in the Shelf, just not in the History?]

jua and humdinger,

Great ideas, except I would condition jua’s point above with this: if you give the application the ability to define a notification type, the user should also have overriding control. So ultimately it should be up to the user to define the experience with notifications (which apparently wasn’t the case with KDE causing jua’s frustration). I have also been thinking about different notification behaviors. For example on MacOS, some notifications are “persistent”, like the system update notification which remains visible until you click on “Close” or “Remind me later…”. This would be equivalent to a Haiku notification with no timeout.

So I see possibly 3 types of notification behavior: Persistent, Normal, and Fleeting.

Persistent- No timeout, remains on screen until user dismisses. Does not go to notification shelf (once we get one) since the user has seen it. Saved in history.
Normal- Times out, disappears from screen after timeout reached. Does go to notification shelf after timeout. Saved in history.
Fleeting- Times out, disappears from screen after timeout reached. Does not go to shelf. Is not saved in history.

If the user would like to override the types used by the application, that could be an option set in the “Applications” tab of the preflet, giving the user the ability to do something like make instant message notifications fleeting so they don’t crowd the history or shelf.

One nice thing about the notifications window (and should be the same in the new shelf) in Haiku is that all notifications in each “group” can all be closed at once, so you’re not forced to close each notification individually.

1 Like

OK. But still, to distinguish different kinds of notifications, it does boil down to the available notification_type. If an application just always uses B_INFORMATION_NOTIFICATION there’s no way to have some of them persistant/normal/fleeting.

We can only have default settings in the General tab (that can eventually be overridden on a per app basis in the Application tab).

Also, the user has to be able to distinguish those different types. I propose a small icon on the “Group” bar. Remember my flat Notify_* icons? :slight_smile: They are already in the trunk:

We probably need another icon for the B_VIEW_AND_FORGET_NOTIFICATION (B_TRANSIENT_NOTIFICATION ?), or maybe just the Notifications prefs icon?

The settings could be in a table with the notification_types and checkboxes for their behaviour (the notification_types are of course not in the GUI…):

							Keep in			|
						Shelf	History		|
											|
{icon} Normal note			O		O		|	B_VIEW_AND_FORGET_NOTIFICATION
{icon} Info note			x		x		|	B_INFORMATION_NOTIFICATION
{icon} Important note		O		x		|	B_IMPORTANT_NOTIFICATION, B_ERROR_NOTIFICATION

B_PROGRESS_NOTIFICATION are always transient, i.e. don’t go in shelf or history, right?
I don’t think we have to make the “No timeout for important notifications” user-settable. Actually B_IMPORTANT_NOTIFICATION or B_ERROR_NOTIFICATION are always no-timeout.

[Edited to add: Hmm… I wonder if the above “Keep in Shelf/History” GUI should only be available on a per-app basis. The above shown defaults should be good enough as a system setting. Only “misbehaving” apps that use e.g. B_INFORMATION_NOTIFICATION instead of B_VIEW_AND_FORGET_NOTIFICATION for their notifications could then be tweaked.]

1 Like

I’m wondering why the notifications are going to be stored in a file at all? I expected them to be stored in ram only and disappear when I reboot the machine. Which incidentally removes the need for a “keep for x days” setting if one reboots often enough.

3 Likes

I agree…
Keep it simple!

1 Like