• Created by Unknown User (dmiao@mit.edu), last modified by Unknown User (pipian@mit.edu) on Mar 10, 2013 20:18

Sketch 1

  • 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. This improves efficiency because the OK button is available as soon as the details are revealed.

Sketch 2

  • 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 "YES". If it is not, 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. 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 consistent.
  • The 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

  • 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).
  • No labels