<n>The following is an analysis and brainstorming of a problem in generalized database browser GUIs, like those generated by the Quino metadata framework.</n> <hr> <h>The User Story</h> Let's start with the user story that generated this idea: <bq>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.</bq> <h>The Problem and a Quick-fix</h> Now, if you know the paradigm of <a href="http://encodo.com/quino">Quino</a> 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: <ol> It's not very intuitive to select "new" to indicate that one is finished with editing an object. The data you've entered for one object may have quite an overlap with the data you're going to enter for the next object -- but you have to enter the data all over again (the "templates" section below addresses this issue). The user isn't given any visual or workflow feedback that editing an existing object is any different than adding a new one. As far as the underlying technology is concerned, this is true; as far as the user is concerned, this is not. </ol> Anyway, once we'd gotten her squared away, we huddled back at <a href="http://encodo.com">Encodo</a> 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. <h>From Another Angle</h> In describing the problem to another, non-technical person with a fair amount of computer experience, the following ideas came up. <ol> The pattern the user seemed to be following was the classic dialog-based workflow, where you open a dialog, make some changes, then click "Ok" to save changes. Since there was no Ok button, the user clicked "Save" to continue. Quino applications now save changes automatically. Previous versions used the classic pattern of asking whether changes should be saved or discarded before allowing the user to move the focus away from the edited data. Users didn't like this because it got in the way far more than it prevented them from saving unwanted changes. The application is a data-browser which shows the details for individual objects in an editable format. This is highly convenient when browsing the data and making <i>edits</i> here and there, but not ideal when making doing mass data-entry (i.e. when <i>adding</i> data). That Quino displays new objects in the same place as existing ones without making a distinction is an accident waiting to happen. With auto-save mode, it's not even obvious how you can tell the application that you're done creating the new entry. The answer now is to either select "save" explicitly or to just click something else, like another object or the "new" button. The mix of the highly generalized data browser, the object editor and the object creator was too subtle to be learned intuitively, leading to disastrous workflows like the one described in the user story above. </ol> <h>Possible Solutions</h> <h level="4">Templates</h> 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: <ul> Standard: have a blank form as we offer now, in order to be able to specify every facet individually Cloning: pre-load the form for the new object using <i>all</i> of the values from another object Templating: pre-load the form for the new object using <i>some</i> of the values from another object </ul> <h level="4">Handling New Objects</h> 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 <i>not</i> saving a new object, but modifying data, which included <i>replacing</i> 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: <ul> Add a banner to the top of the form editor, indicating the current mode with text and an icon (e.g. "Editing existing object" or "Creating new object") Use a different background color for fields that have been modified from their loaded values so that the user can tell that they are being changed. This offers a hint that the object being edited is not a new one. Use a different background color for new and edit forms. Some combination of the features above or something else entirely. </ul> 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: <ul> Instead of closing the dialog when the user selects "Ok", Quino saves the object, but loads the form with a new, blank object so the user can continue to add objects. When an object has been added, but the dialog is not closed, Quino could show a banner at the top or bottom, indicating what just happened (e.g. "Object [title] was saved; creating new object."). This little message could fade out after a couple of seconds. Instead of simply loading a blank object, the user could select which template should be loaded -- or which object should be cloned -- to pre-fill the form for new objects in this data-entry session. When the user is working in this "batch data-entry mode", the "Ok" button might be renamed to "Save" and the cancel button might be renamed to "Close". The user can select at the top of the new-entry form how the form should be used: "single object" or "batch mode". In either mode, the user should be able to set a preference for which template is used by default. These preferences should be available from the new-entry form. The form should always show <i>where</i> in the hierarchy the new object will be placed. This could be displayed as a series of breadcrumbs or in a tree-view or some other cool GUI gadget. If validation errors occur, the form does not close in either mode (single or batch). </ul> 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.