UI Guidelines for Shift
0. Introduction
This document has two parts: first, a list of aspects of the Sophie UI that Astea feels need UI input, and second, a schedule listing when aspects of the UI need to be integrated into Sophie 2. (See also the release schedule.) This is currently a draft; as this document grows, it should show areas where Astea is in agreement with Shift and areas where more discussion needs to happen before work can be done.
Older documents:
1. Aspects of the Sophie UI
(Most of this is based on sophie_v2.pdf; a lot of this is based on parts of the Sophie UI that weren't touched on in that document that need to be addressed.)
1.1. Graphic look & feel (general)
I think the graphic look is generally good & we like it. The gray windows and blue details look nice.
One basic problem is in list palettes: we need to have a general idea of how all list palettes should work, not a bunch of different palette designs that behave in different ways.
1.2. Interactions (general)
Basic questions that need to be worked out:
- How much drag and drop is there in the interface?
- Can we drag and drop from palettes to HUDs?
- From HUDs to palettes?
- From book to book?
- Number of halos on frames: ideally, there would be a balance between easily accessible functionality & less potential for confusion.
1.3. Arrangement of flaps, tabs, and palettes
I think we're in basic agreement that things used to create books (resources, frames, etc) appear in the left flap, while things related to the structure of the book (page thumbnails, list of books) appear on the right side.
We should hammer down exactly what the tabs are and what they are for - Sophie 1 had tabs with the vague names "tools", "library", "resources" which proved to be confusing.
1.4. Halos and HUDs
One thing that would be extremely useful would be easily understood icons for the halos. These were vague at best in Sophie 1; this could be improved tremendously. This is connected to the arrangement of what's in each HUD; we can't have clear icons for halos if the HUDs contain a large variety of functionality.
1.5. Floating dialogues (find/spellcheck)
Some functionality in Sophie 2 is going to be in floating dialogue boxes - when the user presses control/command-F, for example, a window will pop up asking what you want to search for, like in other applications. This isn't how this was done in Sophie 1 (that was in the palettes); it would be useful to see how this could look.
1.6. Timelines
The way timelines were done in Sophie 1 wasn't wonderful and could probably be reworked.
One issue: in Sophie 1, every frame on a page had a timeline halo that was dragged to the timeline to move the frame to the timeline. (The frame itself wasn't dragged because the author presumably had positioned the frame on the page first.) This got the job done but it was confusing: most of the other halos did not behave in this way.
1.7. Embedded books
The way embedded books were handled in Sophie 1 - particularly the editing of embedded books - was confusing and needs to be rethought. (This has not been implemented in Sophie 2 yet.)
The main issue here is the problem of focus: you can have two books on the screen at once. In the Sophie 1 design, there was confusion because it wasn't clear what the status bar controls referred to (almost always the parent book, I think) and what the content of the palettes referred to (usually the selected book).
1.8. Page templates
The idea of page templates is confusing to a lot of people; a way to implement this that would be quickly understandable would be fantastic. In Sophie 1, users ended up having to spend a lot of time in the page structure palette figuring out which elements on the page were part of the page template
1.9. Reader application
The author application contains reading functionality; the UI of this shouldn't be too different from the authoring UI. The reader application, however, needs to have its UI thought through more carefully: many of the people using Reader won't have used Sophie previously. Because it's their first introduction, it needs to be easy to use; it should also be inviting.
(If we're planning on having Reader work in a browser as an applet, does all reader functionality need to be confined to a single window?)
1.10. Things that don't work
(This section lists things in the Sophie UI that don't currently work.)
2. Schedule
(This part of the doc lists when things should happens, milestones etc.)
2.1. Major Dates
2009-08-14: This is the first Beta release; most of the UI should be integrated into the product at this point so it can be critiqued.
2.2. Minor Dates
2009-05-13: When the first round of this document will be critiqued by Shift.
