User interfacing

The user interface of Charta consists of controls that visualize data in all sorts of ways. Currently controls are available to display lists, tables, trees and so on. The controls have been developed from scratch without using a third party control library. Furthermore, the interaction between the different controls is also developed all over. In fact, in the current Windows implementation of Charta the user interface as a whole is just one Windows control. Charta itself redirects Windows events to the proper Charta controls.

Redesigning a control library is a considerable investment of programming effort. However, the gain is that the user interface can be integrated intimately with the rest of Charta, moreover, in the future the control library will be implemented in Charta itself. Also, a control library from scratch allows to implement new features that are not supported by other control libraries. The most important of these features is the ability to let the user design and adjust his own interface to Charta.

Customizing the user interface

One important principle in Charta is that it should be the user of software that should be able to design the user interface. Every user has specific needs and uses software in its own way. Traditionally the programmer is responsible for designing a user interface. Often this results in rigid and sloppy interfaces because programmers do not have enough time to design a proper interface to the functionality they have developed: it is the functionality itself that gets the most of attention of the programmer.

The solution to this in Charta is twofold. First, Charta will try to provide the user with an automatically generated user interface: viewing an array of Persons will bring up a table control which conveniently allows the user to add and remove persons and change properties of individual persons. However, the programmer will be able to influence this standard behavior in the future.

Second, after an initial user interface has been created the user will be provided with extensive possibilities to customize the user interface. Controls can be dragged to other places and controls can be resized in various places. Currently not all of these features work properly, sometimes the way the user interface reacts is not convenient but these issues will be addressed in the future.

Also, in the future more options will be available, for instance, the user will be able to create tabbed controls and other container controls to design its own user interface.

Keyboard navigation

Important to good user interface design is to make most of the user interface functionality available to the keyboard to prevent the need of using the mouse very often. For instance, one should be able to reach an other control on the screen by just using the keyboard. Traditionally this can be done by using the Tab key to iterate over all the controls on the screen. However, there are two problems with this approach.

First, the programmer has to define the order in which the controls will be traversed and too often the programmer ignores this fact of the design of a user interface. The result is that the user cannot comfortably traverse the controls on screen. The second, and maybe more important, problem is that using the Tab key only allows for one-dimensional traversal of controls while a computer screen is clearly two-dimensional.

In Charta the solution to this inconvenience is the following. Instead of using the Tab key the user can hold down the Windows key. The currently focused control will light up blue. Then, when the user presses one of the arrow keys, the blue indicator will move to an other control that corresponds to the direction indicated by the arrow key. Releasing the Windows key will transfer the focus to the control that is currently lit up blue. Clearly, now the user is able to traverse controls on the screen in a two-dimensional manner. Moreover, Charta automatically will determine which control will be the next in the traversal according to the arrow key that was pressed by the user. For this an algorithm is used that tries to provide consistent and predictable traversal based on the known positions of controls on the screen.

Explorer

When Charta is executed the initial user interface consists of three controls. The first control, the upper left tree control, is used to explore the contents of the currently installed object stores. For the moment there are two object stores: Memory and charta.data. The first will hold objects that are created in internal memory. The latter is a file on disk to store objects persistently.

At the moment objects in an object store are grouped together in an array of objects belonging to the same class. Every object of a certain class will be placed in one of these arrays. Thus these arrays can be seen as an index to all objects in an object store. These arrays can be found under Class instances in the explorer. Opening nodes in the explorer allows to further inspect objects. Double-clicking a node will try to open a control to edit the type of object that is selected. For arrays one will be provided with a table control, for functions a complete panel for programming a function will be created. All created controls will end up in a tabbed control, the second control in the user interface, called the Control vault that is situated at the top right of the screen.

The Class instances is the default index of an object store and is the first Global the user can use to browse an object store. Globals are global variables that are the entry points to the objects in the object store and are available throughout the application. By opening an object store these globals can be edited. By default the object store contains the globals Classes and Functions where the user can organize his own classes and functions. Of course new globals can be added as well.

Problems

User input often is not without errors because people make mistakes in editing. In Charta the user gets visual feedback about his editing problems in the third control in the user interface. At the bottom of the screen the user is provided with a table that shows the current problems. Problems can vary in severity: problems can be hints but also errors. Besides this overview of all the problems the user also gets direct feedback from the controls that contain the problems. For instance, when the user is editing a function, errors in that function will be underlined in red. In the future every problem with data entry (for instance entering an invalid zip code) will be consistently indicated in this way.