Several Issues with the MOSES Interface

Overview

The purpose of this page is trying to share with the MOSES group some of my ideas, a programmer's view on the interface.

SDI vs. MDI

Though Microsoft's Visual C++ and SUN's Java are different, they both share the same philosophy on how to design the interface. One of the concept is about the SDI (Single Document Interface) and MDI (Multiple Document Interface). Simply say by example, a notepad is a SDI since it deals with one single document. Microsoft Word is a MDI because it can deal with multiple documents at the same time. Similarly, WEPS Lite is a SDI while MOSES is an MDI.

The point here is not to identify which one is SDI and which one is MDI. Look at many commercial packages, we can find some basic rules on developing GUI. Almost all of them have a main window.

Within the main window it always contains the main document windows. In the above image, Microsoft Word main window contains several documents. Detailed information such as font for a portion of characters are displayed in a pop-up window. It's not in the main window (See the following snapshot).

This is important because 1) the user always knows where he comes from or the root of the application, 2) when the user close the main document, all other related pop-up windows will be closed, 3) in some cases, some required operation in a pop-up window must be done before you can proceed to the next step. The implied meaning of this is that there is a hierarchical structure in any interface.

I raise this issue after I read through Joel's proposed flexible view structure and ran RUSLE-2. The following is a snapshot after I ran RUSLE-2. I try to display a lot of detailed management information and accidently close the main management window (the root window where we come from). That means all the other windows now being displayed on the screen are meaningless because these windows are come from a root-window which has been closed. I believe it is definitely not a good idea to put everything within a main window. The only kind of windows that will be displayed in the main window is the main document windows. Any other detailed windows should be pop-up windows.

Two Approaches on Editing (making choices)

In our implementation of MCREW, we use a quite different way as Joel's implementation in RUSLE-2. At the highest level, we have a very clean table view and a timeline view. When mouse move to a certain column which allows editing, a bubble-help prompt is shown. (The cursor is added since the snapshot tool I'm using won't catch the cursor.)

So double click on a specific line will get to the next snapshot. That means the specific cell is get into the editing state. It totally depends on the implementation on how to do the editing. In our implementation, we use a tree-view to edit the operation column. It's suggested to use a calendar to edit the date column and maybe use a compass to edit the direction. So there are various possiblilities on how to edit a cell.

There are some other operations may apply to the current cell. We use right-click plus pop-up menu to implement the functions as in the following snapshot. For example, to see the detailed information about the current operation, pick Display menu item. This implementation is quite close to some commercial packages such as Microsoft Contact (in Outlook) though it uses single click to edit cell.

RUSLE-2 Implementation:

The following is a snapshot of Mangement in RUSLE-2. All the operations on the table are shown on the screen. The "+" button will insert a line and "-" will delete a line. Clicking on the folder sign will display the detailed information and clicking on the down-arrow sign will allow the user to change the operation.

Quite straightforward. But I raise the following questions:

1. Expandibility: for example, if we want to implement some more functions such as copy-paste several lines, how?

2. Wise space usage: if we have a lot of columns like operation column, a lot of folder icons and down-arrow icons are displayed in the table view. Is it a good table view?

3. Flexablibility: We can't always use this format to display/edit everything. Sometimes we may use a checkbox to display/edit whether a person is a vegetarian or "Is this a rotation?" in the above example.

Another problem is how to display extra parameters. I don't think it's a good way to do it as above. To me, the right side and the left side are separate parts. I need some effort to align the corresponding lines.

Table View vs. Cell View

I noticed in RUSLE-2, Joel used a lot of cells (in a similar format) to display parameters (the red-box in the above snapshot). I guess he is using a small component which has a title, a frame-box and a edit field. Combining many of these cells will get a table. This does give us some flexibilities on organize the display of parameters. For example, you can drag and drop the cell at any location of the screen. But we must also consider the following issues:

1. Complexity: It's easy to implement some simple functions as shown in the above snapshot. How about some complicated table-view functions such as copy-n-paste, drag-n-drop, sorting, etc.? In our previous MCREW, we did try to implement a table-view from scratch or cell. The result is neither powerful nor professional. We spent much less time on our new MCREW table-view by using a commercial table-view component. From my point of view, we should try to use commercial components as much as possible. Otherwise, programmers may not be able to meet the required deadline if everything is developed from scratch.

2. Professional: Using "+" & "-" sign to insert & delete a line are not so professional. Developing a table from a scratch will eventually cause un-professional. (Just compare old MCREW and new MCREW)

3. Expandability: It may be impossible to add some complicated table-view functions as stated in my first point.

This page last updated on march 27, 1998.