Live Data popover user experience

Development
#1

Hello all,

Currently, when a Live Data is displayed and the user has the right to edit one of the displayed property, double-clicking on it allows to switch the property to edit mode and edit it in place (see https://jira.xwiki.org/browse/XWIKI-18659).

This is causing some user experience issues:

  • if the property is of type link, the user is forced to click on the div, but not on the displayed link as otherwise the link is followed and the user is directed to the target of the link, even if his intent was to double-click to edit
  • triple-clicking to select the whole content of a cell is not possible

To address these issues we decided to:

  • disable following clicks on link when the entry is editable
  • introduce a popover on single click, proposing the following actions:
    • edit the entry
    • select all and copy to the clipboard
    • (only for the links) follow the link

While starting to implement it, I’ve found some things that I think need to be discussed collectively.

Topic 1: Should actions be displayed with a label, or just a title?

Choice 1:
Screenshot from 2021-07-02 10-55-10
Choice 2:
Screenshot from 2021-07-02 10-55-27

The first choice is more descriptive about what the actions are doing but more space consuming than the second choice.
While the choice 2 does not show the action labels upfront, hovering on the icons displays a title with the description of the actions.

Topic 2: When should the popover be displayed

The granularity of the right to edit can be done at three levels:

  • the Live data
  • an entry
  • a property in an entry

That means that a user can be allowed to edit all or part or a Live Data and we currently do not provide a clue to indicates whether or not a given entry is editable by the current user.
As we currently disable the default behavior of the links only when the entry is editable, the user cannot know in advance when clicking on a link if a popover is going to be displayed, or if he will navigate to a new page.

The alternative is to always display the popover on link, eventually with a single follow the link action.
While this prevents unexpected navigations, the user will be required one more click when he actually wants to follow a link.

So we have 3 choices:

  • only activates the popover on editable link entries
  • always activate the popover on link entries
  • provide a visual clue when an entry is editable

I think the last choice is interesting but I did not find an good solution for it so far.

WDYT?

#2

Hi Manuel,

about topic 1, choice 2 seems more interesting to me, since it’s consistent with what we already show in the WYSIWYG editor: link-editing

about topic 2, I think the visual clue to specify that the entry is editable would be best, wouldn’t using the small pencil, like we use to specify that a section is editable, work?

#3

+1

+1. I hadn’t considered this option but I like it. This is not intrusive and I think the semantics of the pencil cursor is universal.

#4

After starting to consider in more details this option, and after some discussions with @mflorea and @cdesableau, we’ve found some flaws that I’ll try to summarize below.

First, the pencil is not a standard cursor type and users can have customized their icons, and could also be unfamiliar with it. This could lead to usability and accessibility issues.
Another point is that this does not solve the issue on touch screen, where the notion of hovering does not exist.

More importantly, designing this feature raise another question, do we want to favor navigating or editing?

For instance, notion or google sheets allows to follow link by first clicking on a cell, then offering to follow a link of the cell from there (requiring two actions to follow a link).

So before I continue further to find a configuration that works both on mouse based and touch based settings, what do you think is to be prioritized: reading or editing?

Thanks

#5

Considering all this, we propose a solution that favors navigation over edition on devices with a mouse, but that still require a second click to follow links displayed in properties on touch based devices.

  • the double click to edit is removed.
  • using a mouse:
    • navigation is standard (i.e., we don’t add event listener on links)
    • hovering an editable property shows a popover with and single edit action
  • using a touch screen
    • a touch ouside a link on an editable property shows a popover with an edit action
    • a touch on a link (regardless of if the entry is editable) show a follow link. In addition, if the property is editable, the edit action is displayed too

This solution is both compliant with screen and mouse based devices, works on all screen sizes, and propose a consistent behavior between editable and read-only properties (i.e., a user cannot accidentally follow a link by trying to edit a read-only property).