prev

iDB Tutorial  (cont.)

Multi-Field Editing

In hand-held devices screen space is always a precious commodity. On the other hand, iDB tries to minimize the number of keystrokes and the number of screens one has to visit while editing records.

Hence, iDB's choice of editing the whole record in a single screen; -- a screen that is not big enough to display the keyboard and the whole record edited.

During the design of iDB user interface, single versus multi-field record editing has been discussed. iPhone's standard way of editing one field at a time (where an edit screen shows up and user would edit only one field on it, then, he/she is required to save the field and go back, bring another field into edit mode, edit, save, and go back..), a.k.a. "single-field editing", was considered too primitive. Instead, we chose "multi-field editing" for iDB.

Multi-field editing not only shortens the number of keystrokes and screens visited, it also provides the very final view of the record while editing.

The way multi-field editing enables you to do things below is completely different than anything else you've been able to do on your iPhone. You may want to read the following carefully, otherwise if you skip this section and expect regular iPhone behaviour while editing multi-field records, it may catch you in surprise.

In "multi-field editing", once in 'Edit' mode the whole records becomes scrollable and editable. You are free to scroll it anywhere any time, and edit multiple fields at once. This is more difficult to implement, yet more powerful and flexible than iPhone's seems to be the standard practice of single-field editing. The whole record is scrollable; you can put your finger to the side of the record, --but not on a field, if you put your finger on a field, that means you want to put the cursor on that field--, and then you would scroll the record up and down to the desired position.

In Edit mode, even the 'notes' field may become scrollable if the amount of text entered exceeds its visible area. You can than scroll the field and place the cursor on the field anywhere you want.

Let's take 'Logs' database type: Suppose you are editing the 'notes' field and it occurred to you it may be a good idea to add a related keyword.., into the keywords field that is guaranteed to be outside the visible screen space, hidden somewhere underneath the keyboard. Simply scroll the record all the way up, edit the keywords field, scroll down, and put the cursor back to the notes field at exactly where you left its editing.

Multi-field editing is especially useful if there are too many fields on a record; the alternative would simply require going back-and-forth, constantly keep saving single fields at a time, and come back to the edit screen for more and more fields.

During multi-field editing, fields will respond to tapping and even swiping motions. Hence one should pay attention to what he/she is trying to control or scroll. This may feel awkward at the beginning, but once you get a hold of it, it is a cinch.

Suppose you tapped on the 'notes' field of a record to edit:
 

Now, how can you append more text to existing notes? Well, just hold the 'field' (not the record) and slide it all the way up to get to the bottom:
 

Another problem: Suppose you need to go back and edit the 'title', which is now out of the visible screen. This time hold the 'record' (not the field) and slide it down to bring the title into visible area:
 

When two things won't fit to the visible screen area, they *both* become scrollable at the same time. In the case above both the 'notes' field, and the 'record' as a whole are scrollable.

In order to scroll down the whole record, you should hold the record on the side (not the 'notes' field), and slide.

Record Lists

When a database name is tapped, it brings the record list of the subject DB.

A record list may start changing appearance depending on the number of records it contains. A regular database containing a few records at the beginning, may end up having an alphabetical section headers, and an index column on the right side for easy navigation.
 

   

Or, a ToDo list without any sorting options, may start displaying a row of sort options:
 

   

That is because when there are only too few records, some options just do not make sense. Offering sorting obtions on 1 or 2 rows would have been laughable.

Here is another example: Once a record list gets screenful, sorting options may seem to disappear:
 

Where that's because iDB always tries to render the most relevant information. In this particular case, knowing that the user most likely is interested in seeing as many records as possible (rather than the options how to sort them), iDB scrolls the screen up one row, to show the maximum possible number of records it can display.

To bring back the sorting options, just scroll the screen down one row:
 

prev

next