Introduction and Rationale
As GRASS is growing in size and functionality and targeting new user groups through being ported to MS Windows, getting a greater attention as a OSGeo project and the new GUI in development it is time to consider the usability of the program.
This augmented visibility will bring many new users to GRASS who may have known GRASS for long but never dared to use it for one or the other reasons. Other may be totally new to GIS and geospatial analysis or drawn to GRASS by its great capabilities. GRASS should have the best possible user interface to provide a appealing working environment to the new and experienced users to enable them to do their work effectively and without reading tons of documentation and mailing list archives.
The great Chance
OpenUsability the initiative that promotes usability in free and open source software (F/OSS) development has a call open until February 20th for interested projects to benefit from the work of willing students to review and improve overall usability or the usability of special parts of a program just as Google Summer of Code does it with new program feature. GRASS should strongly consider applying and take this nice opportunity for the reasons mentioned above.
The organisers of the OpenUsability Initiative told the GRASS informed on 17.03.2008 that GRASS wasn't selected for the 2008 review phase. Nevertheless, we should bear in mind that improvements in th usability will significatly raise the workflow efficieny and visibility og GRASS. We should therefore continue to list and discuss usability blockers on this page and convert them into enhancement requests on the bug tracker.
There are a number of user interfaces available for GRASS 6:
- Tcl/Tk GUI (current gis.m GUI, limited new development)
- Old Tcl/Tk GUI (d.m, functional but unmaintained)
- wxPython (wxGUI, functional, but still under heavy development)
- Usability improvement efforts should be concentrated on the wxGUI.
- Text based command line interface (CLI)
- The CLI is in pretty good shape WRT modules, due to the near universal use of G_parser() and the g.parser module. Option and flags could perhaps be more consistent between modules (e.g. sep= -> fs=) but these are frozen between minor versions.
- The C API - it can be a bit inconsistent, but it's not exposed to users.
- SWIG interface (Python, Perl, ..) to the GRASS libraries
- Modules could make better use of guisections (tabs).
The current usability show-stoppers
Please list here the issue where you think that usability needs to be improved. Please mention the version of GRASS used.
Where could the usability of the GUI (please state which referring to) be improved?
Where do you feel your workflow being blocked?
- Visual interpretation of satellite (and aerial) imagery for land cover mapping/ change detection purposes
There is no option to link two displays (wether using the X monitors or the Map Display of the GIS Manager) for an effective side-by-side visual comparison of data (all kinds of data: imagery, vector, raster, other ancillary data) over the same geographic region, projected of course on the same coordinate system. Having a linked pointer (pointing at the same location/ coordinates) on two different maps is an efficient way to compare images (e.g. winter vs. summer acquisitions over the same location) or to visually judge how effective was a georectification process. There are many other situations were this is "linking" option is useful/ critical.
To implement an automatic replay of all actions (pan, zoom, load/ unload and overlay other data) taking place in one X monitor into another X monitor (or from one Map Display?) requires scripting and even then is not "automatic" as it is probably necessary to re-run the script.
To exemplify, OpenEV (Edit Toolbar... > Link Views/ Cursor) is a very good tool to do this work. It's light, supports almost everything (based on gdal/ogr), smooth panning/ zooming, quick digitising and more.
The combination of GRASS (for the analysis) and OpenEV (for an easy visual cross-comparison of results) is ideal. Yet there are time consuming limitations: e.g. exporting from GRASS to some format, careful selection of export parameters etc. Maybe it would be enough to create an easy to use export tool (from GRASS format in... ?) or why not the option to access GRASS' locations from OpenEV? The latter would be of course an OpenEV issue, if at all.