[GRASS5] starting discussion on next generation UI

[Michael Barton]

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:

1. a pretty functional TclTk interface, which could be made considerably
better with more sophisticated programming and newer TclTk tools;

2. the option of accessing GRASS files and using some GRASS tools within
QGIS;

3. a Java interface used in JGrass too link GRASS and R functions;

4. a rumor I¹ve heard about someone working on a new QT interface for GRASS

5. 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 - - -

1. 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

3. 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.

4. 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.

5. 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?

6. We need to have better, interactive access to attribute data tables
(including query and management) given their importance in the new vector
architecture.

7. 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)

8. 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20050729/8df6605a/attachment.html