Complete redesign of notification watch buttons

Development
#1

Hi everyone,

we discussed a lot with @lucaa about the watch buttons of notifications:
image

and we’d like to propose a solution as replacement for them.

So, the problem we have with those buttons, is that they have two purposes: they both display a state, and allow to perform an action. And by mixing both the state and the action in the same place, they are doing it wrong. I recently tried to improve the situation by allowing the button to have a third state, but it’s just making thing almost more confusing.

To give a simple example, right now in 15.5, by default nothing is watched for new users, so the buttons are all off, and users are only able to click to watch a page. If they started to receive mentions on a space, they just cannot block notifications through this UI.

Another problem we have with this UI, is that it’s quite hidden, and not consistent: those buttons concerns the current page, but they are displayed in a notification menu which displays notifications for the whole wiki, not just for the current page. And you have to be aware, that watching a page is provided in that menu: by instinct, you might want to perform the same action through the more action menu of the current page, for example.

So the solution we come up with is about:

  • removing those watch buttons in the notification area
  • provide a notification icon (showing current state of the page regarding notifications), next to the create/edit button directly in the page content header, as in:
    image
  • open a modal when clicking on that button, providing more information to the user about the current state of that page (if it’s watched or not, directly or not, etc), and allowing to perform different actions (follow the page, unfollow it, block it, etc)

We started to work on the different icons to provide for illustrating the state of the page, the text to display, and also the various actions that should be available in the modal. All that is available in the dedicated design page (Notifications - Watch buttons (Proposal.Notificationwatchbuttons) - XWiki) but it’s still a bit a work in progress.

Right now my proposal is only about the principle: I’d like to know if everyone would be ok on performing the solution proposed, i.e. the icon + the modal instead of the watch buttons.

If we agree on that, I’ll open new proposals to have your opinions for the icons and usecases, don’t hesitate to also discuss it directly in the design page.

Thanks

#2

Hello all,

I obviously agree with this, as I helped propose it.
I just wanted to highlight a couple of benefits that we see for this proposal.

First of all, as a base of this change, we discussed with @surli about how we’d need to change the control of watched pages (display of current state and actions) and unfortunately it’s not getting any simpler / we didn’t find a way to simplify it while still keeping it in any way useful. The most simple version is to remove either display or actions and move them to the user profile. While this is an option, it will hinder usage of notifications.

With this in mind, here are the benefits I see for the proposal we made:

  • the notifications dropdown is already rather crowded with the notifications themselves, having the control of watched pages in it is adding more complexity, so we need a new place for it
  • the content menu, while far from the notifications list itself, is much more appropriate as the state + actions will apply to the current page, not globally, so they need to be in the page menu instead of global menu, like all other page actions
  • having a button that illustrates current state through an icon is both small and information-conveying and quite enough to incite users to go further (by clicking the button)
  • full state description & actions in a modal instead of directly on the UI gives us a lot of freedom when it comes to the complexity of the actions we want to present, the explanations that go with them, even allows to implement a wizard if we need to, etc.

Hope this helps,
Anca

#3

Definitely +1 to go away from the three state buttons!
The idea looks good, an alternative is to have it as a new tab in the bottom pane, but it would make the feature more difficult to discover.

PS: I think having the bell alone without a label is a usability issue (@CharpentierLucas to confirm this :slight_smile:)

#4

I tried looking at them to make them more accessible, but since a three state button is non standard, it needed a lot of work semantically and I didn’t work on it yet. :+1: to replace them with a clearer alternative

I think that it might feel inconsistent here: all buttons in this bar open dropdown menus (advanced edit modes, more actions), and not modals, so it might feel untidy to use.
I understand the advantage for a modal (more space to write down the exact behavior of actions), but I think it might be helpful for some users to have a dropdown because even if it has less details about the actions, it also has less distance → less time (Fitt’s law). Maybe having two presentations for regular and advanced users allows for the best compromise. Using a UI based on the user type here wouldn’t be too unexpected since there is already some user dependant UI (edit modes dropdown, and content of the moreactions dropdown). It’s not a critical point. I reckon it takes time to implement two UIs and it can come later as an improvement.

For accessibility, we need to make sure to include a text alternative (visible or not).

Using icons by themselves can be a roadblock for some users. However it’s pretty common and in some cases the pros outweight the cons. For power users and users used to web conventions, the bell will be easy to understand. For less tech-abled users, they might not recognize the bell or not tie it with the concept of notification. I think that in this case, not using a visible label is correct, since “Notification” is a really long word. Maybe we can show the label only if the “extra accessibility” parameter has been turned ON in the user preferences.

