Move the watch page buttons

Hi everyone,

so I took quite some time to work on the Watch page buttons following what we initially put in the dedicated design page with @lucaa. I have a PR ready to be merged which contains lots of API changes and improvments but also a new UI for handling the watch settings.
You can see it in action in the following screenshots:

Capture d’écran du 2024-06-07 10-41-41

and in the following video: Up1

I’d like a lot to merge my PR right away, but the discussion about that UI has never been entirely closed. I read again the topic dedicated to it, where various ideas was provided.
In particular I noticed that:

  • Vincent was preferring to have the button either in the bell menu in the top of the page (where we display notifications) or in the more action menu (the … menu)
  • Marius seemed to agree with moving the button inside the page area, and ok with having it in the more action menu too
  • on my side I’d prefer to have it where it’s currently located in the screenshot, as I find it easier to discover but I’m +0 to move it to more action menu

So please vote for your favorite option:
A. Put the button next to edit like in the screenshot
B. Put the button inside the more action menu of the page
C. Put back the button in the notification area under the bell menu

I’m opening this vote for 2 week days until tuesday 11th at 6PM, so that I have enough time to rework the UI before the RC release.

Here’s my vote: +1 for A, +0 for B, and -1 for C.

Hi Simon,

Thanks for working on this.

For me:
-0 for A (I don’t think that users need to see that action all the time, nor the status for it)
+1 for B
-0 for C

I also think we need to decide if we use the “follow” terminology or the “watch” one. Your screenshots are mixing the 2 vocabularies and I believe we need to have some consistency.


PS: I haven’t fully re-read the design proposal (which is elaborate with lots of use cases).

Basically the same, for the same reason.

I’m worried about the backwards compatibility implications of option B: Users that have used XWiki before will notice that the notification buttons are missing and if they don’t immediately see where they are now, they won’t find them. But maybe we could add a tour to inform users about the change after the upgrade?

-0 for A as I think the space there at the top is precious, and we should avoid cluttering it. I would have been +1 if it was just an icon.
+0 for B as while this makes most sense, I fear that having an item that is a status and not an action doesn’t fit there.
+0 for C as it is where existing users look for the feature.

If we go for B, I wonder if we shouldn’t introduce another place like in the footer of the document that shows the notification status.

-0 for option 1, +0 for option C
+1 for option B.
Couldn’t we put an explanation at the “legacy” location, explaining where to find it now?
Something we could remove later, e.g., after one cycle. Also, we could make it possible to hide it by configuration.

+1 for A: a status like this should be easely seen, but I would prefer an icon only; this button should have an aria label describing the status too and a title, so you can have an explanation for the status very fast with hovering the mouse; normally I would say that buttons should always have a label, but in this case I think an icon should be enough, as this is a combination of a button to change and a status to show

+0 for B: it’s more related to the article then option C, but the status must be actively checked on every visit

-1 for C: this part is more a global one; normally I wouldn’t search here for notifications based on the shown article

So, I started to look at implementing option B as I thought it would be the result of the vote but it’s not good. @MichaelHamann pointed out a consistency problem with using a noon in the button next to create/edit but it’s even worst in the “More options” menu since we put the possible item under “Action” submenu, and it really doesn’t look good IMO:
With “Followed” status:
Capture d’écran du 2024-06-11 16-58-46
With “Not set” status:
Capture d’écran du 2024-06-11 16-58-56

I personally feel it’s even less understandable, so I’d be -1 for this option: I’m ok for having a menu entry there to open the modal for watch settings, but not for displaying a status, so like this (with a better label probably):
Capture d’écran du 2024-06-11 17-00-29

I experimented a bit the options we have with current existing UIXP, and so far the only options not too bad are next to like button on the bottom of the content, or directly in the information tab:
Displayed after content header:
Capture d’écran du 2024-06-11 17-02-48

Displayed after content footer:
Capture d’écran du 2024-06-11 17-02-04

Displayed in information tab:
Capture d’écran du 2024-06-11 17-07-09

Personally I feel like the information tab is the right solution on the long run: it’s easy to reach and we can be a bit more verbose without cluttering the UI.
Now @tkrieck did make some proposal to put the info next to the author, which was possibly a nice solution but we don’t have a UIXP for this, so if we go there we’d need first to introduce the UIXP.

So I’m reopening this vote for 2 days, what solution do you prefer between:
A. Put the button next to edit (A from original proposal)
B. First screenshot in this message: button with status in more action menu (also B from original proposal)
C. Put back the button in the notification area under the bell menu (C from original proposal)
D. Put a generic button in more action menu + a status next to Like button
E. Put a generic button in more action menu + a status in information tab
F. Put a generic button in more action menu + a status next to the author with a new UIXP
G. Only put a status + a link in information tab (same link as for editing properties of a page)

Here’s my vote:

  • -0 for A
  • -1 for B
  • -1 for C
  • -0 for D
  • +1 for E
  • +0 for F
  • +1 for G

This vote is opened until thursday 13th at 6PM CET.

IMO the action should be “Watch”.

For the status, we need to decide if we put it in the menu too (for example with a different icon + some text after the action, like “Watch (Followed)”) or it we want to display it elsewhere in the UI, in a non-obstrusive place.

D or E sound ok to me. Now, if we put a status outside of the more action menu, then we should probably also make it clickable, and then I’m not sure we need the action to be in the more action menu (we could, for consistency reasons - Note that we don’t have a Like action in the more action menu ATM for example).

I’d like to have @tkrieck 's opinion on this.

this is probably the best solution. Also, I think we should just display the status of the watching.


I find it hard to find in the menu

I’m fine with option E. And I would also add a small temporary text in the current position at the top of the page to where those options were moved, nothing fancy. As @MichaelHamann said, current XWiki users are used to find that option there and this was evidenced in my our usability study (I still need to post the results btw).


Screenshot 2024-06-11 at 13.52.43

Further down the road, it would be nice to also see it as a clickable status besides the author, after the UIXP introduction. This would show new users that this kind of feature is available.

Also, I am not worried if this is something that’s accessible from multiple entry points (menu, status, info tab). Redundancy in some cases can be beneficial, in this case allowing different users, with different ‘paths’ inside the system, to discover a secondary feature.

I don’t like this too much for several reasons:

  1. While it may be nice to see it once, it’s painful to see it every time you click since you already know about it. The Tour idea is better IMO for this reason.
  2. Some users will not have upgraded and this message is not necessary (and more confusing than anything else for them).
  3. I don’t think we should point to some external URL. First, some instances of XWiki don’t have internet access and that URL could be broken/moved/etc. The message will also require maintenance since it’ll need to be removed in the future.