UI improvements for Live Data's edit mode

Development
,
1

Hi everyone,

This proposal is a follow-up to Design for Live Data row creation
It will only focus on the live data UI itself, for other limitations (e.g., the macro) there will be more specific others.

At this point, we have the current process implemented:

  • the user can enable “edit mode” on a livedata instance,
  • in edit mode, clicking an editable cell directly opens the editor. Switching to another cell (e.g., through keyboard) saves the previous one and opens the editor for the new one.
  • if the user has the necessary rights, they can click a “Add entry” button
  • While in row addition, all the cells behave as with an existing row, except the save process is manual (either through a button or keyboard)

The implementation has, however, a few limitations that I’m trying to address:

  1. having a single cell editable at any time makes the editing experience not really smooth,
  2. for row creation, we don’t have a created XObject before saving, which means we can’t easily have a pretty display for the new cells,
  3. switching to a new cell (even on the same row) can cause a reordering of rows depending on the current filters, which can be quite disturbing for users,
  4. there is a discrepancy in the editing processes in edit mode: editing an existing row saves automatically, but creating a new row requires manual saving.

As such, I would like your opinions on the following possible solutions:

A. When clicking a cell in edit mode, make the whole row editable

This means that all the editable cells of a given row would have an open editor.

image
image1663×300 34.7 KB

This targets problem 1 and would also fix problem 2 for free.
For the save process, there are a few alternatives:

a) continue saving on each cell switch,
b) save on row switch,
c) save manually, same as row creation.

Both options b and c would lessen the impact of problem 3, and option c would fix problem 4.

B. When entering edit mode, make every visible cell editable

Slightly different than solution A, consider the whole table instead of rows. This would have the same alternatives (a, b and c) but note that it might be heavy (some cells can span multiple lines when the editor is open, so the whole table might become a lot harder to parse for users).

C. Directly create a XObject when clicking “Add entry”

This would create an empty XObject instead of waiting for the user to enter its values. That would fix problems 2 and 4 (since we could then make the save automatic) at the cost of the user losing the ability to control what to commit and when.

D. When in edit mode, freeze the view

This solution is compatible with the previous ones. The idea would be to entirely freeze the current table layout when the user is in edit mode, meaning that there would no longer be reordering on saves. The user could also possibly create new rows and see them even when over the pagination maximum size.
I see two alternatives with this:

a) if the user manually clicks a page or changes filtering after having entered edit mode, we temporarily unfreeze the view and freeze it again once the filters are applied,
b) or we don’t, the layout is frozen throughout all pages.

Both alternatives would fix problem 3.
Note that it’s important to find a clear UX for this, indicating to the user that parts of the UI are voluntarily frozen.

Conclusion

Personally, I see an advantage in implementing both A.c) and D.a).
I believe solution B would be too heavy, and manual saving in this context is not such a problem as long as it’s clearly explained to the user that some data has not been saved (quite visible here because we have at max one row visibly “in-edition”) and we keep keyboard shortcuts for power users.
Solution D.a) seems more logical to me than D.b) from a user’s point of view, and doesn’t require loading more than a page at a time.

What do you think? Don’t hesitate to add anything I might have missed.
Thanks.

2

+1 for A.c (makes row edition consistent with row creation) and D.a (freezes the filter / sort, but allows the user to force update the filter / sort). Note that for D.a we also need to save before applying the new filter / sort.

B is interesting, but I see it as a different edit mode (row-by-row vs. all rows) that we could implement later.

For C it’s not clear to me if by “creating an empty XObject” you mean saving the underlying wiki page. The default live data source maps entries to wiki pages. So by C you mean creating (saving) the new wiki page with an empty XObject? This goes a bit against what we did to the object editor where we save the added objects not when you add them but when you click on save. But I’m not against it, +0 on my side.

Thanks,
Marius

3

Right, basically I mean that instead of creating the page and its object when clicking save, it would be done directly when clicking Add entry. Now, it could be a temporary page and XObject, that would later be moved once we have more information (e.g., if the page title needs to be derived from a cell input). But that’s basically a proposal to fix problems 2 and 4 if we don’t agree on other solutions, I’m not convinced it’s the best approach.

