Design for Live Data row creation

Development
,
1

Hi everyone,

The goal of this proposal is to discuss the alternatives to implement support for row creation to Live Data. This is part of a general process to improve Live Data usability and uses, but this specific proposal does not cover the livedata macro itself nor AWM, only row creation.
Also, while I will be using the terms rows and columns a lot, everything mentioned also applies to the card layout (so, cards and fields).

Here is the design page: https://design.xwiki.org/xwiki/bin/view/Proposal/LiveDataAddEntryAction

Right now, a lot of the requirements to support this process are already implemented in Live Data:

  • the current layouts already include a Add entry button, though it is disabled.
  • the current REST endpoints already support the POST request to add a new entry, and it just needs to be actually implemented in the livetable source.

As such, this proposal will focus on the addition process for the user. On that front, there are two main open questions for the livetable source: where to store the new data, and how to display it to the user once it has been created.

Page Creation

The data of the new entry will need to be stored in a page. There are a few alternatives I can think of when the user clicks the Add entry button:

  1. Ask the user for the full page location for each new row
  2. Ask the user only for the page name for each new row
    1. Use the current space
    2. Use a configured space in the livedata macro
    3. Ask for the space for the first row and keep using the same for the following ones
  3. Do not ask anything and auto-generate page names
    1. Use the current space
    2. Use a configured space in the livedata macro
    3. Ask for the space for the first row and keep using the same for the following ones

Personally, I vote for option 2.1 (which is also the current behavior of AWM) since it’s the most straightforward and intuitive to me. Option 2.2 could also be optionally implemented to cover most of the other use-cases.
There is also the question of how to ask the user for this information:

  1. Always open a popup at the very start of the row creation, with the field auto-focused
  2. Use appropriate columns if the Live Data displays them (e.g., doc.location and doc.title, the location is usually not editable but there could be an exception during the row creation process)
  3. Enter a “row creation mode” that would add special editable columns to support this use-case.

Option 2 seems to be a decent compromise here, there is a slight overhead when the popup opens but I expect most of Live Data uses to display the page title.

Display Update

A Live Data has pagination and filters. This means that, once a user has created a new row, it might not be displayed because it is not part of the currently displayed page or it’s filtered out. There are a few ways to handle this when a new row is validated:

  1. Refresh the whole table, disable filters and move to the page containing the new row
  2. Ignore page limits and filters and simply keep displaying all the new rows until refresh, page switch or filter update
  3. Do nothing, once created the new data will simply disappear if not all conditions are met

I like option 2 more, I believe it’s the less distracting one when quickly inputting new rows in bulk.

Creation process proposal

We want a process that can be done entirely through keyboard once the creation button has been clicked once.
Assuming the chosen options are 2.1, 2, 2, an ideal creation process could be:

  1. Click the row creation button (Add entry)
  2. Depending on whether or not the Live Data displays doc.title, either make it editable or open a popup
  3. The new row appears and the first editable column is opened in edit mode and focused
  4. Tab and Shift+Tab can cycle between the columns. If the editor for the current cell displays a list, the list elements must first be cycled through to reach the other columns
  5. The new row will be created once validated. This can be done through a few different actions:
    • Cycling with Tab until the user exists the row and reaches the creation button again
    • Pressing Return
    • Pressing Ctrl+Return, which will also create a new row and loop back to step 1

What do you think? Feel free to suggest any other alternatives I might have missed and/or ask for clarifications.

Thanks.

2

For me we need to do 3.2 because:

  1. We want the feature to be easy to use (asking anything makes it just too hard)
  2. Use the current space doesn’t work in the majority of cases. The argument of current AWM behavior doesn’t work anymore because we’re talking about LD that are in-situ and not located in any app dedicated for something.
  3. We need the location to be configurable and having it in the LD config makes the most sense to me. We would still not have the use case of being able to add new pages in various spaces in the wiki but I don’t see a real use case for this and if we need that, we can always add a new strategy.

In term of design, maybe make the strategy configurable.

PS: We don’t need to autogenerate the page name fully. The LD config should provide a template for the name (with a fixed part and the rest being a generated number for ex - will require checking existing values but I think it’s nicer and something we want).

3

So first we need to define who can create new rows (probably users who have edit rights in the target space).

I would put a ‘Add Entry’ button but a “Switch to edit mode” one. When you click it, the LD goes in edit mode showing cells and basically becoming like excel, and you can create a new line using the table without clicking any button.

I’d put the “Switch to edit mode” button in the LD kebab menu so that it’s not too visible as it’s not the main use case for LDs.

4

While I agree that we should make it easier to add new entries, I’m wondering if adding entries inline in the table (Excel-like) is really the best way:

  • The Live Data might not display all columns, in fact it might miss mandatory columns
  • The space in a Live Data column is very cramped. I’m not sure that we can fit there inline validation messages, hints that transmit important information and a full WYSIWYG editor (WYSIWYG editing is currently unsupported in Live Data)

