Minimize interactions for rapid data entry into cells

[seancolsen]

Discussed in https://github.com/centerofci/mathesar/discussions/3233

^{Originally posted by **MrChadMWood** October 4, 2023} In the current state, highlighting cells do not make them editable: Non-Editable:  This makes typing in data manually a little slower, as every cell requires double-click with the mouse. ### Feature Request: Add the ability (or option) to type into a cell once it is highlighted. This way users can navigate across cells while entering data more quickly by -- for instance -- pressing tab, entering the data they want, pressing tab, entering the data they want, ...

[seancolsen]

@MrChadMWood One small work-around that may help is the Enter key — pressing it converts the cell to edit mode. So your workflow could look like this:

1. Enter
2. Ctrl+A to select all text within the cell
3. Enter new data
4. Tab or Enter to save changes

[seancolsen]

The behavior that @MrChadMWood proposes here is how I would prefer that Mathesar works — like a spreadsheet.

I proposed exactly this behavior very early in our UX design process.

However @kgodey disagreed, making a case for adding an extra step:

I think we should err on the side of not entirely replacing data in the database based on quick actions. We care about data integrity. If the user accidentally types a, then they can remove the a if they make the mistake. If we end up replacing the content of the cell, then they can't recover their previous data, which sounds scary, especially since we don't have undo yet and we've removed it from the plan for the alpha release.

@kgodey later said:

we'll have user feedback to help make the decision.

Now that we have some user feedback, would you be open to reconsidering, @kgodey?

[ProfessorDisociate]

Thanks for the explanation, I actually appreciate the effort to preserve integrity.

My use case is but one, however personally I would enjoy the privilege to make these decisions as the admin for my users. My use case is to create a tailored (safe, easy) way for business users to interact with some data that they own. I would like to gauge what “safe” is in this context.

I like the idea of adding a timer. I had considered this:

Given, if a sort of cache/queue/buffer is implemented to store unprocessed queries.

There could be a toggle option for “quick mode” that turns on the queue for unprocessed queries (at the same time, allowing edit on highlight).

While the “quick mode” is turned on, there could be a timer. Alternatively, there could be a “COMMIT CHANGES” button somewhere, with a “warning: {n} unsaved changes” next to it. n being the queue’s length.

Lastly, it could be up to the admin to either enable or disable this feature for users.

[ghost]

@seancolsen Can i work on this..?

[ghislaineguerin]

@ProfessorDisociate, thanks for your input. I think your 'quick mode' idea is worth exploring, as it makes sense for users to prioritize speed of entry over safeguarding integrity when necessary.

You've mentioned the need to make other decisions in this context; I'm curious to hear what other ideas you have in mind for admins managing user interactions in Mathesar.

[ghislaineguerin]

@seancolsen, as I mentioned in Matrix, collecting use cases involved a lot of data entry across multiple rows, and double-clicking each time was frustrating. Additionally, being able to start typing should also apply to linked record fields, although I assume this could be a separate issue.

[seancolsen]

@Thanush66 no, this issue is not ready for implementation yet since it it still status: draft. We first need more agreement on our intended behavior. Specifically, we need to hear from @kgodey who had previously voiced concerns over the behavior which this ticket proposes. Then, if we do decide to make this behavior user-configurable, we'll need to do UX design for that configuration functionality first.

[seancolsen]

lol turns out I already opened a ticket for this last winter #2381. I closed that as a duplicate, but I do want to paste the "Considerations" I wrote there because they'll be good to keep in mind if we move forward with implementing this at some point:

Considerations

• We should ensure #1116 is also implemented before cutting a release with this change (to mitigate against inadvertent edits).
• In some types of cells I can only enter certain characters in the input (e.g. Number). What happens when I have selected a Number cell and type a z character. Do I enter edit mode? If I do, is the content of the input cleared? Ideally I would not even enter edit mode, though I'm not sure how easy that will be to implement. Alternatively, I think it would be okay to enter edit mode but retain the content of the input.
• FK cells do place the user's focus on an input element, but it takes time to fetch data before we render that input element. This is tricky, especially if the user enters many characters rapidly while the record selector is loading. Ideally we'd be able to capture that input while the record selector is loading and transfer it over to the record selector once loaded. It would be especially cool to have an input within the FK cell that shows the user's search query as they type while the record selector is loading (with some kind of loading indicator in the cell too). This seems possible, but probably lots of work. So I think keeping the current behavior of "Enter to launch the record selector" would be fine for now.

[seancolsen]

We discussed this issue during today's product approval meeting

Some notes:

• Kriti: ideal solution in my mind would be to have a mode that you can toggle between. Different people might have different needs. On a production DB, you might not want to edit that easily. We should have a default and the support the ability to toggle.
• Pavish: I don't think we should have a toggling state. We should go the "Apple" way — there is one way to do things.
• Kriti: we should be thinking about the problem rather than the solution
• Brent: improving data entry is very important
• Brent: seems like OP didn't know that you could press Enter to enter.

Outcome: this problem is worth solving, we just don't know the solution yet. We need to clarify the requirements to determine which direction we'll head.