Caret7:UI notes Aug3

From Van Essen Lab

Jump to: navigation, search

AGREED: Take an iterative approach to UI changes. Our primary focus as a team has to be two-fold: what can we deliver as a working prototype by the end of September, and how do we address the long-term need for an improved user experience, particularly with Connectome Workbench users in mind. All of the proposed design changes will have to go through a “reality check” filter by the developers to determine what makes it into the prototype. However, it’s important to consider the broad ramifications of future design directions now, while we have the hood open.




TABLED: Support multiple open Spec Files. This was briefly proposed, but not enough is known about the use cases that would require this functionality. More research is needed, and more issues related to Spec File management are expected to emerge, such as:

  • Simplifying the user experience of creating Spec Files
  • Exploring natural connections between ConnectomeDB and Workbench to assist the creation and management of Spec Files
  • Explore a use case for “Template” Spec Files
  • Migrate Connectivity data and the “Connectivity Selector” into the Spec File.

As an action, I would like to set up a demo focused on Spec Files with an experienced Caret user.




AGREED: Separate controls that are Window Specific from controls that are application-specific. This is a broad design direction that appears to have a lot of buy-in, but also has inherent complexity and a host of attached issues that were also discussed. These include:

  • Proposed “Canvas” view of the application (TABLED)
  • Proposal to create a new “Main Window” that is not an image viewing window (AGREE TO EXPLORE)

In general, there is a need to rationalize Window Controls (AGREE TO EXPLORE)

  • Create distinct control groups for 2-D views vs 3-D views.
  • Create (or promote) precision controls for 3-D Orientation.
  • Create (or promote) “Save View” control.
  • Reorient “Manage Loaded Files” control and “Spec” button.
  • Create a way to manage menus (such as “Model”) that support multiple selections.

As next steps here, I will continue Jenn’s work in mocking up window-specific and application-wide menu treatment options. I will also continue user and developer interviews to explore the separation of controls, particularly the complexity of the Display Control command set. We will have new mockups to look at in next week’s meeting, exploring several options with the intent of settling on a final direction as a group. However, due to the complexity here, this will likely require multiple rounds of design and review.




PROPOSED: Use “Dockable” Command Palettes rather than windows. We are too early in the game for this to be “accepted” by developers, but received enough positive feedback as a concept for us to explore further in mockups. Related: • PROPOSED: Use color theming to connect control windows with viewing windows.




PROPOSED: Provide more granular “YOKE” controls between windows. This relates to multiple suggestions that were put on the table, including: • Create a new 3-D view that allows left and right surface hemispheres to be rotated (or “mirrored”) along the same axis. • Yoke any two windows to each other, without necessarily yoking to the “primary” viewing window. • Enable (and manage) multiple yoke relationships between windows.

This is a complex problem to manage, but one that could become very useful if we can come up with an elegant way of managing the interface. Mockups will be required. I am hopeful to include these in next week’s review, but may slip to the week following.




PROPOSED: Create multiple cursor states and “tool” commands for different operations (i.e. orientation, drawing, selecting). This received a lot of positive feedback, but will need mockups to clarify. These will be delivered next week.

Personal tools
Sums Database