What I would find more realistic is to implement proper support for adding new entries in a modal. We would need to revamp our modal support to support stacking modals, but that seems like a good idea, anyway. In the modal, we would have enough space to have a proper edit form with hints and validation and there would be a clear flow for saving an entry. I think it would still be a much more straightforward experience than the current one.

5

What about devices that don’t have an always-visible keyboard, like phones or tablets? How would you validate a new entry there? How can you avoid validating too early because the user moves the focus outside the new row to hide the keyboard? How can users learn about the keyboard navigation, in particular users who aren’t power users and thus not used to using Tab or Return to validate data/move to the next field?

6

Note that live data is generic and doesn’t have the notion of pages. It knows only about entries which have properties. A live data source may fetch its data from wiki pages, but the live data UI shouldn’t be aware of that. This means the live data UI cannot ask for a page name. The location where the data will be saved depends on the data source. Thus, you either don’t ask for the location and let the live data source save the new data where it needs to, or you allow the live data source to provide a location picker UI, through some UI extension. I think the first option is fine for now, i.e. to let the live data source decide the location based on some live data source parameters, which Vincent suggested as well.

Same, but I think it would be nice to also provide some visual indication that the filters and sort are not fully applied, and some refresh / update action to enforce the filters (after the user has finished adding rows).

The 3 options you listed may be fine for advanced users, but for simple users I think you need to:

  • either (attempt to) save whenever a cell loses the focus (i.e. prepare for realtime editing)
  • or have a dedicated save action somewhere in the UI, for users to click after they fill all the cells

The problem with save on blur is that in some cases you won’t be able to save partial data due to validation (e.g. some properties are mandatory, or the value of one property depends on another property, like country → city).

The dedicated save action could be the switch between view and edit mode that Vincent suggested.

Thanks,
Marius

7

Hi @pjeanjean, thanks for moving forward with this implementation. For me:

As I was answering this I took a look at @vmassol and @mflorea takes on this and I guess I was understanding it wrong. I will abstain for now.

Option 2 would be my choice as well. 1 and 3 are bad because option 1 would be taking control away from the user and option 3 would not be showing relevant status update.

Agreed on the proposed process. Ideally we end in a state where almost everything can be done in the table itself for creating the entries. My only point is that while it can be used entirely via keyboard, this should not be the only option.

When adding in the table view we’d need to show all mandatory columns. Now this brings a situation in which we have some columns available for viewing and others when editing, depending on the table this might be a nightmare to use. I don’t have an ideal solution for this.

I understand your position, but this means that we would switch the user away from the context of the table. This means that the user must have in mind what was already on the table beneath the modal, and if they forget, they must close the modal to check, and this modal could already be half filled.

Just my opinion now, but it would be weird for small tables as well.

For the first iteration I wouldn’t add this. We could end up putting too much information in the UI from the get go. If new data is not fully sorted, and someone notices this, the first action of the user will be to do some sort of refresh/reset of the page to check and then they’ll learn about the behavior. If users request it, then we could add something to indicate.

Just my 2c :slight_smile:

Thanks

8

When the user switches to edit mode, we could display all columns, including the hidden ones but mark them visually as hidden (so that the user understands they won’t be visible in view mode).

I also prefer to stay in table editing mode, a la Excel. More like what @mflorea suggested in having a simple editing experience, and a more advanced view for complex cases (if that’s needed in the future).

9

Just to be sure: are we talking about the fields declared in the Live Data macro, or all the fields defined in the XClass? Because right now I don’t think Live Data offers a generic way to obtain the full list of available fields for a given source (i.e., fields of the XClass for livetable).

So, the first one could be done (if we trust the user of the Live Data macro to have declared all of the important columns) but the second one would be a lot more complex.

10

I was indeed thinking about the fields defined in the LD macro (including the hidden ones).

For fields not defined in the LD, I don’t know what we should do. Either don’t edit them at all through the LD since they’re not meant to be displayed or have an option to show them (I wouldn’t show them by default though).

Are you sure about this? I thought I had read somewhere that if we don’t define the fields, the LD was going to use them all. In any case, it wouldn’t be too hard to add a feature to display all fields as they’re easily discoverable through the XClass reference.

11

Alright, thanks everyone for your answers, now to try and summarize everything:

  • For the storage, we should provide alternatives but right now the most important one should be to have automatic page names with a configured space (3.2), ideally through a template parameter. Note that this setting should be a source parameter to keep Live Data generic.
  • For the display, we should always keep the new rows displayed (2) but consider improving the UI to properly convey that the filters/pagination are temporarily disabled.
  • For the creation process, we should definitely start by considering an “edit” mode that would display all columns listed in the Live Data macro call. It would only be accessible if the user has the proper edit rights. From that, we could keep the process described in the first message, but also add an explicit “submit/save” button for non-power users. We can look into an optional “modal input” support later, and also make it default for mobiles.

Am I forgetting anything?