Here is a talk about ageism, and more specifically, a few minutes on how some older people understand the “gear” icon. I already shared it a couple times, but I found that this part makes it really easy to understand the kind of issues a user can run in with icon only buttons.

.

Thank you for this proposal,
Lucas C.

#5

That’s not really true: I mean, by default for simple users create and edit buttons just redirect you to a new page, there’s no dropdown menu. The dropdown menu is there only if you’re advanced and you click on the arrow. Here the button would act more or less as if you’d expose “Export” action from the “More actions” menu as a top action button next to create / edit. So I don’t really see an inconsistency here.

Ok, the plan anyway was to have a title on the button, so that the state of the button can be read and not only guessed from the icon.

#6

I agree with @surli here, the modal is used also for the export options (and not a sub-sub-menu), so it’s as if we had a notification option in the “more actions” menu that would open a modal. I think we even discussed with @surli about making the notification a submenu in the More actions menu, and I really don’t remember why we decided to not go for that one but for a separate button. In any case, this would be easy to change, technically, if needed, as we will use a UIX.

I also wanted to apply this for the export options, it didn’t go through, we went for a modal. So, again, we fall on the same comparison with the export options…

I don’t think we should go in this area and it would be the first time we do so, honestly. Having additional option / command for advanced users is something we’ve done before but having the same options in a different UI we didn’t. If we decide to show more information to some users (advanced vs simple) then it would make sense, but I don’t think we have a reason to show more information to advanced than to simple (more actions yes, but not more information).

@surli had explored different options for this icon (see the design page) but I insisted for it to be bell-based so that the user recognizes and associates the bell of this menu with the bell from the navbar that displays notifications, to have more chances of figuring out what it does, before they hover it to see the title.

Thanks for the feedback!

#7

Actually, I have nothing against using a dropdown menu if it turns out that we manage to express the current state & options to change it with small sentences in a small space that fits in a dropdown.

Basically when this bell button is actioned, we’d need to be able to do 2 things:

  • display, in more detail, a description of the current state of the notifications settings for the current page;
  • propose actions to change that state - I think we’d be somewhere around 1-4 actions to propose. The actions being a little complex, we may need a name + an explanation for each of them.

So we went for a modal because it’s the UI that gives the most freedom for this: a dropdown is rather small and constrictive (displaying a state that is not actionable next to actions may not be that easy to make happen in a dropdown); we wanted to fix the current problem we have which is that we’re cramming up a lot of information in a very small amount of space, so we went the biggest. If it could fit in a smaller space we can discuss, but I wouldn’t want to make that constraint from the start.

#8

I would be interested to know why you chose this option over the submenu :slight_smile: I agree that the notification is an important aspect to manage on a page, but I think it’s way more complex of an action than ‘Edit’, ‘Create’ or ‘Translate’. Proof is, we can’t fit the UI for its parameters in a dropdown. From my understanding, actions with complex parameters such as ‘Export’ are kept in a submenu so far. Why would the toggler for notifications be in another place? I think this question describes better what I tried to explain with vague words earlier ^^’

I agree that a dropdown is not a solution for simple users. My idea here was to display less information to the advanced user, since we can assume they already understand how each action works (or at least they understand how to get more info about this). With an advanced user, you could almost put a set of icons for each actions with a short description of the current state and call it a day. That’s why I think it could fit in a dropdown without too much constraint.

But this point is secondary and should not slow down the progress on these changes. We can discuss it later in another topic about potential improvements :slight_smile: .

Thank you for your answers!
Lucas C.

#9

I ended up answering to this exact question, in my latest comment.

#10

I meant: Why chose the independant button over a submenu item for the toggler?

From what I understood, your last comment was about the modal vs dropdown question.

#11

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.

1 Like
#12

@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…

#13

Sounds good! :+1:
Thank you for the explanation, it makes more sense to me now :slight_smile:

By the way, “Watch” is a good text alternative which could be added next to the bell in the button.

#14

Well there’s a vocabulary section on the design page, we’re thinking about not keeping “Watch” verb but use “Follow” instead :slight_smile:

1 Like
#15

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.

So instead of opening another proposal for that, I will proceed and work on implementing what’s on the design page, so using the bells icon for the button and implementing the actions defined in those usecases.

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.