From Glom
< Development‎ | UIReview
Revision as of 09:29, 3 May 2010 by Danielb (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Purpose of the Application

For administrators (developers?): Create database layouts and associated meta-information to make it easy for users to enter and modify data. (TODO: Is this correct/sufficient?)

For database users: Provide an easy to navigate interface to the created database layouts, which allows entering new datasets, finding and editing existing datasets, and printing database reports. (TODO: Is this correct/sufficent?)

Current approach: A single application with two modes (developer/operator). Both modes allow entering and editing data, but the developer mode unlocks additional capabilities. The bunk of these capabilities is located in a single "developer" menu, leading to various dialogs.

Advantages of current approach: Shared functionality is not duplicated. Developers can develop and test the database layout from a single interface.

Disadvantages of current approach: Functionality is often unnecessarily complex for users, which do not need access to developer related functionality. Developer functionality is largely cramped into one big menu and many separate windows. Code complexity.

Aim: Reduce complexity and clutter when Glom is used as a database viewer. Improve general usability for Glom when used by developers.


[TASK] Dialog titles should generally match the menu item. See [Title Format]

Currently broken by:

Import => Open CSV Document || Suggestion: Import => Import CSV Document Fields => Field Definitions || Suggestion: Field Definitions => Field Definitions Users => Groups || Suggestion: User Groups => User Groups

[TASK] Menu items should be ellipsized if they require further input. See:

Applies to: Open Save as Example Export Import Possibly to "Print -> Standard" (that item doesn't work for me) Add Related Table Test Translation

Usability Issues

  • Quit is ambiguous, as it is not clear whether the button will close all windows. Quit is usually only used in single-instance application, where "Quit" closes all windows (as opposed to "Close"). Glom is not single-instance however, so it can be confusing if the user opens a second instance of Glom.
  • The most common task of opening a recently opened document could be easier. It requires two clicks and the items are fairly small in a fairly cluttered environment.

[PROPOSAL 1] On the welcome screen, move a limited number of recent items to the top, adding "New Document" as an additional option underneath. Move network sources underneath (maybe only show the entry when network sources are available?). Remove hierarchy for simplicity. Examples are limited in their functionality.

[PROPOSAL 2] Allow single click activation of items, either by making them buttons (with or without relief) or a single-click list view. Remove the "Select" button.

[PROPOSAL 3] Make items bigger and add more information (e.g. database name, type of database, specific icons, date of last access). Make welcome dialog larger if necessary.

  • Creating new databases is confusing. The first thing a user ends up with is an empty "Tables" dialog. When closing the dialog, the "No tables" alert appears. When opening the document again, the Tables dialog appears but cannot be edited (because the document is now in operator mode). Examples are very limited.

[PROPOSAL 1] When creating a new database, guide the user through the creation of the first table. In the most simple case this could be accomplished by creating a first table and highlighting the name field.

[PROPOSAL 2] Do not allow this dialog to be closed without creating at least one table. Inform the user that one table is required when he/she tries to close the dialog.

[PROPOSAL 3] When a document is opened that has no tables yet, start in developer mode.

  • Generic abstract boxes can be confusing. The standard layout of "Add / Delete / Open" makes it easy to lose track. "Open" is not always the most descriptive term. Everything looks very similar and opening dialog over dialog is seldom the most efficient way to do something. In many cases there are multiple ways to do the same thing, adding complexity where it is not necessary.

[PROPOSAL 1] Use more descriptive terms than "Open" where-ever appropriate. E.g.:

On the main screen -> "Details" Edit Print Layouts -> "Edit" Edit Tables -> "Select" Edit Reports -> "Edit" Field Definitions -> "Values & Formatting" or "Settings" Relationships -> Remove the button (it doesn't appear to do anything)

[PROPOSAL 2] When opening a field definition from the Field Definitions dialog, do not show the first tab which duplicates settings already accessible from the Field Definitions dialog (aside from "Auto-increment" for some reason?).