Window System: User View
Author: 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.
- Contents:
- 1 Problems of the current design
- 2 User scenarios
- 3 Logical elements
- 4 Functional elements
1 Problems of the current design
This section presents problems of the current window system design the new
design should solve.
Windows
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
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.
2 User 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 project
Pierre 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.
WS-1-0a
- 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.
WS-1-0b
- 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.
WS-1-1
- 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.
WS-1-2
- 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.
WS-1-3
- 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.
WS-1-4
- 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.
WS-1-5
- 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.
WS-1-6
- 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.
WS-1-7
- 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: ?
WS-1-8
- 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.
WS-1-9
- 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 cause
Pierre 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.
WS-2-1
- 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: ?
WS-2-2
- 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.
WS-2-3
- 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.
WS-2-4
- 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 changes
Pierre 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.
WS-3-0
- 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.
WS-3-1
- Goal: See changes he has made against the project repository.
- Scenario: Diffs the project.
- Expectation: Output of the diff is listed.
WS-3-2
- 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.
WS-3-3
- Goal: Refactor the code in the changed classes.
- Scenario: Follows the diff output and modifies the classes.
- Expectation: Same as above?
WS-3-4
- 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?
WS-3-5
- 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 form
Dennis 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.
WS-4-1
- 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.
WS-4-2
- 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.
WS-4-3
- 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.
WS-4-4
- 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 implementation
Dennis 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.
WS-5-1
- 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.
WS-5-2
- 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.
WS-5-3
- Goal: Replace hardcoded strings with bundle keys.
- Scenario: ?
- Expectation: ?
WS-5-4
- 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.
WS-5-5
- 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 IDE
Katrina 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.
WS-6-1
- 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.
WS-6-2
- 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.
3 Logical Elements
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.
Windows
Primary Windows
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.
Base Windows
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
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
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.
Properties Windows
Property windows are a windows displaying properties of a selected object.
Utility Windows
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.
Action Windows
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 Windows
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.
Toolbars
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.
Task
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.
Focus
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).
4 Functional Elements
Functional elements are the actual elements of the window system.
Window
Window is a basic window system element. It includes all window types but
document windows which work differently.
Document Window
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.
