With the impending (hopefully) release of the 6.0.1 bugfix and looking ahead (shortly?) to 6.2, it seems to be a good time to start a discussion about the future of the GRASS interface.
Currently, there is:
-
a pretty functional TclTk interface, which could be made considerably better with more sophisticated programming and newer TclTk tools;
-
the option of accessing GRASS files and using some GRASS tools within QGIS;
-
a Java interface used in JGrass too link GRASS and R functions;
-
a rumor I’ve heard about someone working on a new QT interface for GRASS
-
discussion of using GTK to create a new interface.
It is good that the project is sufficiently active to encourage these various efforts at making GRASS—and GIS in general—more accessible to users. However, I’ve begun to worry if we are about to get the cart before the horse, designing interfaces before we think seriously about what we need and want in a UI.
While I don’t want to discourage creativity, I think it would be a good idea if we had a discussion about what we need in an interface: what kind of features are essential, desirable, undesirable; how it should function through commands, menus, buttons, and other devices; and how it should interact with users in terms of visual, textual, or other feedback. Once a framework for UI requirements have been reasonably well sketched out, then we can look at available platforms and expertise to develop it.
It seems that now is a good time to plan the interface systematically, while we have a decently functioning interface and growing interest in GRASS as comprehensive tool for analysis and visualization of spatial data. It may turn out that most people are very happy with the way the current interface works and it just needs to be improved. Or it may be that we should consider something very different. Perhaps GRASS could lead the way in new interface concepts for GIS and spatial technologies. There are a lot of creative, talented people involved in this project. A new interface project might be a good way to get them to exercise this creativity and talent, and contribute to spatial information tools worldwide.
I suggest that we could start by simply listing (and hopefully coming to consensus) a set of wishes for the UI. The next step would be to transform these wishes into a set of design specifications that we can then use for UI improvement or redesign.
If this does turn into a fruitful discussion, I’ll volunteer to save all the emails and try to distill them in a month or so to see where we are at. There’s probably more to say, but I’ll simply start out here with a few features that I think are important.
-
-
- WISH LIST FOR GRASS UI - - -
-
- I think GRASS should continue to have its own integral, default UI—although the beauty of an open source tool like this is that is can also be incorporated into other projects and UI’s. The recent GRASS user survey suggests that most GRASS users also want an integral UI for GRASS
2 . We need to maintain a command line interface (for power users and for scripting) AND have a graphical UI
-
I like the current structure of separating controls from display windows (perhaps because I started with Map Info). It lets me look at multiple views of spatial data with less screen clutter.
-
If we end up keeping command dialogs, I’d (usually) like them to go away after I click run—with their output directed to the main control window. (This could get tricky running multiple processes, but should be solvable) I’d like to have a button that brings up their last state when I open then so I could easily rerun something without having to keep the dialog open.
-
I wonder if there is a way to seamlessly combine NVIZ-like visualization with the ‘standard’ displays so that all displays have the potential for 2.5D and 3D display and we don’t have to run a special visualization module?
-
We need to have better, interactive access to attribute data tables (including query and management) given their importance in the new vector architecture.
-
It should be easier to do spatial queries of attribute records—without having to create a new file. (this is not really a UI issue, but related to one)
-
Users should be able to customize the UI to some extent, so that they could have the tools they use most often easily accessible, but wouldn’t always have to wade through the entire tool set.
Well, that’s more than I planned on and I’ll probably come up with more later. But now I want to open this up to the rest of you. Please feel free to forward this to people who are not currently on the developers list but perhaps should be.
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton