DEVise Interface Concept


DEVise Interface Concept 1

My main goal for this concept was to create an interface that would be more efficient, easier to use, and more pleasant to look at than the current DEVise interface. In order to accomplish this, there were three main goals I took into account:

  1. Using familiar design patterns that would make using the DEVise software relatively intuitive.
  2. Creating a visual hierarchy that would allow information to be presented according to its necessity.
  3. Creating a greater level of consistency in the aesthetics of the interface.

With these things in mind, I continued to research the project and similar projects and worked to develop an "ideal case" concept of what the interface might look like.

Research & Inspiration

When researching for this project, I attempted to look at similar applications to see how they had handled the interface design. While some may have been better designed than the current DEVise interface, they were rarely intuitive and even less frequently did they look decent1. While these applications can get away with a lack of intuitiveness due to their specialized user base, it seems that the DEVise project needs to be more accessible to a general audience.

With that idea I decided to model the interface after something that nearly every computer-literate person has experience with: the internet browser. In many ways the DEVise interface has the same purpose as an internet browser; it is a portal through which its users interactively consume information. Because of this I borrowed several of the internet browser's main components: the toolbar (including "stop" and "reload" buttons), the "throbber", and the status bar2.

The concept I came up with that made an attempt to emulate the modern internet browser whenever it seemed helpful, while maintaining certain elements that are specialized to the DEVise application's purpose. I attempted to make it appear as a stand-alone application rather than something that is simply embedded within a web browser. Ideally this concept would be presented in a separate Java window rather than within a browser window, to avoid redundancy between the similar interfaces.

Design Specifics

Here I'll break down some of the specific design choices I made for this concept.

The Toolbar

The toolbar is essentially a place to put the most often used and/or most necessary functions of the interface. I used an icon-based menu system3 so that the functions of each menu would be less ambiguous, and the drop-down menus are identified by a small arrow next to the icon. In addition, I attempted to separate certain functions that I thought should be given a more prominent place on the toolbar. For instance: in the current DEVise interface the "Restart Session" option is located within a separate "Session" menu. I thought it probably deserved a more visible place on the interface, so I paired it with the "Stop" button on the right side of the toolbar -- making the icons of both buttons red in order to signify their importance.

The "throbber" in the far left-hand side of the toolbar has the simple task of notifying the user when the application is busy talking to the server or running commands by displaying a simple animation. Although there is a similar function in the current interface, this version is simplified to the point where it tells the user one thing; "I'm busy".

The Status Bar

This element is inspired by the status bar in most internet browsers. It's main purpose is to display information that is of secondary importance, or more detailed information that the average user may not necessarily need. Included in the status bar is mostly information pertaining to server communication and status. To the left are the "SPR lights" which indicate what kind of actions the applications is performing. Next to that is a text-based status message that indicates the server communication mode (Socket, CGI, or Collaborative), as well as an indication of the duration of time until the application is ready. On the right side are two fields used to display X and Y coordinates of the cursor - something that is useful but probably not essential enough to be placed on the toolbar.

View Display

One of the main changes within the actual visualization was an attempt to differentiate control views from visual information views. The distinction between these two is that the visual information views (graphs, maps, etc.) are the most essential part of the application, whereas, the controls simply exist to manipulate these visualizations. As you can see in the example, the menu to the left and the scroll bar on the bottom of the larger JMOL-based view are both visually integrated into the rest of the application's "chrome". In opposition, the JMOL visualization and and graph both maintain a separate visual styling (in this case the same styling that is used presently) to assure that they stand out. Separating the control elements like this should, hopefully, make them easier to identify and less likely to compete with the more important visual content.

Also, in order to save screen space within the view, I proposed separating certain kinds of information into separate windows. Most notably, separating developer features into a separate "Debug" window, and separating the color-coding legend into a "Legend" window.

Window Management

One thing that seemed to be fairly important to current users of DEVise4 is the ability to resize the window to better utilize a larger monitor's resolution. The idea here was to allow the user more flexibility as to how large the JavaScreen would be, as well as giving the option to launch the JavaScreen in a new window. Additionally, it seemed like it might be helpful for the user to launch the JavaScreen at full screen to maximize screen space. I had initially begun implementing this feature using JavaScript, but it then became apparent that much of the window sizing could be controlled within the Java Applet.5

Additionally, with the possibility of having several secondary windows associated with a JavaScreen, it seemed that it might be helpful to be able to manage open windows. While the proposed "Legend" and "Debug" windows are easily reopened from the toolbar, some JavaScreens also have additional content-based windows that are integral to their usability6. Because these windows open automatically when the Applet is first opened, it is difficult for the user to figure out how to reopen them if the window gets closed. Because of this it seemed logical to include a "Windows" menu that would list all available windows, and allow the user to reopen windows easily.

Next Steps

This design was conceived as more of an "ideal case" concept, deliberately ignoring how difficult or easy some of these features would be to implement. The next step is to evaluate the possibility of implementing these features, and to develop a realistic timeline based on that evaluation.

1 This, of course, is a mostly subjective judgement. Many of the interface examples I viewed can be found when browsing the RCSB Protein Bank.

2 These aren't necessarily unique to the internet browser, but they are important attributes shared by nearly every modern browser.

3 For this concept I replicated the same icon for the different menu items; icon design is time-consuming and probably best saved until a final design is being developed.

4 Based on conversations I had with Eldon Ulrich and Adam Steinberg (UW Biochemistry).

5 An example of this ability can be found at . Once the window has launched, the window size can be set in View->Option.

6 An example of a JavaScreen that uses an additional window can be found by viewing 3D structure from PDB ID 1IV6 .