(This was sent by Milo 2 April 2009.)
Sophie 2.0: Application Interface Design Concepts
As we discussed, we are sending you the feedback about the initial interface design for Sophie 2.0.
Here is what we think:
Positive issues
- Icons
- Book opened (templates, flow represantation)
- Book closed
- Frame icons (flow, non-flow, etc)
- Grey texts (for drag and drop)
- Selected frames (dashed border) and frame move halo
- Page selector
- Tabs for different modes - frames, no frames and test
Features that need to be improved
- Current flow representation (page preview) supports only flows on nearby pages
- Page preview should be page layout independent
- All scrollbars should have or don't have arrows
Features that need to be changed
- Consistent flaps, tabs and palettes - most of the book editing controls should be in palettes
- List palettes - should be with icons of same size and text(and scrollbars). Can contain buttons
- Meta palettes - contains text (and scrollbars). May also contain buttons
Missing features
- Book window - Because Sophie 2 Author is a multi document environment, we need to be able to drag things from one book to another
- Book desktop - live background that has page elements. It consists of one page only.
- Opened books tabbar - should represent menu with buttons for each opened book and show Desktop icon
- Timeline management and editing - probably palettes, but where to put them? On bottom flap is the solution of Sophie 1.
- Halo grouping - how to group halos because now we do have a lot of halos
- Palette grouping - in which flap to put which palette? The Reader app should have some controls and should be with one or two flaps (left and bottom)
- Menus - if there is really simple alternative that covers all of the functionality, we probably may leave the menus, but for now they are needed
- Tooltips - almost each element will have one
List of functional elements
To work on a common language here is a list of functional elements that present in Sophie 2.0 and the way we see them
Window
A window is a rectangular portion of the display on a computer monitor that presents its contents (e.g., the contents of a directory, a text file or an image) seemingly independently of the rest of the screen. Windows are one of the elements that comprise a graphical user interface (GUI). Each window has its own Title Bar. When the content is bigger than the visual working area of the window, scrollbars appear. Note that content is defined for specific elements.
Dialog
The dialogs are windows which have only basic functionality. Dialogs are windows that provide non-editing functionalities (outside of book editing itself) and provide information - opening, saving, information for books, errors, etc. It is not necessary for a dialog to be related to a specific book.
Book desktop
The book desktop is an improvement of the workspace introduced in Sophie1. It is a work background but with the features of a book that has only one page.
- Desktop covers the whole work area and can be overlapped by flaps.
- Desktop has its own resources which can be used in other books
- Resources can be dragged from and to books desktop
- Minimize all books shows the book desktop
- Probably timelines won't be needed in the book desktop
- Scrolling behavior will remain the same as in the other books - scrollbars where needed
- The Desktop book doesn't have it's own book window - it uses application window as a book desktop.
Flap
The flaps hold most of Sophie’s functionality that the user can’t get at through the halos and HUDs. Each flap has tabs in it; each tab has palettes.
Tab
Tabs allow for the selection of data sets to be displayed. Data associated with a tab is accessed through a single click of the tab. Tabs may contain one or more palettes. Tabs present a title that is visible to the user (such as "tools", "books", "pages", etc.)
Palette
Palettes give control over application or book element features. Palettes are loaded automatically or as modules. Palettes can be unloaded by unloading the corresponding module.
- Palettes that control by dragging between layout elements
- Some list palettes allow dragging elements to the Book Desktop or a book window (from resources palette for example)
- Dragging a page element to a palette is also possible, for saving templates for example
- Palettes that control by dragging elements inside the palette
- Some list palettes allow editing by dragging elements inside the palette.
- Page preview palette - for reordering pages
- Timeline palette - by dragging timeline entry frame box
- Palettes that control by other elements
- Buttons - for example the plug-in configuration palette
- Fields - some palettes may contain text fields
- Preview palettes - contain only preview (text or media) and no controls
Button
Buttons trigger specific functionality. This may be
Bound Control
- A Bound Control gives the on-the-fly changes functionality. This means that changing a property/group of properties is done immediately, without clicking Apply or OK buttons. All of the changes can be undone.
- Bound controls are part of huds, dialogs or palettes.
Halo
- Halos are icons that invoke HUDs or some functionality. Different items in Sophie have different kinds of Halos.
- Halos are showed when an element (book element) is selected. Displaying halos is relevant with what can be done with this element (book element).
HUD
- HUDs are windows that provide information and control for a specific type of object.
- HUDs are triggered by Halos.
Work Process
The list above is neither complete, nor accurate. The most important thing that we need to define is how we are going to proceed. We need to build the following:
- Kinds of visual elements - such things as Flap, Tab, HUD, MenuItem etc.
- Application structure - tree of visual elements.
- Behavior and appearance of each visual element kind.
- Specific / concrete visual element appearance and behavior.
- Appearance and behavior of the whole application.
It is not hard to see that (2) and (3) depend on (1), (4) and (5) depend on (3) and (2). With this dependencies, it is reasonable to assume, that we should attack (2), and (3) after we have at least basic idea/agreement on (1), and we should attack (4) and (5) after we have at least basic idea/agreement on (2) and (3).
Please note, that based on the size of this product, it is critical to define (1), as it will simplify both the communication, and the way UI design can be implemented from our team.
Based on this, I suggest that we work the following way:
- Increase the communication
- We should continue having meetings regularly
- However, meetings with all the participants, can not be frequent/effective enough, so either we should have meetings with less people, or some of the communication can just be done by mail.
- Since Shift Global needs lots of information, it is best to just request it from us, so that we can provide it quickly.
- Show / discuss drafts.
- In order to reduce the amount of work, it is better do discuss partial designs, drafts, etc. This way Shift Global can send us wire frames, incomplete interaction descriptions, etc, so that Astea can provide early feedback.
- The same way, when Shift Global needs some information that is not yet fully specified, Astea can send a draft, with approximation of what should the final product have.
- Define the schedule.
- Since both sides have finite amount of resources, it is a good idea to define a schedule or number of iterations with specific dates and goals. This will clarify the responsibilities of both sides.
Overall, I am very happy with the initial interface design. I know that programmers and artists think in slightly different ways, but I see that Shift Global have very talented people, and I am confident that we will figure out the best way to work and to produce a really nice product.
Best, Milo
