[GRASS5] Proposal for GRASS UI roadmap

Sun Nov 6 10:56:06 EST 2005

Thanks Martin. Rumors of this and a few other similar projects prompted me
to try this approach. Before someone (including me) invests time and effort
in developing a new or evolved UI, we need to think about what should go
into it and how it should be organized. I think that input from longtime GIS
users will be helpful in that respect. One fundamental question is whether
we follow the ArcGIS model or whether we can do something better.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Martin Wegmann <wegmann at biozentrum.uni-wuerzburg.de>
> Reply-To: <wegmann at biozentrum.uni-wuerzburg.de>
> Date: Sun, 06 Nov 2005 15:36:32 +0100
> To: <grass5 at grass.itc.it>
> Cc: Michael Barton <michael.barton at asu.edu>, Christian Wygoda
> <crischan at wygoda.net>
> Subject: Re: [GRASS5] Proposal for GRASS UI roadmap
> 
> hello Michael, 
> 
> your ideas are very good & needed. By chance I found this page
> http://crischan.net/qgrass with a Q GRASS approach, however it is in its very
> first steps but it sounds pretty promising.
> I asked Chrischan to present the very first version in GRASS-News vol.4 and
> perhaps you both could benefit from each others skills/knowledge/experience.
> 
> regards, Martin
> 
> On Sunday 06 November 2005 05:59, Michael Barton wrote:
>> Colleagues
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Thanks to all of you for your support over the past two years.
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution and Social Change
>> Arizona State University
>> Tempe, AZ 85287-2402
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> ==================================
>> 
>> 
>> PROPOSAL FOR A USER INTERFACE ROADMAP FOR GRASS 6.X AND 7
>> 
>> DISPLAYS
>> 
>> ***Display windows:
>> 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.
>> 
>> ***2D and 3D visualization:
>> 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".
>> 
>> DISPLAY CONTROL GUI AKA GIS MANAGER
>> 
>> 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.
>> 
>> ***Buttons:
>> 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)
>> 
>> 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.
>> 
>> ***Layers:
>> 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.
>> 
>> 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.
>> 
>> 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?
>> 
>> 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.
>> 
>> ***Option panes:
>> 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.
>> 
>> 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?)
>> 
>> ***Pull-down menus:
>> 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".
>> 
>> RELATED UI ISSUES
>> 
>> ***Attribute data management:
>> 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.
>> 
>> ***Printing:
>> 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.
>> 
>> ***Display output:
>> 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.
>> 
>> ***Exiting:
>> It should be possible to exit GRASS from the GUI rather than having to
>> separately type "exit" on the command line.
> 
> -- 
> Martin Wegmann
> 
> DLR - German Aerospace Center
> German Remote Sensing Data Center
> @
> Dept.of Geography
> Remote Sensing and Biodiversity Unit
> &&
> Dept. of Animal Ecology and Tropical Biology
> University of Wuerzburg
> Am Hubland
> 97074 Würzburg
> 
> phone: +49-(0)931 - 888 4797
> mobile: +49-(0)175 2091725
> fax:   +49-(0)931 - 888 4961
> http://www.biota-africa.org
> http://www.biogis.de