...
...
|  Image Added | - This is the first preliminary design sketch which emulates a master-detail interface like that of an iPad app, and is designed to be relatively safe and efficient.
|
...
- Tabs at the top of the screen allow music directors to switch between modes (uploading and tagging).
|
...
- The entire interface is drag-and-drop-friendly, and responds to dropped files and URLs by uploading the corresponding file
|
...
- , improving efficiency and safety thanks to the large drop area and internal consistency.
- The left half of the screen is taken up by a list of uploaded albums which may be selected and shown in more detail on the right.
|
...
- This is externally consistent with iPad apps making use of the master-detail paradigm, improving learnability. Safety exists as, even when the wrong item is clicked, the right item may be clicked to correct the detail display.
- Albums may be deleted before entering the database by clicking on the "X" in the top right corner (for which the hot area extends into the "tabbed" area
|
...
- . The user will be prompted to delete, to improve safety. Since the operation is rare, fatigue should be avoided.
- Editing data is performed by clicking on any piece of text which acts as click-to-edit.
|
...
- The item which will be edited is highlighted on mouse-over
|
...
- to improve learnability, even though this may not be as externally consistent with other interfaces or internally consistent with the <textarea>. It may also be unsafe since the fields are relatively closely packed.
- Album art may be uploaded by clicking on the album icon in the top left corner of the right pane, and comments may be freely added at any time.
|
...
- When the data is approved as correct, the "OK" button may be clicked to upload the digital download to the database.
|
...
Image Removed
Analysis
Learnability
This design makes use of a number of features that are externally consistent with other UI elements. The row-based selection colors in the selected row which also responds by displaying the details in the right-hand pane, making it extremely obvious what the focus is at any given moment. Responsiveness to mouse events by changing the cursor and highlighting text to be edited increases the ability of a user to understand that the static text may be interacted with (and a simple click should reveal that it will open a text box). However, this is not externally consistent, as users may anticipate a proper text field to indicate that it may be edited, especially as the comments field is an obviously editable <textarea>.
Efficiency
The design is reasonably efficient. By allowing the entire page to act as a drag-and-drop area, the region in which to drop a link or file is proportionally bigger, making steering much less of a concern. Furthermore, by allowing links to be dropped like files, the consistency of the action demands no interaction with a text box nor does it require two different methods of interaction that depend solely on whether or not the file has already been downloaded by the user. By presenting an "OK" box to approve albums right away, making it obvious and visible on the right-hand pane makes it easier to glance over the information and streamline the process of approving albums that have minimal or no errors.
Safety
The design is relatively safe. Making the entire screen drag-and-drop reduces the chances that a user will fail to drop the file for uploading (as would be the case if only a part of the screen was active). Furthermore, by unifying the drag-and-drop action across both links and files, users will not suffer from a lapse that might otherwise occur if they were forced to copy and paste a link by hand but instead chose to drag and drop the link. The delete action in the top right corner of the right pane prompts the user for confirmation, as this action is dangerous. Although such prompts are not desirable in general, the rarity of the delete operation should minimize any familiarity with the dialog. Should information be required, the design may be made safe by preventing submission and highlighting missing fields. The least safe aspects of the design relate to the compact nature of each download in the left-hand list (it's possible to select the incorrect album, but this is easily corrected, especially if state is maintained when an alternate album is selected) as well as the compact nature of the editor fields (it's possible to incorrectly activate the album name editor rather than the artist name editor, for example).
Design 2
Design 2 focuses on an ultra-safe interface for interaction with recent play counts. Since the track count data digitally may only be partial (some plays may not make use of it or may depend on CDs), the design simply offers a preview of the plays with two additional buttons allowing the user to export the plays as an Excel spreadsheet or to Google Docs.
Image Removed
Analysis
Learnability
This design is extremely learnable. Only three major elements exist, and the distinction between "Download (as Excel)" and "Export to Google" is clear and obvious. The table of the preview should be consistent with previous external representations (i.e. existing Excel and Google spreadsheets of play counts)
Efficiency
The design is extremely efficient for the specific goal (viewing and exporting play counts for CMJ). The scrollbars on the table are self evident and sorting may be achieved by clicking headers. Downloading and exporting to Google Docs are possible with a single click and confirmation dialog.
Safety
The design is ultra-safe. As data is only viewed, no damage may be done to the data. Sorting the wrong column may always be corrected by clicking on the right column, while the "File Save" dialog that appears when the "Download" button is clicked, and the "Name the spreadsheet to save this as a Google Doc" dialog that will appear when "Export to Google" is clicked both feature "Cancel" buttons that allow a user to avoid irreversibly downloading or exporting to Google.
Design 3
...
- This improves efficiency because the OK button is available as soon as the details are revealed.
|
Sketch 2 | Image Added | - This is the second preliminary design sketch which emulates a wizard interface to improve safety over the first preliminary design at the cost of efficiency.
- A single upload may be dragged and dropped onto the app.
|
...
- Only one upload may be handled at a time, hurting efficiency.
- Once the upload is complete, the music director or elf will then be asked whether the default data is acceptable.
|
...
- If the data is acceptable, they
|
...
...
...
- will click "NO", which is placed in the
|
...
- corner far away from "YES", to avoid accidentally clicking "YES" when a "NO" is meant. The question "IS THIS OKAY?" is not externally consistent with other dialogs and may detract from learnability.
- If "NO" is clicked, a simple window-pane like interface appears (reminiscent of Windows 8), asking what is wrong with the interface, and presenting several options, one in each pane (e.g. "Title", "Tracks", "Artist", "Genre")
|
...
- . The consistency of the locations of these buttons makes this interface moderately learnable, especially if the buttons react when the mouse is over them.
- If one of the panes is clicked, the display focuses on editing only that field (e.g. editing "Genre" with a drop-down box for selection and button to add or remove additional genres).
|
...
- If "OK" is then clicked from the detail view, the details will be saved.
|
...
- If "CANCEL" is clicked, they will not.
|
...
- In either case, the user will be returned to the "What's wrong?" screen.
- When all changes have been made and nothing is wrong, the large "NOTHING" button may clicked to approve the album as is. The relative unusual nature of the "NOTHING" button (it is not externally consistent with other applications) may prove to decrease learnability.
- Once approved, or if "YES" is clicked initially, a "complete" screen is displayed.
|
...
Image Removed
Analysis
Learnability
...
- The screen should include a "BACK" button to allow the user to modify the upload if the user has grown used to the "YES" button.
- Since the two responses to "IS THIS OKAY?"
|
...
- do not show the same screen, it is possible that users will have a difficult time learning how to pull up the editor, as the two actions are not internally
|
...
...
...
...
- piecemeal nature of the design means that at least 4 button clicks are needed to edit even a single piece of incorrect information ("NO" -> (the incorrect value) -> "OK" -> "NOTHING").
|
Sketch 3 |
Safety
...
Image Added | - This is the "stretch" design that is designed to be ultra-safe.
- Since the track count data digitally may only be partial (some plays may not make use of it or may depend on CDs), the design simply offers a preview of the plays with two additional buttons allowing the user to export the plays as an Excel spreadsheet or to Google Docs.
- The simplicity of the design makes it extremely learnable, especially as the buttons are appropriately labeled and distinctly named.
- The scrollbars on the table are self evident and sorting may be achieved by clicking headers. Sorting the wrong column may always be corrected by clicking on the correct column.
- Downloading and exporting to Google Docs or Excel are possible with a single click and file-save dialog, leading to efficiency (due to the single click) and safety (due to the dialogs).
|