[GRASS5] Proposal for GRASS UI roadmap

[Martin Wegmann]

Hello Michael, 

On Sunday 06 November 2005 16:56, Michael Barton wrote:
> 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. 

fully agree

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

I assume you mean with "follow the ArcGIS model" the UI Design (e.g. 
http://www.esri.com/software/arcgis/extensions/streetmap/graphics/sm_local-map.gif)  
with consists of one map window and not the multi-window UI like 
ERDAS/ENVI/GIMP etc. For GRASS you would need at least a shell window perhaps 
like kile incorporated it (http://kile.sourceforge.net/screenshots.php) but 
personally I prefer the multi-window model. 

Just an idea: Comparing Windows and KDE, I have one desktop when using MS 
Windows with lots of application running (might be grouped) and I have KDE 
with several desktops and the application distributed across them to keep 
them clear. Of course people have different preferences but I think of a 
arrangement to be able to select buttons to swap the visible GRASS components 
e.g. previously customised buttons like "analysis X",  "analysis Y", 
"visualisation Z" (equivalent to KDE Desktops) - this would not change to 
whole GRASS session but only the monitors/toolbars which are relevant for the 
respective analysis. 
Using this function would make swapping between 'analysis' - 'map layout' - 
'NVIZ'  using the same UI pretty easy and straightforward and not too much 
cluttered. 

However in the end it depends on the user and perhaps a choice how to arrange 
the UI (mulit vs. single window) would be the best solution.

regards, Martin




> __________________________________________
> 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

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