4

I have the feeling that we’re going to have a solution that is less usable/less user-friendly than what Notion has been offering (in term of UI/UX).

See Intro to databases in Notion | Notion Help – Notion Help Center

AFAIK in Notion, you can:

  • edit any cell directly (you’re already in edit mode, by comparison this would mean entering edit mode for us)
  • no save confirmation
  • actions:
    • click and hold the blue dot at the bottom corner of a cell and drag it across other cells to copy values in a table view.
    • Right-click a row or click the six dots next to an item to rename, delete, duplicate, or edit its properties
    • Hold Shift or select the checkboxes next to multiple database rows.
    • Choose the property you want to update and pick a new value to change all selected rows at once
  • Navigate easily:
    • Press Up, Down, Left, or Right arrow keys to jump across cells.
    • Press Enter on a highlighted cell to modify its content.
    • Press Enter again or click Tab to save changes and move to the next cell.
    • Press Escape to stop editing a cell without saving structural changes.
    • Hold Shift while pressing the arrow keys to highlight a block of data.

I guess the main difference is that the whole page content lives inside a single editor, so each cell doesn’t have its own editor. Would there be a solution for us to do something similar by either:

  1. While in view mode, when entering edit mode: have a single editor to edit all cells
  2. Don’t do LD edits in view mode but require entering edit mode to enter the LD edit mode, and thus have a single editor

Has this been thought aboit already or not?

Thanks

EDIT: I don’t know if this was evaluated or not, but it would be nice to have a solution that’s at least as usable if not better. And I’d find it interesting to have an excel-like ability to edit LD. It seems the directions mentioned above don’t go in this direction, but I don’t know if this is a conscious design choice or not. Ping @tkrieck

5

Problem 1 is not clear to me because I don’t know what smooth means in this context (it’s the change in layout when enabling an editor for the cell? it’s slow on enter/exit?). I’d need more clarification to choose between A and B, but it seems to me that B is more aligned with editing multiple cells in a short time use-case (notion or excel like).

B.a - IMO Having the whole table editable and handling saves automatically on cell exit goes hand-in-hand with the real-time editor concept. Having all “cells” editable would also allow for quick navigation between them via the cursor keys (after confirming changes with the enter key or navigating away with the pointer).

I agree though that having each editor enabled would be odd visually for now, so we’d need to have proper styling applied (only show each editor on mouse-over/focus and take care of changes in padding).

C - I don’t know the technicalities. But if creating a page is easy, deleting it should be easy also. If that’s the case, I’m ok with it.

I understand that it could become a problem if someone has create/edit rights but can’t delete. Could we have a special case of allowing deletion if the page is completely empty/default?

D.a - I like this approach when there’s visible pagination on the table, since we wouldn’t have cells move around when editing. It’s important to keep the user in control, though. that’s why I’m more inclined to the .a subitem.

Thanks

6

There is a slight delay when switching cells (it needs time to close the previous editor, and open the new one after focusing the new cell), and the cells “transformations” (from and to editor) are a bit distracting.

If we go this way, that’s a good idea and I think we can also consider something similar to Notion: instead of growing the focused cell to display the whole editor, make it temporarily a popup that can extend other its neighbors. But it does require also implementing C to fix problem 2.

7

Thanks, in that case I’d stay with B.a as it allows for two dimensional navigation (horizontal and vertical).

Do we already have validation on the fields?

8

I just checked how Notion behaves, and:

  • the live (database) table is not in edit mode by default; the page containing the live table is editable, but the live table is a read-only area inside the editable content (before / after the table); the live table is basically a widget, conceptually similar to a macro call in our case; if your caret is in the text before the live table, and you use the Down arrow key it jumps over; so it’s not easy at all to go inside the live table
  • once you manage to go inside the table you can use the arrow keys to navigate the cells, but they are in view mode. If you press Enter the cell editor, which is a separate editor (depending on the property type, same as in our case) is displayed on top of the cell (like a popover), not inside. It is very well aligned, so you can think you are inside the table, but its width is larger than the cell with, so its size doesn’t change the table layout.
  • Using arrow keys while editing a cell doesn’t move you to the other cells. You need to press Tab, in which case the cell editor is closed, the cell returns to view mode, and you are taken to the next cell

