-
Notifications
You must be signed in to change notification settings - Fork 0
States views overlays
This page contains notes and proposals about how to reconcile Maqetta's existing states feature with mobile views, overlay widgets, and stack containers, while attempting to establish a foundation for product growth.
With Maqetta, UI designers create mockups that are reviewed by their team members and customers. Maqetta becomes much more valuable as a tool if, in additional to being an individual tool for sketching out UI designs, it also serves as a team tool where team members can effectively collaborate on a UI design.
The primary team feature in Maqetta is the review/commmenting feature, where a designer can send email invitations to team members, who can then follow a hyperlink in the email invitation to enter Maqetta's review/commenting module. Therefore, my contention is that having an easy to use review/commenting feature is of high strategic importance because it determines how useful the team features are.
After observing users who attempt to use the review/commenting feature, my conclusion is that a good UI approach is to provide reviewers with a simple list of "views" that show the UI mockup in its various runtime states, and then provide the reviewer with dead-simple UI for navigating through the list of views so that the reviewer can be confident that he has seen everything that warrants review.
Some products that people use for UI mockups today offer the equivalent of "views" and simple UI for stepping through the views:
- PowerPoint. A "view" is a slide. The "next view" operation consists of going to the next slide.
- Photoshop. Some designers use Photoshop's Layer Composition feature to provide a list of "views". Each layer composition represents a "view". Users can go to the "next view" by bringing up the Layer Composition popup and clicking on the following layer composition. (Note that Photoshop layer compositions have a lot of similarities to Maqetta states. In both cases, the author chooses which elements are visible within the given layer composition or states.)
As mentioned above, Maqetta's existing states feature is similar to Photoshop layer compositions in that the author chooses which elements are visible within the given layer composition or states. Maqetta states have a couple of special wrinkles:
- Maqetta creates "live applications" where the designer can specify event triggers that cause state changes (e.g., onclick on a button can cause a state change)
- There is a default state ("Normal")
- In addition to simple visibility changes across different states, Maqetta allows arbitrary CSS properties to change from state to state
- Ultimately, we want to allow state changes to animate. (Most of the time, fade-in/fade-out animations)
- Ultimately, we want to enhance the existing states features to support a inter-dependent system of HTML pages, where different parts of an application are defined in different HTML files
Dojox.mobile's widget set provides some built-in functionality that overlaps quite a bit with Maqetta's custom states feature. If you have multiple sibling View widgets, the dojox.mobile library will automatically ensure that only one view among the siblings is visible at any given time. The dojox.mobile library includes some built-in event trigger logic.
(Note: in Preview 3, Maqetta page editor includes various features to align the authoring tool with this runtime behavior. The page editor enforces the requirement that exactly one View among a set of sibling Views is visible at any given time.)
The Dijit library has some special widgets that pop up as overlays in response to user events:
- Context menu
- Tooltip
- Dialog
- TooltipDialog
As mentioned earlier, I maintain that a key requirement is that reviewers have a way to step through all aspects of the UI. All of these overlays and temporary menus are things that reviewers typically need to see.
(Note: In Preview 3, various helpers have been added (eg, onSelect, onToggleVisibility) that are likely to help the page editor deal with these overlay widgets.)
A handful of Dijit container widgets derive from class StackContainer and all share the behavior that only one sub-pane can be visible at once.
As mentioned earlier, I maintain that a key requirement is that reviewers have a way to step through all aspects of the UI. Hidden panes are among the things that reviewers typically need to see.
(Note: In Preview 3, various helpers have been added (eg, onSelect, onToggleVisibility) that are likely to help the page editor deal with stack container widgets.)
Here are some features we would like Maqetta to support in the future:
- Allow UX professionals to use Maqetta to manage a entire system of UI mockup modules, where Maqetta can show the UI flow of an application across different HTML pages and screens within a single page. The idea is that Maqetta would provide various flowchart views that show the flow of the UI across the various modules
- All nesting of application states for certain types of widgets. For example, a Dialog calls for its own internal set of states
I think the term "view" will be more meaningful to designers than "state". Also, this makes it easier to explain how we manage Dojo Mobile views. By calling these things "views", then it will be more obvious and expected to a designer that Maqetta shows Dojo Mobile views under its list of "views" rather than its list of "states".
Most people would agree that states/views should be on toolbar rather than in its own palette. This is particularly important in the review/commenting UI where reviewers usually don't even notice the states palette in the lower-right corner. What I'm thinking is:
Views: [v] [<] [>]
where:
-
"View:"is a text label -
[v]is a DropDownButton. Clicking on this DropDownButton brings up a TooltipDialog or similar control that allows viewing/editing the current list of views -
[<]and[>]are buttons that allow the user to switch to the previous/next view
---------------------------------------
file1.html [CV+]
[-] [St] States
^ [Ds] Default
[Cs] Task added
[-] [Vs] Dojo Mobile Views
^ [Vw] View 1 [CV+]
^ [Vw] View 2 [CV+]
[-] [TC] tabcontainer1 (disabled if not in current view)
^ [CP] [CV+] (disabled if not in current view)
[CP] [CV+] (disabled if not in current view)
[CP] [CV+] (disabled if not in current view)
[-] Popups
[Di] Add new task dialog [CV+] (disabled if trigger not in current view)
[Mn] New menu (disabled if trigger not in current view)
[Mn] Edit menu (disabled if trigger not in current view)
[TT] foobar tooltip (disabled if trigger not in current view)
[TD] foobar tooltipdialog [CV+] (disabled if trigger not in current view)
---------------------------------------
where:
-
file1.htmlis the name of the current HTML file -
[CV+]on the first line above and on other subsequent lines is an icon that adds a new custom view to the current document. The[CV+]icon would also be available on any nested "view container" widgets such as Dialog or ContentPane. -
^is a placeholder for some sort of graphical indication of which view(s) is currently active. (Note: with nesting, multiple views can be selected at once.) -
[DV],[Di],[CV],[Mn]and other similar things on the left side of the listing above are small icons that indicate the type of view.[DV]would be a special icon for the default view.[Di]is a Dialog widget icon.[CV]is for a user-defined custom view.[Mn]is a Menu widget icon. (For widgets, use the same icons that appear in Widgets palette) - The notes
(disabled if ...)above indicate that Maqetta would need to do some analysis of the document model to determine if one of the event triggers for the given overlay widget is active at this time. For example, suppose a TooltipDialog is triggered by a DropDownButton with id="ddb1". If that DropDownButton is visible now, then the TooltipDialog would be active, else it would be visible but disabled.
When an item is selected in the view, additional icons might appear on the right side of that item. For example, if the author created a custom view (fka state) called "Task added", and then selects that view to make it active, 2 icons would appear right-justified on that item:
[CustomViewIcon] Task added [...] [x]
where:
- the
[...]icon would bring up a properties dialog for changing view properties. This might only be useful for renaming the view, but maybe we'll find other view properties that might need to be changed. - the
[x]icon would delete that view
See next section for what happens with mobile UIs.
[M4] Since we would now be supporting nesting, we need to think through scoping issues:
- Each view is scoped to its nearest ancestor view container. In the example above, if the root_view switches from the Default (sub)view to the "aaa" (sub)view, then this happens only within the scope of the View widget with id="root_view". Under the hood, what this means is that Maqetta does its magic updates of CSS properties in response to state changes only for widgets underneath the View widget with id="root_view".
- When a widget issues a "change view" call in JavaScript, the name of the new view is passed as a parameter (e.g., "view1"), along with the calling widget. Maqetta's logic then ascends the widget hierarchy looking for nearest view container widget that has a view of the name "view1" and switches to that view upon finding the first match.
For the following widgets, there will be coordinated updates to the Outline palette and the States list:
-
[M3]Overlay widgets (Menu, Tooltip, Dialog, TooltipDialog) - Selecting one of the these widgets in the Outline palette will cause the corresponding view to become the current view, and vice versa. -
[M3]Mobile view widgets (View, ScrollableView, SwapView) - Ditto -
[M4]Stackcontainer panes (ContentPane within TabContainer, Accordion) - Same as above, but we also need to coordinate clicks on the tabs in TabContainer and Accordion such that clicking on the tab causes:- corresponding ContentPane is selected on canvas and in Outline palette
- currently nested view becomes the ContentPane
I think "Default" is more meaningful to designers than "Normal".
- The default view is named "Default". For backwards compatibility, we might decide to equivalence "Normal" with "Default".
- The user will be required to enter a name for a custom view.
- For widgets that appear in the list of views, we will equivalence the view name to the ID on the widget. That means that any widget that acts as a "view container" must have an ID, so we will need to force an automatic and persisted ID onto certain widgets, such as Dialog, Menu, TabContainer, and ContentPane.
Ultimately, the dropdown menu on event properties should show the same list of views as the popup views palette.
[Future] To manage a system of HTML pages that collectively represent the UI for an application, Maqetta would need to analyze the document model as follows:
- Follow 'src' attributes on IFRAME elements
- Follow 'href' properties on ContentPane widgets
- Follow 'href' attributes on A elements
- We will have to enhance the dropdown menus for event attributes (e.g., onclick) to show a list of HTML pages in the user's current project. That way Maqetta can provide simple UI (and keep track of) cross-page navigation that is due to JavaScript logic (e.g., openWindow())
By nesting views or containers, one must choose a path of dependent states. However, with web pages and particularly with widgets, there are often independent interactions and the cross looks more like a matrix than a tree. Take for example a tab container with an overlay widget like a dialog next to it. There's a state that represents the tab selection, and another state that represents whether or not the dialog is visible. The two are not dependent on each other, so representing this as a tree, one would have to map out these combinations and duplicate either the dialog states under the tree states or vice-versa. The same could be true of any two independent widgets with their own states.
Adam says: "The two are not dependent on each other, so representing this as a tree...". It is true that the natural reaction of a user when he sees a tree is that there is some notion of hierarchy and containment. But note that, for Dialog, there is indeed a clear notion of hierarchy and containment in the case where a Dialog widget has content and that content has multiple custom states/views. If a Dialog is invisible, all of its embedded states are (for all intents and purposes) irrelevant because the browser treats display:none for visualization and layout purposes as the child elements are not in the DOM. Same thing for mobile views.
But for stack container widgets such as TabContainer, this isn't as clear cut. Each ContentPane child of the TabContainer could be an href (in which case there is a clearer notion of hierarchy and containment) or just inline content that could interact with the rest of the page (in which case things are fuzzier). The reason I proposed that TabContainer's children represent distinct states/views is that I'm thinking that the overriding UI concern it that reviewers have the ability to click through a simple list of states/views and that shows them everything there is to see in the UI mockup. If we don't include the various stack container widgets in list of states/views, then we have special case requirements on reviewers where for some things you navigate through the list of states/views and for other things you need to click on TabContainer or Accordion tabs. (Similar concern with mobile views).
What if we kept views (states) operating like the original davinci states feature, a simple list operating on the BODY element of the page, but made it possible to have additional lists of views affecting other parts of the page? So, rather than embracing views as a model for embedding complex relationships between widgets and letting the user go arbitrarily deep, additional views would be added (sparingly) to manage "special" situations, such as overlay widgets or mobile views. Perhaps the term 'views' breaks down here, and states is again more applicable, since it would be the combination of these settings which would determine the appearance of the overall page. It may be that only the top-level ones are user-editable, the ones associated with widgets have fixed behavior.
For a typical web page, the developer would be presented with a single dropdown and a simple list of states. Like the Sample1.html example, one might create an entry for 'add task', 'done', etc. Upon adding a widget with special interactivity, namely, interactivity which requires review comments in different configurations, helper code could add an additional list of states, such as a list of dialog states -- normal, dialog1_visible, dialog2_visible, etc. If tooltips are present on the page, another list would appear for tooltips. Note that dialogs and tooltips may or may not be mutually dependent. Mobile Views might also have a list, one for each view. The likelihood that all of these states would ever appear on a page is slim. Hopefully, the user would be presented with only one or two state lists for any given application.
The state list or lists could be selected, like they are today, either in the designer or in the review tool. It may be feasible to represent this as a series of dropdown controls or some sort of accordion control. However, because of there may be multiple widgets involved, it may be hard to fit this in a toolbar.
I'm not sure I fully understand. It sounds like you are proposing the list of states/views would look something like this:
---------------------------------------
^ Normal (default state)
Task added (custom state)
BlahBlahBlah (another custom state)
[-] Dialogs
Dialog 1
Dialog 2
[-] Tooltips
Tooltip 1
Tooltip 2
---------------------------------------
Adam: My proposal was that there might be three entirely separate lists. One with {Normal, Task added, BlahBlahBlah} one for Dialogs with {Dialog 1, Dialog 2} and a third with {Tooltip 1, Tooltip 2} The latter two, of course, would only be present if those types of widgets existed on the page. Add another such category for stackcontainer/mobile view type of widgets. The proposal does not take into account containment hierarchies and would not provide a programming model, just a way of making things visible for review & commenting and provide mutual exclusions by type. Note also that some states may not be reachable, either because of widget behavior (you can't programmatically demand that a tooltip become visible) or because of containment hierarchies (you may not be able to show a pane in a tabcontainer, for example, if it's contained by a dialog which is not visible)
If I've understood correctly, here are some comments, questions and issues:
- When I had crafted my original proposal above, my first thought was to group all dialogs together, all tooltips together, etc. But after further thought, I concluded it was better to intermix the dialogs/tooltips/etc. with the default state and custom states for two reasons: (1) As much as is possible, it is best to present a simple linear list of "states" or "views" to reviewers, and avoid as much as possible having them open/close tree container nodes or accordions. This caused me to change my proposal above to ungroup dialogs/tooltips/etc and present a flattened list, (2) The author might have in mind a particular sequence of states/views that he wants to present to the reviewer. For example, with Sample1.html, the second state "Add new task" really should be a Dialog widget instead of a ContentPane. For Sample1.html, the natural sequence is "default state", then "Add new task dialog" (an actual Dialog), then "Task added state". Because of the need to control the sequence of states, I have proposed allowing the user to use drag/drop to rearrange the order of states/views.
- You say "Hopefully, the user would be presented with only one or two state lists for any given application." Adam: I said state lists, not states... bad terminology here. I expect there could be many states in the current sense, just not that many additional lists of states types like dialogs, mobile views would involve Unfortunately, from what I've seen so far, in real-life I expect the typical Maqetta mockup of a single HTML page will have 10-50 states/views, even if the designer has gone to great effort to "modularize" his application mockup by leveraging iframes and ContentPane/href for isolating particular sections of the mockup into a separate HTML page. There are tons of nitty little details that a UI designers needs to put into his mockup, and usually each separate detail will have a corresponding custom state or overlay widget.
- You say "The likelihood that all of these states would ever appear on a page is slim.", but looking at user behavior so far, I expect there will be quite a lot of mixing of custom states, overlays and mobile views on a typical mobile UI mockup, especially when doing UI mockups for tablets, where more complex UIs are possible due to the larger screen. Adam: perhaps... but I'm talking about number of types, not number of states