Forms¶
Simply the fastest and least error-prone data entry mode known
pb: With the added benefit of being hard to code :)
djp: yup ! jus plain nasty !
forms
Question; what's the very quickest mode of data entry ?
What if you have a giant stack of contacts to enter by hand or someone was giving you contact info over the phone ?
alternatives;
- pure CLI (as is now) is not too bad, but you have to be concerned about clean syntax and you have to type all of those attribute name and remember what they are and how they work. pb: plus, it has to be right, otherwise command fails.
- prompted input (as in tcy's suggestion above) to have the program ask you for each [attr] one-at-a-time and in a fixed order, maybe faster than the CLI, but what if you screw up and have to go back ? what if you just want to quickly enter two values ?
nope, neither of those will satisfy under time-pressure. The answer here is to take a page from spreadsheets of old;
data forms
It's half way between the (i)nfo screen and the (e)dit function. Where (thanks to Paul and ncurses) a full record is presented like the (i)nfo report, but with the fields laid out and the values in little edit boxes which you can move to and from. I can't recall seeing a form-field sort of function, in an ncurses app, but if it's reasonable, this might be another desirable edit mode.
maybe (e)dit is for a form-fields interface, and (E)dit if your text editor. Of course, what is "best" here is entirely subjective.
pb: Quick! Get me a bucket.
djp: I had a sneaking suspicion, that adding a whole new interface (data.forms) might induce nausea.. but can you think of a quicker data-entry mode, or one less error prone ?
pb: I cannot. You are right. ncurses can be used to create forms. I'd rather be lying on a beach, but forms are doable.
implementation¶
The interactive "forms" mode is, in many ways, just another list, but with the ability to change elements, one-at-a-time.A forms screen is paired with an info screen, and the two should be similarly named (ie info.task - form.task) and either name should always be displayed at the top left of the status bar, right after the application name; task..
The overriding design principal here should be; "as little design as possible"
the order that forms elements are listed should be as "close to the metal" as makes sense.
That is to say that the forms list order is generated, not decided upon.
There should be the bare minimum of modes, gadgets and gizmos, just enough, to get the job done.
for forms I propose a two column listing with attribute labels on the left and values (to be changed) on the right
The cursor move down and up the left column of the list with the up and down arrow keys. The left and right key move the cursor from the left column (default) to the right column, but once the cursor is in the right column, the up and down arrows no longer move the selection up and down, but cycle through choices (if any) or directly edit the value of that attribute. If there's a default choice, it should be seen, if there are other choices, that should be indicated. Moving the cursor back from the right side (edit) to the left side (labels) saves the modification. <esc> jumps back to report.info without saving changes.
<enter> saves any changes (if any) and moves directly to the next value down the list (ready to edit) and if the user is looking at the forms edit screen, but hasn't moved the cursor to make a selection, then hitting <enter> drills down one level (the text (E)ditor)
In other words, if you have one item selected in any report (list) and you hit <enter> you are taken to the (i)nfo screen, <enter> again and you are looking at the forms (e)dit mode, <enter again (with no changes or selections) to open the record in your text (E)ditor.
forms behavior restating;
from listing with ONE selected item
(e)dit goes to forms edit mode, or
<enter> = (i)nfo
<enter><enter> = (e)dit form (don't select anything and hit <enter>) is
<enter><enter><enter> = (E)dit text
but with MULTIPLE selected
<enter>
(i)nfo (shows all info output sequencially on screen)
(down arrow would select a WHOLE info entry at a time, for individual edit, via forms)
(just <enter> goes to forms mode, same sequencial list of records as info, all fields exposed, but ready to edit via forms) (same as (e)dit)
<enter> with nothing selected here.. should go a forms list of all tems, to the the first value, ready to modity
<enter> with arrow-key-selected forms field (multiple not possible) and cursor moves to the right, ready to change the next value
<enter> (changes saved) cursor moves DOWN to the next value
should be possible to <enter><enter><enter>(change value)<enter><enter>(change value)<enter> all the way down (around?) the form
.
command line uselessness¶
Although forms is entirely an interactive thing, we might learn things for CLI use.
interactive use¶
(e)dit
comments¶
form.color
the interactive way to customize the theme, changes should be applied immediately.