Window System: User ViewAuthor: Jan Rojcek
Revision: $Revision: 1.1 $
Document History: available in CVS
- Abstract: This document is conceptual base for the new window system design. Presents problems of the current windowing system design. Lists user scenarios the new design should fit. Provides base ideas for the new design.
- 1 Problems of the current design
- 2 User scenarios
- 3 Logical elements
- 4 Functional elements
This section presents problems of the current window system design the new design should solve.
Window is not only a collection of views (and editors) but has its own identity (name) that doesn't always reflect its purpose e.g. if the user removes all views from the Explorer window but Properties view its name would be "Explorer [Properties of ...]". Explorer name becomes misleading.
Enabling and disabling of the source editor menu item in the view menu is a mystery. The menu item is disabled if no document is open. When the user opens a document, the source editor is opened automatically and the menu item is enabled. When the user closes the editor window, the menu item is disabled again. So the menu item is disabled if the editor window is closed, and enabled if the editor window is open. This has to do with current workspace model (see bellow).
Desktop and Internal Frames
Attaching of windows and docking of views is complicated and insufficient. For example to put debugger views between the source editor and output views we have to dock them either into the bottom of the editor or to the top of the output window. Both solutions are conceptually wrong as debugger views should not be part of non of the mentioned windows.
Moreover when the user is docking a view she has to think whether she needs to create a new window or dock a view to an existing one. This makes DnD very complicated. DnD is also unusable if the dockable areas are limited to the top, left, bottom, right and center, because the user doesn't have a notion which areas are already used while dragging.
It is not possible to layout workspace well on a small screen resolutions, thus screen size utilization is far from ideal. There is no support for quick hiding and showing views (by one click).
Internal frames inside center area are hard to use, overlapping complicates access to an overlapped window. Maximized desktop window overlaps other windows completely.
Workspaces fork the users work flow into a different modes. Switching from the editing to debugging or GUI workspace is automatic but switching back requires user decision. Workspace switching creates effect of "big change" resulting in losing user's focus. It is slow, many windows are hidden, or change their size/position, new windows are introduced. User needs to get oriented each time workspaces are switched.
When a user switches to the gui editing workspace right after the first start (as she wants to start gui editing), there is nothing except the explorer where the user certainly can not perform the gui editing. The point is that workspace tabs are meant by IDE beginners as a doors to a named activities (gui editing, debugging), but they are not.
When the user opens the source editor it is open only in the current workspace, but if she closes that it is closed in all workspaces.
More editors of an object
Window system doesn't provide ability to switch between different editors (source, form) of an one object.
The form designer view doesn't provide any indication whether the form is modified or not.
Focus related problems
There are frequent bugs that focus is nowhere or on wrong component and user has to use mouse to give control to the component where it's desired. For example after Ctrl+F4 press on top component.
Switching between editor and explorer
Code centric users often want to switch to explorer in the context of currently edited source code (or another document). Either they want to see "package view" around source code document or they want invoke some action which is not accessible from editor's menu (Rename action) or they are used to invoke some kind of actions (cvs actions) from explorer rather then editor. In all cases, sync of explorer's selection with edited document in editor area on explicit request will speed up these scenarios.
The purpose of the scenarios is to describe actual and real usage of the IDE and the window system, give a clear understandings of the user requirements, and serve as a test base for the new design.
A focus of the use cases is on the production usage of the IDE. We should take into account a simple use cases like writing a 'Hello world.' application, but it is not our target usage scenario.
In the scenarios, three different users (personas) are considered. Pierre is an intermediate java developer, developing backend of the two tier application. Dennis is a visual style developer working on a front end of two tier application. Katrina is the IDE and Java beginner.
[WS-1] Add new functionality into java projectPierre wants to make changes in a project, without modifying the UI. He needs to add a new functionality, so he firstly searches for a class where he would plug in the new implementation. Opens several classes until he finds the appropriate ones. Writes some code and realizes he should create a new class. Creates one and copies methods to the new class. Opens a browser and searches for a tutorials and articles about the APIs he plans to use. Finds a few sources, reads it and copies some code to try it in his implementation. Doesn't understand the API well, so reads the javadoc. Writes the code and saves. Needs to modify other existing files to make it work, so opens them. Switches between files and writes code. Writes more and compiles to check and fix the errors. When all files seem ready compiles the project. Fixes errors. Compiles again successfully.
- Goal: Open class for editing.
- Scenario: The user searches for a class she wants to edit. Opens several classes using a project browser until she finds the correct one.
- Expectation: Several files are open in the window system, only one file is valid for the user's task.
- Goal: Create a new class for editing.
- Scenario: The user creates new file with the new wizard. The new file is open.
- Expectation: New file is added to the list of open files. It gets a focus.
- Goal: Read web articles about the APIs/technology the user is using when writing code.
- Scenario: The user opens few browser windows and reads appropriate docs.
- Expectation: New application windows are open in the OS window manager, IDE is not in the user focus.
- Goal: Copy code snippet from the examples found on the web to the open file.
- Scenario: The user copies code from the browser and pastes it to the open file for additional modifications. For copying and pasting uses keyboard shortcuts.
- Expectation: The IDE is in the user focus again.
- Goal: Read javadoc of the APIs.
- Scenario: The user opens javadoc browser of the Class, package, and methods she expects to use. Needs to check it with the code in the file and the code in web examples.
- Expectation: Javadoc viewer is in the user focus. Sometimes gets browser and opened file to the focus.
- Goal: Open several other files for editing and create new ones also.
- Scenario: The user follows scenarios WS-1-0a and T-0-0b.
- Expectation: More files are open.
- Goal: Save changes in the file. User doesn't compile, as he knows there are errors, only doesn't want to lose changes.
- Scenario: User saves file by shortcut, menu, or toolbar.
- Expectation: Window system informs about successful save.
- Goal: Compile a single file, to check the syntax.
- Scenario: User compiles using a compile action (menu, toolbar, shortcut).
- Expectation: In case of successful compilation, the user is informed. List of errors is displayed if the compilation is unsuccessful.
- Goal: Fix syntax errors found during compilation.
- Scenario: The user navigates to files and lines containing the errors (shown in the compilation output). Reads javadoc (WS-1-3) to fix the errors. Fixes a few of listed errors and compiles again (T-0-6).
- Expectation: ?
- Goal: Compile whole project. The user keeps all files open, wants to check that she didn't miss any file during compiling and that whole thing works together.
- Scenario: The user runs compile project from the main menu, or from the project browser contextual menu. If the errors are found, the user continues according to WS-1-7.
- Expectation: Information about successful compilation is shown, or list of errors.
- Goal: Check for the semantics errors.
- Scenario: The user runs the project to check the behavior.
- Expectation: A different application is in the user focus (can be a window, console, ...).
[WS-2] Search for a bug causePierre reads a bug report and tries to reproduce the bug in a last version of the project. Runs the project and reproduces the bug. Gets an idea where the problem can be, so opens the file and reads the code. Everything seems to be okay. Adds printlines, rebuilds and runs the project. It seems that the problem is somewhere else. Navigates into a method, which provides incorrect values. Goes deeper into method calls into different classes and files. Adds a printlines and dump stack lines. Rebuilds and runs again. Still not sure where the cause is. To get a better understanding of the project runtime, runs the project in the debugger. Steps trough the code, and into a methods. Finds the cause.
- Goal: Locate a file/line not working properly using printlines.
- Scenario: The user searches between open files and adds print lines to a source she expect a bug is. Compiles (WS-1-6) and runs (T-0-0-9).
- Expectation: ?
- Goal: Inspect and understand code in a method called from his code.
- Scenario: The user uses "go to declaration" or "go to source" from contextual menu above the method call, few times. Goes back if the path is wrong.
- Expectation: New files are open and focused, or already open files are focused.
- Goal: Run the project in the debugger.
- Scenario: Adds a breakpoint and runs the project in the debugger.
- Expectation: Debugger views are displayed, output of the debugged process is displayed, file containing program counter is in the focus.
- Goal: Inspect behavior by stepping into a method while debugging.
- Scenario: The user steps into the method while debugging. Few times.
- Expectation: New files are open and focused, or already open files are focused.
[WS-3] Refactor and clean the code before submitting changesPierre needs to submit changes to the CVS. First updates the project from the cvs. Diffs his project copy against the trunk. Sees printlines in a files which should not change and also the code should be cleaned and refactored a bit. Opens files which contain only debugging print lines and deletes those lines. Diffs again. Opens files which contain changes and modifies the code trying to not change the semantics. Builds the project and tests it. Works okay, so diffs again. Seems fine, but Pierre has realized that haven't added comments and javadoc, yet. Goes through the diff looking for a public members. Adds javadoc comments and checks the javadoc. Compiles, diffs and checks into the CVS.
- Goal: Bring local copy of the project up to date with the team.
- Scenario: The user updates sources from the cvs. Runs an action from the main menu or from the project browsers contextual menu.
- Expectation: Window system displays output of the cvs update associated somehow with the editor.
- Goal: See changes he has made against the project repository.
- Scenario: Diffs the project.
- Expectation: Output of the diff is listed.
- Goal: Clean debugging lines from the code.
- Scenario: The user opens/focuses files, which contain only debugging output, and should not be changed (according the diff output). Deletes debugging lines.
- Expectation: Files are focused sequentially according to the diff output.
- Goal: Refactor the code in the changed classes.
- Scenario: Follows the diff output and modifies the classes.
- Expectation: Same as above?
- Goal: Add javadoc comments to a new public members, or modify javadoc of changed methods.
- Scenario: Searches for a newly introduced public members in the diff output and adds the javadoc comments. Checks javadoc using the autocomment tool or suggestions view.
- Expectation: Same as above?
- Goal: Submit changes to the cvs.
- Scenario: The user checks in the project.
- Expectation: Output of the cvs check-in is displayed. It is remembered even if the user closes the output for a later usage (to archive the commit).
[WS-4] Create a prototype GUI formDennis needs to create a demo gui form to make a screenshot for sending to a customer. Dennis creates a temporary project for holding a prototype forms. Creates a new form, sets the null layout and adds components from the palette. Modifies component properties (labels, color,...) using property sheet and rearranges again. Test the form and sees that the size is a problem, so rearranges components again. Tests the form and takes the screenshot.
- Goal: Create a new empty form.
- Scenario: The user uses a new wizard to create a new JFrame.
- Expectation: Form designer, component palette and property sheet are displayed.
- Goal: Add components to the designer.
- Scenario: The user adds components to the designer, one by one, not laying them out precisely.
- Expectation: Focus is switching between the designer and palette.
- Goal: Modify properties of components.
- Scenario: The user selects components in the designer one by one, and modifies the properties.
- Expectation: Focus is switching between the designer and property sheet.
- Goal: Test the form.
- Scenario: The user invokes testing frame of the form. Testing frame allows to view the form in the runtime (?).
- Expectation: New frame is open above the designer. After testing the focus returns to the designer.
[WS-5] Create a production GUI form, with the implementationDennis needs to modify prototype form for the production usage, and implement a background ui logic. Dennis copies a prototype form from the temporary project. Changes the null layout to the gridbag layout and tunes that a bit. Adds labels to the bundles. If the UI is okay, opens appropriate source file to implement the event handlers and data retrieval (getter/setter) methods. When implementing event handler, goes always from the designer and component to the code.
- Goal: Convert the prototype GUI form to the production GUI form.
- Scenario: The user copies the prototype from from the temporary project to the production project and opens the form.
- Expectation: The prototype form is open in the designer, together with palette and property sheet.
- Goal: Change the null layout to the gridbag layout, and customize the layout.
- Scenario: The user invokes gridbag customizer and tunes the layout.
- Expectation: Gridbag customizer is in the user focus.
- Goal: Replace hardcoded strings with bundle keys.
- Scenario: ?
- Expectation: ?
- Goal: Add event handlers to the components.
- Scenario: The user selects a component and switches to a generated header of the event handler in the source code. Repeatedly.
- Expectation: The source code is focused at appropriate place. A way to switch back to the form designer is also expected.
- Goal: Implement data setter/getter methods in the form source.
- Scenario: The user switches to the source code of the form and writes the code.
- Expectation: The user is focused in the source file of the form.
[WS-6] Getting started with the IDEKatrina wants to create a simple calculator application. She runs the IDE for the first time with a goal to write a code without using a gui builder. She is not sure whether she have to use the projects so she opens a help page saying how to start with the IDE. She skims through the help and checks controls in the IDE window to understand help text better. When she finds that she doesn't have to create a project she closes the help page and goes to create a new class. She opens the new wizard and is not sure which template she should select, so opens a help page to learn about templates more. Reads the help text and expands the templates tree at the same time. Closes the help window and tries Empty Class template.
- Goal: Read the help text about the Main IDE Window.
- Scenario: The user invokes a help action from the main menu. She reads the help and interacts with the IDE at the same time. Switches focus from the help window to the IDE window.
- Expectation: The help page and a part of the main window the help is talking about are in the user focus at the same time.
- Goal: Read the help text about a modal dialog box.
- Scenario: The user hits a help button in the dialog. She reads the help and interacts with the dialog at the same time. Switches focus between the dialog and the help window.
- Expectation: The help page and modal dialog are in the user focus at the same time.
Logical elements are not necessarily functional elements of the window system. Bellow is a list of logical elements and terms that should be taken into account while defining the functional elements of the windows system.
Primary windows display an objects. An object is a user interface entity like file, project or output, and each primary window allows the user to view and manipulate with such object. The user can not change an object a primary window is displaying, we say the window is associated to an object it displays.
Primary base windows are a windows which display a top level objects, which usually means a user projects (perhaps filesystems). Top level objects allow the user to access a user objects, for example files, classes, forms.
Document windows are a special kind of primary windows, as they display the objects called the user objects. The user objects are parts of a project, for example files, beans, classes. Document windows are windows which provide primary way for the user to modify and view those objects. An examples of such windows are java editor, form editor, xml editor, image viewer. Document windows are most important windows as they allow to actually work with the user objects.
Output windows are a primary windows displaying an output objects. Output objects are a results of the actions run, for example compile action, execute action.
Property windows are a windows displaying properties of a selected object.
Utility windows are a windows which provide an access to a tools used with a primary windows. An example is the component palette used with the form editor, or a general toolbox (as described in the assistants proposal) used with other document views.
Actions window are a windows allowing a user to perform supplemental tasks to a tasks performed in the primary views, for example the search filesytems window, web browser, scripting console.
Secondary window is a window which the user invokes, uses and dismisses, usually not interacting with other open windows during that process. It is similar to the action window, but the difference is that the action window is expected to be open and used regularly with other windows or is expected to be used often and therefor should stay open also when the user is not actually using it. Secondary windows are usually implemented as modal or non-modal dialog boxes.
Toolbar is an area which provides a quick access to an actions and options. Some actions are useful only during a certain tasks. An example is the debugging toolbar.
Set of Windows
Necessary Set of Windows
Necessary set of windows is a set of windows that is necessary to view or use when performing a task. So there may be a different set for each task the user is performing. The user always works only with one window at a time, but she needs a quick access to other windows as well. For example when the user performs visual editing with the form editor, she selects components in a form editor window and modifies or reads a properties in a properties window. To achieve it quickly and smoothly both windows should be visible together.
The necessary set of windows is a set of windows that is used (activated) or viewed regularly during performing a task.
Useful Set of Windows
Useful set of windows is a set of windows that might be potentially used while performing a task. An example is the threads debugger window, it is usually not used during debugging of a single thread process, but might be used just to check what the running threads are. So the useful set of windows is not the necessary set of windows, doesn't have to be visible, but easily accessible.
OTOH the thread window might be used a lot when debugging a multiple thread process. So, it depends on a task, whether the view belongs into the useful or necessary set.
It is hard to define what actually is the task, especially in the sense of a task granularity. For example, completing a whole project may be a task, and creating a project is a subtask, then a debugging a project is a subtask, and setting up a breakpoints is another subtask. So, when solving an issues about what set of windows is necessary or useful the tasks have to be defined first.
When we talk about a focus, we mean the user focus, it means a window the user is watching into. Keyboard focus is a subset of the user focus, as the user is watching into a window where she is typing. So the user may look at the compilation output, but it doesn't mean that the output window should be active (receiving key strokes).
Functional elements are the actual elements of the window system.
Window is a basic window system element. It includes all window types but document windows which work differently.
A special kind of window used for showing the user objects which are part of a project.
Main Window Areas
There would be just two areas - Window area and Document area. Document area corresponds to the editor area in the spec, and document area equals to the editor area. A windows are open in the window or document area. A document windows are open only inside the document area. Outside area which is described in the spec would be withdrawn from the spec. This means that all windows would open only inside the main window in MDI mode. The consequence is that the windows which are open outside of the main window currently would be either open in the main window (scripting console, web browser, VCS windows) or would be transformed to modal or non-modal dialog boxes (properties windows, options).
Set of Windows
Set of windows is a replacement of workspace. It is a set of windows which is used during a concrete task. For example GUI Editing set of windows consists of the component palette, component inspector (just a components hierarchy) and properties window. Debugging set consists of all the debugger windows (local variables, watches, call stack, etc.).
Necessary Set of Windows
Necessary set of windows is a subset of a set of windows that is shown when a window set is being enabled. For example necessary set of debugging windows contains Call stack, Variables, and Process Output. It is shown when the Debugging set is enabled (e.g. a user starts the debugger).
A user might move a windows from and into a necessary set of windows, depending on the user preference. This way the user is able to control which of the windows are shown when the set is enabled. For instance, the user starts the debugger and default necessary debugger windows are shown. But the user decides that she prefers using Watches instead of Local variables window. So she opens the Watches window and closes the Locals window. Actually this means the user removed Locals from the necessary subset, and moved Watches into the subset, so the next time she invokes the debugger the Watches are displayed and Locals are not.
It is important to mention that more set of windows can be enabled at the same time. For example, the user is using form editor (the GUI Editing set is enabled), and starts to debug, thus the Debugging set gets enabled too. This way the user would see all of the necessary debugging and GUI editing windows.
The question is whether the user should be able to enable and disable a window sets manually using some kind of controls (perhaps toggle buttons) in the main window or not. Arguments for providing controls are that the IDE would never really know what is the user performing. IDE may try to guess and enable appropriate set of windows, but it may also fail in its assumption. A good example is, how the IDE knows that the user is editing a form? Is it when she opens a form object, or when she focuses a form editor? Maybe neither of those. Arguments against controls are the complication of the user interface. It might be hard to understand connection between controls and the windows layout.