Speedy editing

[nicklasb]

Hi,

Just wanted to add an angle, I have a background with developing systems where people enter large amounts of data in the UI. I know that most people have never used those kinds of systems, and while they are not that different, there are a few things to learn. And if people want some ideas for new features.

People working professionally with accounting, financial transactions and similar, are not only often very fast(and in some cases mindblowingly zen and accurate), but there are some specific UI-features that they depend on:

1. Enter-to-tab When using the numeric keyboard, it is highly inconvenient to move to the next input field using tab. They use the other hand to handle receipts, statements, orders, settlements and so on. They always want to use enter instead. And the key is called "enter", after all.
2. Never navigating All enumerations or lookups have auto complete or some kind of search functionality. For example, the datepicker will almost never be used in some fields(entering historical values) and frequently in some(when entering "next monday") . Ideally the potential datepicker edit field could support some shortcuts, "NMO"=next monday, up/down for changing a day, the datepicker would be a click away, and so on. These are the typical date-features. Of course numeric values have masks, thousand separators.
3. Tab order The tab order needs to be very predictable. Perhaps that is possible to handle using existing code, don't know.
4. Most commonly used fields first The most commonly used fields should be first.
5. Keyboard shortcut for submitting When the most commonly used and required fields have their values, a keyboard shortcut is used to submit the data.

And then there is this general advice, especially important when working with input-intensive stuff: A UI is a contract between the user and the developer just like an API. Moving a field just because it "felt better to have it there" is not OK, especially if it messes up the tab order. I was actually, and literally killed for doing that once. So I am dead now because of changing the tab order.

[davidlgj]

:D Oh, I've been hit by the "don't mess with the tab order" when fixing a bug that led to wrong tab order... but they where used to it!

Some thoughts:

1. Could probably be done with an "useCapture" event listener outside of schema form.
2. This is harder, I guess it's up to the form you create and the add-ons you use?
3. I haven't payed any attention to tab order yet, but I guess this one should be fixable (is it broken?)

[nicklasb]

Well, this i is more thought of as a discussion on how to be more editor-friendly. The points aren't feature requests for ASF per se, I am thinking that there would have to be some form of community interation around these things.

1. Enter-to-tab would probably be handled a little on both levels, as some add-ons or field types use return inside themselves. A solution that put that problem as least half-way out of the ASF realm would be if add-ons in some way could be made aware of who's next in the tab order.
2. Yes, but with regards to the datepicker I mentioned it here as you are involved with that to and that it is a good example of something in the area.
3. Is there an explicit way to set the tab order? Because you can position inputs in several ways using CSS, and people(like me) seems to dynamically generate forms. Or perhaps this can be solved som other way..
4. Don't know why I mentioned that here. That was just a UX tip in general. :-)
5. This one seems on the ASF-level, though.

[davidlgj]

Sorry, I was in my "fixing issues" mode :)

1. I still think this is easiest fixed outside of asf, but we may need to add tabindex="" to all things tabbable, here is a fiddle i found when googling it: http://jsfiddle.net/n67rF/2/
2. These are the ones that would need most work since for instance the datpicker is just a wrapper around pickadate and would need considerable hacking to support this.
3. There is the attribute tabindex="", we don't have it right now, but it could be added and made configurable in the form definition.

[sjaakiejj]

I'd just like to add my vote of support for 3), we've run into the issue of tab order several times and always have to find workarounds for specific use cases. Being able to say in the JSON "this goes before that" would be incredibly convenient.

[nicklasb]

1. Enter-to-tab
   I would like to add a standard option for it. Then implement it in the ASF components and write up how it was done, it would then be easy for others to follow suit.
2. Date editors
   With regards to date editors, yes, there is work to do there, but perhaps not as much as one would think, I added stuff like that to a windows control a couple of years ago, and I didn't have to struggle that hard. The same hooks are available here. For some reason, there seem to be no decent date editor for javascript. Or at least I didn't find one in two minutes. :-)
3. tabIndex
   An alternative could be tabWeight. In CMS:es it is common to use "weight" instead of "index" for ordering of fields, because then you can just combine parts of different UI:s. Or order by how often something is used. Perhaps one even would not need a specific weight for tab order, just for field ordering in general. It is not common that they differ.

[nicklasb]

Hm. WRT point 2, Pickadate is quite extensible: http://amsul.ca/pickadate.js/api/

Here is an example that uses date.js: http://codepen.io/amsul/pen/cBuAl

Date.js is by the way very feature-rich: https://github.com/datejs/Datejs

[Anthropic]

@nicklasb is this one also ready for an update to a new enhancement issue with a specific request or still in need of discussion?

[nicklasb]

I feel that it is pretty specific, that would be if we split the points into projects. Except for 4, which perhaps could be omitted, they would all be major annoyances in any input-heavy situation.