I have the feeling that what you were describing is not a live (database) table, but a regular table which is something else. For a live table, each column / property can have a custom editor (displayer) so you can’t really have a single editor for the entire table.

See CryptPad for a short screecast.

Thanks,
Marius

9

ok that’s cool that you checked because what I indicated was based on reading documentation and I could have got it wrong indeed (mixing standard tables with db tables).

I’ve now tried it:

You’re indeed in view mode but single-clicking a cell or pressing enter allows you to edit it. Once the focus is on a cell you can use the nav keys as you’ve mentioned.

That’s correct.

So indeed, each cell has its own editor. It’s a lightweight editor. So they behave like what @pjeanjean has implemented already I think (i.e. per cell editing).

It would be interesting to try what we have. @pjeanjean how can I try it? Is the code available in a snapshot version of 18.7.0-SNAPSHOT? I’m curious to see how we compare with notion. I’d suggest that you do this comparison, and work with @tkrieck to check if we’re at least as good and what we’re missing.

What’s sure is that Notion is in edit mode by default and thus clicking in a cell makes it editable directly. Since XWiki is not in edit mode by default, we probably need something a bit different to enter edit mode (as otherwise a user wouldn’t be able to highlight a cell word to copy paste it for ex).

The idea of an excel experience for editing still seems interesting to me (and would make us better probably) but as I’ve said I don’t master the technical consequences nor the cost. It seems hard at first sight so could be something done later but I still think we need to decide what our target is.

Any opinion @mflorea?

10

We should strive to have the same ease of navigation between cells and the same ease of entering and leaving edit mode, plus auto-save, as in Excel. But I would still load the cell / row editor on demand. Given that each cell (column) can have a different type of editor (which is not common to Excel) it makes it cumbersome to display all types of editors inside the table cell (it changes the table layout between view end edit). We could let the property displayer decide whether the edit mode is displayed inline, inside the table cell, or as a popover on top of the cell. I noticed that Notion shows the checkbox inline, inside the table cell, while the text input is shown in a popover, very well aligned with the table cell, but still on top of it as it can have more width/height.

Thanks,
Marius

11

LGTM

Thx

12

Hi, I just updated https://design.xwiki.org/xwiki/bin/view/Proposal/LiveDataAddEntryAction with the newly points discussed.

I like the idea of having cell editors in popovers/popouts, not sure yet if it makes sense to have displayers decide on whether or not they should be inlined (I can’t think of a displayer we have right now that would not cause a resize when in edition) but it might be a good first step for rich text edition support (that would require a full editor that cannot fit inside a cell) while making the current edition a lot smoother.

13

Thanks for the proposal @pjeanjean

+1 for the notion like one-cell-at-a-time edition mode as descibed by as @mflorea
+1 for A and B

We can start without this while making sure that if small enoght, the display just fits the “view” cell, and overflow otherwise.

I tend to prefer the finest granularity when saving existing entries

  • +1 for a save on cell switch (and a save being saved shouldn’t block the rest of the UI).
  • +0 for a save on row switch
  • -1 (or at least not as the default) for a manual save

I’m also fine to have the same behavior for new row (i.e., save the xobject in a new page as soon as a value is edited) , but we need to

  1. Make sure that users can remove entries they added by accident
  2. Preferable don’t request for user intervention when saving (e.g., asking for a page name), that’s the only case where having an explicit manual save seems interesting, but I tend to prefere fully automated page name picking in the context of LD.

It could be made configurable to have a way to configure the granularity (optionally, later). I guess this goes with the larger discussion we have for realtime too on the topic.

-1 for C

+1 for D.a

14

Considering the consensus on the save mechanism seems to be that it should not be manual, I just created Live Data's entry creation save behavior as a follow-up.