[GRASSGUI] Comments on new GUI

[Trevor Wiens]

Some time ago I had some discussion with Michael Barton about the GRASS
GUI and he recently sent me the e-mail he posted to the developers
list. He had indicated he would forward on my comments to the
developers list a couple days ago and suggested I join the list.

I'm now on the list and looked through the archives but didn't find my
comments, so I'll post them directly. I'm sure there are many others on
this list with more knowledge of development than myself, even though I
did do Windows based db applications programming for 10 years in an
earlier life, I've not done any significant amount of Linux development 
and I haven't programmed in C for years.

That said here are my comments on Michael's original post.

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

The importance of a good user interface can't be understated. I totally
agree in this one.

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

There is a single question that is central to this question, do we want
to support non-*nix based platforms aka M$. If this is the case then I
would suggest that Tcltk needs to be dropped in favour of something
that will produce a GUI that will look like in belongs in a M$
environment. More important than this however is the issue of
scripting. If we want to have a single application that runs the same
on all platforms we need to drop shell scripting in favour of a
scripting language that accesses GRASS modules through library
bindings. This would facilitate your ideas about graphics display
further down and would allow for scripts to for GRASS on platform A to
operate exactly the same on other platforms. This portability is
important if we want the user base to grow. If we don't care about M$
(which I really don't but would like to liberate M$ GIS users from the
grip of ESRI), then Tcltk is fine and we can keep writing shell
scripts to get stuff done. It is my opinion that GRASS should move to a
scripting language environment like Python. This is next step in the
natural evolution of the product to a modern product. This move would
also facility GUI development because the entire GUI could be written
using PyQt which would make it easy for the adding of new modules that
could be downloaded and added easily. Obviously the display engine
would be written in C but these environments play pretty nicely
together so I don't see this as problem. 

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

Yes. Multiple display applications are superior to the single display
model and having focus controlled by the window manager is highly
desirable. 

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

This is also a good idea. The separation is artificial. I would suggest
that the default display mode for 3D data should be 3D or user
configurable. 

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

By going to a scripting language and library model this become pretty
easy.

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

I'm a big fan of keyboard shortcuts. I hate having to click on one tool
to zoom in and another to zoom out and yet another to pan. This is a
pain for digitizing or examining data. We should have a single zoom/pan
tool and behaviour be modified by use of the keyboard such as ctrl+left
to draw a zoom in box, or ctrl+right to zoom out and ctrl+middle to
pan. I realize if we want to be cross platform, we need to support
people with one and two button mice, so it is possible that other tools
need to be provided in a drop down, but the ease of use a single tool
makes real use so much more elegant, that we need to implement this for
heavy users.

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

I don't understand this.


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

I think there is central issue to be considered here. Do we want a
single display / edit / print window or a separate cartography window.

If we want single interface then I would suggest the following.
The base object in the layer tree is the page. The page can be set to
screen dimension for analytical use in a natural size and shape or it
can be set to a paper size. The first subobject would be a frame.
Frames would default to screen size for screen pages, but would default
to a user configured size for print pages. Frames could contain a
series of layers or bodies of text imported from text files, images,
etc. Frames could be set to size and location by coordintes (for
scripting support) or interactively with a mouse. Within the frames
would be the layers, if the frame is a "map". We might want to consider
different types of frames (maps, text, and graphics). This sounds
elegant and can be but the trick comes in zooming. When I zoom into a
map am I zooming into the layers and changing the extent or am I
magnifying the page. There has to be a clear interface cue that one is
changing the view or one is magnifying the page. The way the old Atlas
GIS worked was pretty nice but it wasn't always clear which zoom mode
one was operating in which lead to some occasional confusion.
Personally I like the integrated approach because when labels are place
their sizes can be set properly so you don't get nasty surprises when
it comes time to print. As a consultant who has given away far to many
hours than I care to admit fiddling with label placement I really want
to see this done right. I also want to make sure we build label
placement in such a way that a heuristic algorithm for label
placment (like simulated annealing - there is sample code on the web or
in IEEE journal articles to do this so it would be work but not
impossible) can be implemented. 

Now if we want a separate map composer like window, I would suggest
that all label placement be controlled here for reasons stated above.
This isn't necessarily practical because users doing analytical work
will want to see labels from time to time, but when naive users go the
carto window and find all their labels gone, they will be surprised. 

Now in the tree view there should be options for as many "screens" or
"pages" as you like and you should be able to copy a series of layers
to a new frame in through a simple copy and paste command.

Other people may not like this idea, but having had some experience
working this way, I think that in the end, especially when cartography
is part of the job, the integrated approach is more efficient. Another
selling point is that the application has one less window to worry
about so it is simpler from an end users perspective.

> ***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?)
 
Good

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

I don't have any immediate suggestions on reorganization, but I think
this question should be left open. For example one of the ad hoc, but
generally pretty good rules about menu designs is not displaying more
than 7 or 8 items at a time. More than this, new people can't keep
track. 

I'm not convinced that the current organization around data type is
ideal. I know that it accurately reflects the underlying organization
of GRASS, but I wonder about different organizational themes such as a
functional one. Right now the menus are a bit of mix, with Config being
functional and then Raster, Vector, and Image being data types. I don't
have a new organization scheme in mind yet, but I'm thinking about it.
I do think we can come up with a more accessible menu organization. I
will be meeting with a long time friend (and very experienced GIS user
and instructor) about some of this stuff later this month to get his
ideas. 

I noticed in the archive posts about this issue others are also
thinking about reorganization of the GUI to a more functional system.
Coming up with this system is however the trick and I will do some more
thinking about this and post any ideas I have to the list.

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

This sounds reasonable. The switch to sqllite sounds good because
AFAIK, then we should be able to provide a consistent interface for
users who use any SQL backend.

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

As above, output composition should be able to be done either through a
simple configuration file. Human readable formats are great for this
like the M$ .ini format, however XML is nice for this too and building
a XML reader / writer provides a tool to build metadata like ESRI's XML
metdata files. 

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

Yes.
 
> ***Exiting:
> It should be possible to exit GRASS from the GUI rather than having to
> separately type "exit" on the command line.
> 

Yes.

I should also note there is discussion about dropping the development
of a new GUI and simply working with the QGIS team to make it the
interface for GRASS. I think this is idea has merit because the
question of actually being able to deliver is a real issue with a small
volunteer based developer group like GRASS and QGIS. 

I do think that issues I raised above about labelling and having a
multiple window are important and would need to be addressed, but
building on something that already works is sensible. Diversity is
good, but failure doesn't help anyone. Starting a new project shouldn't
be undertaken unless we are confident it can be brought to completion
and maintained.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)