<HTML>
<HEAD>
<TITLE>Proposal for GRASS UI roadmap</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN DEFANGED_STYLE='font-size:12.0px'>Colleagues<BR>
<BR>
A couple months back I suggested a discussion on the specifications for the next generation user interface for GRASS. Perhaps because it was summer--or perhaps because everyone is just so happy with what I’ve done so far ;-)--there were few takers. However the comments were useful. I’ve included all of them in the attached text file as I promised to do.<BR>
<BR>
Now that we are thinking about GRASS 6.2 and 7, we need to actively consider the way in which GRASS presents itself to users. GRASS is a great program and current development is making it an outstanding piece of software for managing, visualizing, analyzing, and modeling very diverse spatial data. But this tremendous capability will go unrecognized if potential users become frustrated in trying to make it work. Because of its power and versatility, and because GIS is a complex subject, it is a challenge to make GRASS accessible to users—even ones with considerable experience with computer graphics, CAD, and other GIS’s. This same challenge is faced by other high-end GIS systems. To some extent, we are still trying to work out appropriate display and control metaphors for GIS, and a large part of the existing UI’s are still a lot like word processors and drawing programs, although GIS is neither. An automobile may have a great engine and suspension system, but if it lacks a steering wheel or comprehensible gauges its performance will be underutilized. So the UI is important.<BR>
<BR>
In order to make discussion easier, I want to float a proposal for the next generation UI for GRASS. This will give people a concrete target to take shots at, say they like, or offer modifications or additions. This is perhaps a more effective way to do this than simply asking for input, and I think I’ve got a thick enough skin to offer my proposal for critiquing—of course it is pretty close to perfect so I shouldn’t have to worry much ;-) In any case, it is a start on which we can begin to build.<BR>
<BR>
I’ve tried to build on what works well now, to think out of the box a bit to envision how a GIS can be easier to use, and to be realistic about what can be accomplished in an open source project like this one. GRASS has some excellent features that set it apart from other GIS systems. Ones that always impresses people I show it to are the visualization capabilities. It is extraordinarily flexible and fast at visualizing complex spatial data. I think we should build on that, along with GRASS’s excellent analytical abilities for raster data as unique and distinguishing features of the GRASS system. (I’d like to suggest that we think of beefing up the already strong modeling capabilities of GRASS by adding predictive and agent modeling, but that’s another issue).<BR>
<BR>
Some of the items in the proposal could be implemented pretty soon, using the TclTk tools we use now. Other parts will require more sophisticated use of TclTk or a different GUI development system. Yet other parts will require new C-programming. Because a next generation GUI will require skills beyond my own and team effort, your input is essential. <BR>
<BR>
One thing to note is that I am not recommending a platform for implementing this at this point. I’m pretty sure it could be implemented in TclTk if we get more sophisticated in using that platform. However, it might be better to implement it in another platform like QT or GTK. As I said last summer, however, I think it is better to decide what kind of UI we want and THEN decide which available platform is the best way to implement it.<BR>
<BR>
I guess that is enough preamble. The proposed roadmap is below. Please let me know what you think over the next few weeks. At some point, it might be good to send it to the larger GRASS user list for input from the people who will have to make it work.<BR>
<BR>
Thanks to all of you for your support over the past two years.<BR>
<BR>
Michael<BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution and Social Change<BR>
Arizona State University<BR>
Tempe, AZ 85287-2402<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
<BR>
==================================<BR>
<BR>
<BR>
PROPOSAL FOR A USER INTERFACE ROADMAP FOR GRASS 6.X AND 7<BR>
<BR>
DISPLAYS<BR>
<BR>
***Display windows: <BR>
Keep ability to have multiple display windows. Display should have the potential to display both 2D and 3D graphics. Display windows should get focus by clicking with mouse. It should be necessary to run a module like d.mon select simply shift the focus to a different display window.<BR>
<BR>
***2D and 3D visualization:<BR>
2D and nD visualization should be seamlessly integrated. The "normal" view would be 2D like current x displays and standard GIS. Clicking a 3D (nviz) button would open a floating window with 3D controls (like in nviz now) but not a new display window. This would allow user to tilt, rotate, change z, visually separate layers, etc. It would work with the same layers shown in 2D mode, but would simply display them in 2.5D or 3D. Nviz would not be a separate module, opening a separate display window and separate layer control panel; it would simply display any active layers in 3D "mode". <BR>
<BR>
DISPLAY CONTROL GUI AKA GIS MANAGER<BR>
<BR>
We should keep single display control (like current GIS Manager). distinct from the display window(s). This allows for multiple display windows to be controlled from single interface. Display "commands" should be integrated into display control interface; there would be no separate d.* command modules. That is, the display control system should be able to directly draw graphics to a display window, without going through intermediate, stand alone programs. We need to rethink how these would best be implemented (e.g., should we combine thematic vector and chart display functions?) Display functions should still be scriptable as in nviz and d.m, just not independent "commands". It should be possible to run a display script from the command line to automate mapping.<BR>
<BR>
***Buttons:<BR>
There should be 1 row of buttons for display controls (zoom, pan, erase, 3D, query, layer management, open display window, save, print, etc). We should change current display in region buttons to simply region setting buttons (default, select saved region). We will no longer need a display button (see layers specs below)<BR>
<BR>
There should be a 2nd row of buttons for adding layers. This could be space-optimized by making pull-down groups (e.g., vector group would include vector, 3D vector, chart, thematic, etc) with last-used layer-type showing up in the button bar.<BR>
<BR>
***Layers: <BR>
Any function than can be thought of as a layer should be implemented as one. It is a nice and pretty intuitive metaphor. It is easy to work with conceptually and comparable to graphic and CAD programs. Layers should include 3D vectors and volumes (see below) along with the kinds of layers now in the GIS manager. <BR>
<BR>
We should keep layer-tree metaphor. The hierarchical arrangement is intuitive and easy to work with. Nested groups are an especially nice touch. We may want to switch from arranging the layer in the order they will be displayed (first at the top, last at the bottom), to a stacked metaphor (last displayed at the "top" of the stack). This is more in line with other GIS programs and most graphics programs, and would make GRASS less confusing to a new user. <BR>
<BR>
Adding a layer to the layer tree should automatically display it when the 'active' box is checked. There should be no need for display button. Checking or unchecking the 'active' box should automatically display or undisplay the layer. Should layers be added in an non-activated state by default so that the user can choose to display the newly added layer when ready?<BR>
<BR>
There should be an independent layer tree for each display window open. Selecting display window with the mouse displays the associated layer tree. This permits multiple displays of different information controlled from same interface. User should be able to copy existing layer tree to a new or open display window.<BR>
<BR>
***Option panes:<BR>
Option panes should open in a separate window when an entry in the layer tree is double clicked. This will optimize space in the display control GUI. There should be "apply" and "save and close" buttons so that an option pane can be kept open if desired. <BR>
<BR>
We should add a "layer name" field to the option pane rather than adding a layer name by typing it into the layer tree. This makes it more "permanent" so that it is not erased when a new map is chosen to be displayed in that layer. If it is empty, the name of the map will go in by default; if something has been typed in it, it will stay and not be overwritten (make this a question when opening a file?)<BR>
<BR>
***Pull-down menus:<BR>
Keep menus as we have now for file, configuration, GIS function (raster, vector, 3D), database, extensions (I'm assuming that the GRASS Extension Manager will be default soon). Do we need a separate menu for help or can it go into configure or something like that? Menus should call independent modules that can also be run from the command line. GRASS needs to remain scriptable for complex tasks and functions should be useable from command line for "power users".<BR>
<BR>
RELATED UI ISSUES<BR>
<BR>
***Attribute data management:<BR>
Now that GRASS has vectors with linked attribute data, there needs to be a reasonably decent UI for attribute data management and queries. Perhaps this could be developed along with the switch to a default attribute dbms based on SQLite.<BR>
<BR>
***Printing:<BR>
There should be integrated WYSIWYG printing to multiple devices from the GUI, including PDF files. ps.map functions should be integrated into GUI and be accessible without creating complex text file scripts.<BR>
<BR>
***Display output:<BR>
Users should be able to save WYSIWYG display output to multiple graphic formats without scripting through a png driver or using gdal_translate. Formats supported should at least include tif, png, pnm, gif, jpg, svg, and xcf. <BR>
<BR>
***Exiting:<BR>
It should be possible to exit GRASS from the GUI rather than having to separately type "exit" on the command line.<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>