Email Notifications and hierarchy of pages

[surli]

Hi everyone,

I’m currently working on Loading... and in order to fix it properly I’d like to know what we want exactly in the notifications emails to display the hierarchy of pages.

So right now, as described in the ticket, the hierarchy of pages in notifications emails is displaying without taking into account common ancestors, outside of direct parents.

It means that if an email contains event for following pages: Space1.Page1, Space1.Page2, Space1.Page1.SubPage

The hierarchy will appear like this:

- Page1
--- SubPage
- Page2

No information is given in the table of contents displaying the hierarchy that Page1 and Page2 belongs to the same space.

Now, since @caubin was saying in the ticket it was a regression compared to the old WatchList notifications emails, I checked those emails. It appears that back then the mails were not displaying the full hierarchy, but it was using the dot notation of references.

So in my example it would have appeared like that:

- Space1.Page1
--- Space1.Page1.SubPage
- Space1.Page2

Advantage of that solution is that it allows a compact display, compared to a full hierarchy when it can become very long with a lot of nested spaces.

Now, another possibility would be to not use the dots notation, but display a hierarchy with holes when there’s more than XX levels of nested spaces. For example, if we say no more than 2 levels of nested spaces and we have changes in `xwiki:Foo.Space1.Other.Bar.Page1`, `xwiki:Foo.Space1.Other.Bar.Page2`, `xwiki:Bar.WebHome` the hierarchy could be displayed like this:

xwiki
- Foo
--- ...
------ Bar
-------- Page1
-------- Page2
- Bar

Here Space1 and Other subspaces are hidden, but the advantage is that it’s visually either to understand that the dot notation, without crowding too much the hierarchy.

So I think we have 4 possibilities to solve this:

1. we don’t change anything, and we keep a flat hierarchy without displaying common ancestors (current situation)
2. we display a full hierarchy with all nodes
3. we display the hierarchy using the dot notation: common ancestor nodes won’t be displayed unless they have changes too
4. we display a hierarchy with all nodes using holes to limit the number of displayed hierarchy (which could be configured)

I’m +1 for 3 and 4 on my side, with maybe a slight preference for 4, even if it’s probably more complex to implement.

WDYT?

[mleduc]

-1 for option 1 since, as the issue reports, the absence of the full hierarchy can be confusing.
-1 for option 2 since it’s going to give more information than what’s strictly needed which can also be confusion.
-0 for option 4 as I’m not sure having a tree is actually useful to users.

So +1 for option 3 as it’s the one showing exactly what had changed while providing a full context.

[vmassol]

@surli

we display the hierarchy using the dot notation: common ancestor nodes won’t be displayed unless they have changes too

+1 for option 3 but not using the dot notation (which is too technical and doesn’t bring value).

As you can see in the screenshot in the jira issue, in the detail of each change we already display the hierarchy using /. I’m proposing that we do the same in the list of events at the top of the mail. Thus it would solve the problem + it’s using the same way to display the exact location at the top and in the details, which is consistent.

Thanks

PS: BTW I think we could remove the duplication between the path in grey in the details (e.g. “Home / Space1 / My page”) and the page title “My page”, and keep only one (since “My page” is duplicated).

PS2: I would ask @tkrieck to do a UI/UX analysis and propose some nicer design for the mail. I know out of scope for the specific issue at hand but I think there’s some common part, for ex on how to display a page reference.