My recollection is that we assumed it would make the feature hard to discover for new users, and that it would be too hidden for old users who would look to the switch buttons under the bell menu.
The idea is that when you start registering on a wiki you don’t get any notification anymore, so you need to be able to easily start following page. So putting that action in the “more action” menu would be too much of a hide to our taste. At least, that’s what I remember from the discussions we had.
Also I think we checked a bit how notions was presenting that feature, and also took inspiration from Github with the “watch” button on the repositories.
@CharpentierLucas Yes, you’re right, I read too quickly your question.
There was definitely some inspiration from other platforms as @surli said (git*** (hub or lab or both)), but I don’t remember much more else on my side…
Ok so without further comments on that I consider that there’s an agreement on getting rid of the watch buttons. I also consider there’s an agreement on starting to replace them with a button + a modal for now, knowing that the button could be moved to the more actions menu later.
For now I don’t retain the idea of having a dropdown instead of a modal as I’m afraid it wouldn’t be enough space to give all info we want to the users.
The idea to move directly on implem is that I might need new APIs for the UCs and I don’t want to spend more time waiting for feedback, but don’t hesitate to discuss all that here.
Hello everyone, so this post will be lengthy because I had a great deal of catching up to do ;-). Please, let me know if you think that this type of content is better suited posted on other platforms.
I’ve done some mockups that could be used for the new button discussed in previous posts and also, a new idea that I would like to present to you at the end.
Disclaimers
These are mockups only, no code has been written. There could be minor differences when everything is mapped to available LESS variables and Bootstrap components;
A proposed icon for custom notification in one of the screens is from Font Awesome 6.
It goes without saying, but none of these ideas are set in stone, and all is open for discussion
These mockups are for the Follow action only, I will make another proposal and topic to show potential revamps to the Notifications dropdown currently implemented.
Current idea: ‘Follow’ icon on the button bar
In my opinion, a dropdown would fit better in this solution if we can do complex layouts inside of it.
A dropdown does not interrupt the flow of the user when exploring the interface. A modal on the other hand, by its very nature, will obscure and lock the information behind it until the user decides what to do. If a complex drop down isn’t available, then a Dialog is acceptable.
Mockups
New button on the button bar showing the current follow status
Clicking the button opens a dropdown OR a dialog showing the detailed explanation for the currently selected option and controls to change the behavior. The Manage Notifications link should open the users profile in the notification section
Changing the selected option enables the save button. Note that the status text remains the same as we didn’t save yet.
After saving, the new status is updated on the button bar
Checking the details and options saved
Mapping the dialog options to the UCs described
Fullscreen views for context
Another approach
Another idea is to have a “Follow Strip” (name to be refined) below the modified date on the article Header. This proposal come directly from this forum, as you can see at the bottom of each topic;
Applying the same idea to XWiki:
The main advantage in this version is to have the status button and the detailed description always visible to the user, in a position in line with page content and close to another area that shows update info (modified by).
Mockups
Clicking the button should show the available quick options and the custom notification that sends the user to his profile to make a custom filter. Important the icon for custom notifications is from Font Awesome 6, so we should have this package available in case we choose to proceed with this icon. In my opinion, it is a good representation of something custom, but of course we can discuss this.
Selecting an option should enable the save button
Button and detailed description updated;
The same component could be used at the end of each page. After reading all content, the user can engage in ‘follow’ actions without scrolling to the top.
Mapping the options to the UCs
Fullscreen views
–FIN–
Congratulations, you’ve made it to the end =)
Thanks @tkrieck for your first proposal! Keep them coming.
Not sure I understand this point:
What we have is already a dropdown and not a modal
Your 2 proposals are moving the location of the notification settings but you didn’t mention why you’re proposing to move them.
Generally speaking, my main comment is that we have some guidelines we’re trying to following and which can be summarized as (note that these guidelines can be revisited if you think they’re not the best!):
Try to make the UI the simplest possible, this means with the least amount of visible controls.
Both of your proposals add new controls trhat don’t exist and make the UI more complex than what currently exists in this regards IMO.
Hide actions that are not needed all the time. For example this is why the page action menu has only 3 buttons: Edit, Create and “…” (all the secondary actions are under “…”).
If you want to move the notifications settings to the page actions (first proposal), then I think it would make sense to move it under that menu. However, I don’t know if it would make it discoverable enough or easy-to-use enough vs what we have ATM (which, I agree, is ideally not the best place for a page action).
Use the minimum space for the generic UI and the max space for the page content
Your proposal 2 introduces a new line and reduces the place for the content. I personally find this too visible and obstructive.
I also find it confusing to see 2 bell icons in the UI.
Regarding the icon, indeed, having two actions for the same actions is not optimal. I have done some benchmark using Confluence and Notion and yes, they use different icons;
Confluence:
Bell: Notification Center
Eye: Notification Config
Notion:
Clock: Notification Center (updates)
Bell: Notification Config (on a dropdown)
The reasons of moving the notifications settings was being discussed before my post. As stated by @surli regarding his prior discussions with @lucaa. For migrating users this can be helpful as well, as it is an interface pattern of Confluence and Notion (as shown in the screenshots above).
The first proposal on my post is just mockups of the idea that was being discussed before on the topic, to help visualize the concept.
My proposal, the second one, the interface would have more elements to it, my reason is to have a more “conversational” approach. When the user has a setting that’s making him receive notifications, but he is not aware of. For example, when a parent page is controlling those notifications.
One idea to help with spacing, is to present just the “follow” button when there are no other notifications rules for the page. In this version I also positioned the follow button besides “Last modified by” to keep the content area intact. The complete description could be shown on hover, but I would like an opinion regarding accessibility for that.
BTW there’s also a small inconsistency in this proposal: the page actions have an icon + a text (see Edit and Create), while your proposal adds a bell icon only (no text).
When I replied to Thiago, I hadn’t seen that he was just putting in a mockup what was already being discussed, my bad. So I still have some questions:
Is it worth it to make the UI more complex by adding one more button visible 100% of the time? I agree that the notification setup action is probably better placed in the page menu but OTOH it’s going to add one more icon.
We would probably need consistency and have an icon + text for notification setup action.
Do we really need that action to be always visible or should it go under “…”?
Indeed. We proposed a dialog for having the most possible room available, as the options would require many explanations and be complex to explain. If a complex dropdown allows us to have all this while not blocking the flow of the user, fine with me.
Also, a modal would easily allow to move the bell button in another menu (e.g. under the More actions menu, as @vmassol suggest below) with no change in the code / UI whatsoever. A dropdown will need to be updated if the menu notification option is itself in a dropdown.
I didn’t read in detail all the UIs proposed for all cases.
For the icon, note that we’d need a 4 states icon (I can only see 2 in your examples above, we need the other 2).
While it’s looking good, I would say it takes too much room on the page itself (it would be a dedicated row only for this feature). Since this feature is only a setting (it does not provide any content information about the page but only shows the state of a setting), I wouldn’t give it that much room on the screen.
This forum is a conversational tool, to me, which makes notifications rather important. The wiki is a knowledge share tool (which sometime may need conversational features but not always).
This choice was on purpose, in order to make it obvious for the user that the 2 things presented on the UI are about the same thing.
I must admit that it’s not clear to me, from these other tools that use different icons, whether the 2 actions do the same thing - whether “watching” a page will only handle the notifications about that page or concerns something more than notifications.
In any case, if we need to change one of them, I may want to change the bell icon from the navbar :D. The bell icon in the navbar was initially just setting the watch state of a page in XWiki, and only when we added instantaneous notifications we decided to also put the list of notifications in it, so its initial purpose was config.
Now, to answer @vmassol’s feedback about the initial proposal:
There is, indeed. The objective was to not take too much space with it. Also note that the icon is not decorative here, it should change when the state of the watch of the page changes. So it’s as if it was “text” (meaning that it holds information), but it’s very compact.
Initially we wanted to remove it from the notification menu (the current bell) because that bell is already incredibly crowded and the current watch state of the current page was becoming more complex. Now, since we thought of a compact way of displaying the current state with actions available on click, we could move it back to the top menu but it’s still too crowded up there. Now, But as you said, it’s better placed in the page menu.
As I said above, I’m not 100% sure we do. The icon is holding information, it’s not just an icon, so it’s as if it would be just text without an icon . It is a menu that is different from the other menus up there, the question is whether we accept that or not. I don’t have a problem with a different menu being placed along the other menus on the page content menubar.
It’s perfectly possible to move it under …, as I said above, but then we can’t have a dropdown anymore for setting the settings. If we do so, we also need to decide whether we want the same principle (of displaying the state in the icon + label of the button) or just have an accessor button and have the state displayed in the modal.
Actually, if I’m not wrong, this is one of the first cases when we have such a menu for a page in XWiki: a menu that gives access to changing a setting of a page. Regardless of where we put this menu, the question I would ask here before anything is whether we agree that we want a button that shows the state of the current setting while giving access to changing it on click or we want to stick to our current types of menus that give access to the information & setting.
I’m very much for having a state-displaying button for handling watched pages, regardless of where we put it. To me, this kind of button may or may not have a text.
Another reason for moving this button outside this notification menu is also the context: the notification menu is something placed outside of the page so it’s not easy for users to understand that it will contain a configuration specific to the current page. Putting the notification configuration settings inside the page makes that more clear.
There’s also a minor question of consistency: we took a bit of inspiration from the Export modal behaviour when proposing this originally since the same question occurred when Export was revamping about using a dropdown in the more action menu, or using a modal, and it was decided back then to use a modal (see: Export format selection)
It’s not exactly the same thing here, but it shows we have a precedent with using modal for this kind of complex actions.
OTOH it’s a place where it’s easy to discover the settings and having 2 buttons make it more complex to understand and makes the UI heavier. I’m not fully convinced that moving the button is the best choice even if I understand the logic. I’m not against it though (especially if the bell menu is inside the “…” menu).
In this type of situation what we would need is to do what we’ve done once in the history of XWiki, which is to recruit newbies to XWiki, record them, and ask them to perform tasks, and ask them to verbalize what they’re doing. Present one UI to one group and another UI to another group. It’s costly and time-consuming but very interesting. And you don’t do it for only 1 item but for the whole UI with lots of different questions. See Usability: Testing (Improvements.UsabilityScenario) - XWiki & related links.
I think it makes sense to move the page watch setting from the top bar to the page area, because it’s a page level setting.
I don’t think it deserves to be visible directly on the page action buttons because it’s not used as often as Edit and Create.
My preference is to add an entry to the More Actions drop down menu that opens a modal, but I must admit I’m biased because I don’t use this feature that often (I’m expecting the watch to be turned on automatically when I edit a page or when I add a comment, which means I don’t expect to explicitly watch a page too often).
For the users that use this setting often, I’d be OK to have it exposed on the same line as the page Like button (I see these two features as related), where it would open a popover as in @tkrieck 's mockups.
Note that you’d still have a link to your notification preferences under the global bell, but not the subscription state of the current page.
The move is also related to the fact that the “subscription state” and the “wiki notifications” are 2 different things (even if related). For example, you could subscribe to a page and not have in-wiki notifications enabled (only mail ones). This is also why we decided to use the “follow” vocabulary for the state of a page, while leaving notifications be a different thing that will use the “follow” state.
Indeed, what I just said here hints towards also using a different icon for the follow state than for the notifications list (as we discussed previously on this thread). I’m fine with it, as long as it’s aligned with the vocabulary.
I guess clarification of the vocabulary used, concepts and illustration of those (icons) would be something that we should try to structure, maybe, before we actually decide on where exactly we should display things on the UI.
Instead of “follow” from Notifications - Watch buttons (Proposal.Notificationwatchbuttons) - XWiki , we could also decide to use “watch”, as we currently are, still, in some places (although we kinda banned it when we changed the notification system but not completely so it’s a bit of a mess). “watch” has the advantage of being easily translatable in an icon, more so than “follow”.
Yes, a full session of usability testing can be very costly and time-consuming. But we can try to use online tools to have smaller, cheaper, focused research. Tools like Maze and UX Tweaks have prototype testing capabilities and with proper mockups we could do these isolated tests (by isolated I mean a small scale UI change). I will look more into it, but it seems that both have free tiers available for small scale testing.
EDIT: Even better, an open source tool. I’ve made a quick usability test for evaluation purposes. The recordings are available inside the app with success rates, heatmaps, task drop off point. Really promising! Quant-UX - Prototype, Test and Learn - 4.8.2
I forgot to add the image which have all the icons described. I am on the fence about the last one, “Custom”. On one side I think it is a good telling of something custom, like ordered or made just for me, but also at the same time I think the icon may feel too weird or alien in this context. Tell me what do you think.
If this feature works like that, then I agree that the Follow option could be hidden behind more actions
Note that, because it can be quite complex to compute the actual effect on notifications of the watch state of a page and to properly propose options based on their effect on notifications, what we initially proposed with @surli was that the button & the icon handle the watch state of a page, not the result of this on notifications (e.g. an “unset” watch state may also result in “receiving notifications”, if a parent is watched with all its children and there is no exclusive filter anywhere else on the hierarchy; so the full bell should not say “receiving notifications” but “followed”).
We’ll need to find a way to express consequence of the watch state on notifications, if we want to make such a bridge explicit and to decide when we present that consequence.
See here what we proposed: Notifications - Watch buttons (Proposal.Notificationwatchbuttons) - XWiki (I see that we didn’t explicitly describe, for each UC, what icon we’ll want to display, we need to do that).
To express more clearly, let’s take an example:
When a page is not explicitly watched:
the icon should show the watch state of the page, which is “unset” - empty bell
however, the user may or may not receive notifications for the page, depending on the parent
only when they hover or click the button, we want to compute the actual result on notifications and show it to the user - we need to tell them the effect on notifications.
then, the actions proposed behind this button are still actions on the watch state, not on the notifications.
however, since there are many actions possible on the watch state (of the current page or parent), we propose the ones that may have an effect on notifications, without promising them, though.
This may be a bit too technically driven, I definitely understand that it would be simpler to design a user experience with simpler concepts. But basically this is the challenge here: how to choose what to show to the user and the actions they can do in order to drive towards a simple usage of all these technical capabilities.
Maybe indeed, from this angle, it can be clearer to:
use the eye icon instead of the bell one, to explicitly express that it’s about watch state not about notifications
use a single icon to access the modal / menu, which will then display the actual watch state & its effect on notifications (since the information in this modal is mixed between watch state & effect on notifications, it can be hard to try to resume that in a single icon).
I noticed last friday we don’t leverage 100% of font awesome capabilities. I opened Loading... so that someday we could use icon stacking, which would make finding correct variations here way easier IMO.
After reading some discussions about the Like button (Like UI aligned with known conventions - #10 by lucaa) and its effects, it seems to me that both actions “Follow” and “Like” are pretty similar. Perhaps I am missing some details about their differences, but all in all it seems to me that I “mark” some page as an interest of mine and start receiving notifications about it.
If that’s indeed the case, I think it is safe to hide the Follow option behind the three dotted button. Maybe naming it to something even more specific like: “Notification Settings” reminding the user that this option is different and more powerful than simply Liking or Following just one specific page.
In this scenario, if I want to follow a single page, I simply “Like” it. If I want more control over notifications of a page and its children, I can “Configure Notifications” (and in this case with the Bell icon or variant, to correlate them), opening a modal with all the options available and properly explained as previously discussed.
I am not aware that this happens like this today, so it’s possible that it was in a proposal but it was not implemented. The documentation of features is on extensions.xwiki.org, on design there are the proposals (the specification before implementation), so there may be differences between that and the reality.
I checked on a local 15.10-SNAPSHOT and watch does not happen on like.
To me, there is nuance here as in
the “Like” is more like a message for the others (I like this page to express my appreciation of the work that was done for other people to see what’s the best content on this wiki)
while notifications is more of a thing for oneself, like a bookmark (I watch this page because I want to know what happens on the page).
Also,
like is for the past, for what is already there (I read the content and I decided that what I see is good )
while watch is for the content that is not yet there (stuff may happen to this page in the future and I want to know when it does). I may not at all like what’s already there but want to keep an eye on it to see if it gets better in the future ;).
hints towards also using a different icon for the follow state than for the notifications list (as we discussed previously on this thread). I’m fine with it, as long as it’s aligned with the vocabulary.