The following is an analysis and brainstorming of a problem in generalized database browser GUIs, like those generated by the Quino metadata framework.
Let’s start with the user story that generated this idea:
“A user was entering data using our database software and complained of losing data. After verifying that the lost data was not due to an obvious software bug, we determined that it was because of how she was assuming the software worked. That is, she would use the application to browse to the location where she wanted to add data, create a new object, fill out its fields, then save it. For each subsequent object, she simply filled out the form again and clicked save to save it.”
Now, if you know the paradigm of Quino applications – and, indeed, most modern GUI applications, you’re going to see the problem: instead of creating a new entry every time she clicked save, she was simply saving the current object, then editing that same object, then overwriting the previous changes. After filling out the details for dozens of objects, she had only one object saved in the database.
One fix is to improve her training so that she knows how to create multiple objects with a Quino application. That is what we did, so that she could continue with data-entry and get her work done with the current software. A better workflow for entering new records is to select “new”, fill in the data, then select “new” again to store the existing entry and create a blank form for the next entry. A few problems are immediately obvious:
Anyway, once we’d gotten her squared away, we huddled back at Encodo headquarters and asked ourselves how we could avoid similar problems in the future. We agreed that it was a difficult problem and had to break up after a bit to attend to more pressing matters. The problem continued to swirl around in our collective subconscious, though.
In describing the problem to another, non-technical person with a fair amount of computer experience, the following ideas came up.
As mentioned above, when we create a new object, the data entry form is empty, save for a few default values (set from the model) and the parent object on which the object is being created. However, the user might want to do one of several other things when creating a new object:
In the case of “Cloning” and “Templating”, we run into the danger that cropped in the user story above; namely, that the form is in the same place as the object being cloned or the last object displayed, but it is now showing either an exact copy or a partially filled object instead. An object that is new and unsaved. How can we let the user know that this object is new and unsaved and, conversely, how can we let the user know that when they are making edits to an existing object, they are not saving a new object, but modifying data, which included replacing existing information with new information.
One way to handle this problem is to leave the GUI as it is, but to use color or decal hinting to let the user know the object state. We could do this in several ways:
Another way to handle the problem is to separate the tasks of editing existing objects and creating new ones. A paradigm to which users are well-accustomed is the dialog box “Ok/Cancel” one. Open a dialog, fill in the data and click ok to save it or cancel to abort. The way the Quino data browser works right now is that Ok and Cancel manifest as “Save” and “Revert” in the toolbar (which is not so clearly connected to the object being edited or created). This is not really that intuitive, especially when considering that editible objects can be nested.
The navigate to an object and edit-in-place concept is a good one and one which seems to cause little trouble with users. What if, however, we were to change the data entry mode to use a separate window instead? Instead of simply loading the new, empty object into the panel where existing objects are edited, we open a modal dialog showing the new, empty object instead. There is little room for error as the user must select “Ok” or “Cancel” to exit the dialog, making an explicit choice to save or discard the new object. The dialog cannot be closed with “Ok” unless the object validates successfully. When the object is saved and the dialog closes, the form from which the dialog was opened is focused on the new object, which appears in the browser in the tree(s) and/or list(s) where it belongs.
The feature above is quite a bare-bones approach and we can do much better. For example, we could offer the following improvements:
It seems that, with such an approach, Quino would offer a much more streamlined and intuitive method of mass or single data entry with far less of a chance of users getting confused by the combination of the global toolbar, auto-saving and the mix of browsing and data-entry.