I'll start a thread on this. If there is enough interest, we should move it to 
the WIKI. If not, it can quietly fade away.

Last month, I was at the AAG (a first for me) in sessions talking about 
advanced geospatial and other modeling, and jointly with Helena in a session on 
advances in open source tools for GI Science. Seeing some of the papers and 
talking with participants set me to thinking again about GUI concepts.

I've tried to advocate for thinking outside the standard model in designing 
interfaces for GIS. Granted that it is difficult to get too cutting edge when 
we are all "avocational" developers away from our real jobs or studies. In 
spite of this (or perhaps because of it), I think we've done a good job so far 
in creating a flexible and very useable interface to a very complicated piece 
of software. Most people I show GRASS to are very impressed--and they are 
comparing it to the commercial market leader that pays a lot of money for 
software development. If we have such a great interface--and one that we've 
only developed to a point of stability in the past year--why should we think 
about something different. 

The reason is that the nature of computing is changing rapidly, and some of the 
changes are especially relevant for spatial technology. I've always felt that 
the normal windows/menus interface (and typing commands) is not really an 
appropriate design for software that is intended to manipulate, analyze, and 
display multidimensional geospatial data--but I've had only had a somewhat 
vague idea of what might be better. At the same time, the idea of ubiquitous 
computing and combining data from multiple sources over the internet is 
becoming a reality. The latter is especially important as internet-based 
repositories of complex geospatial data continue to grow.

This brief intro leads me to toss out a couple of rather different ideas for 
comment. Think of them as GRASS 8 and beyond concepts.

1. GRASS was originally designed to access data from multiple sources and 
server. However, for most people, GRASS now lives on individual computers and 
accesses data there. But new tools in GRASS are changing that. There are of 
course initial tools to access WMS data. More interesting is Glynn's proposal 
to access all data through an r.external/v.external type interface linked to 
gdal. If we go that way, GRASS becomes much more flexible, accessing data 
wherever it is located accessible to a workstation. Some people still want to 
use GRASS remotely, but have considerable difficulty running our very nice GUI 
in that way--a GUI that is designed to run on a user's local computer. 

So we might want to think about making GRASS run in a browser for some future 
version. I see some kind of synergy between the kind of interface created by 
software like OpenLayers or MapServer and the data accessing capabilities of 
Glynn's idea--maybe also incorporating WMS and other such internet data. This 
might help to make GRASS transparently portable across all computing platforms, 
and reduce the amount of GUI development work needed for cross-platform 
compatibility. It also would open the possibility of making GRASS accessible 
via cloud computing. 

I don't know how we do this, but the fact that some kind of interface is doable 
in a browser via OpenLayers, MapServer, and other such internet mapping tools, 
means that this is possible. We'd need to develop a more sophisticated 
interface than is now available on existing internet mapping software, but the 
tools to do this exist and it may be worth considering. 

2. An alternative way to think about interfaces comes from conceptually melding 
of the kind of tactile interfaces that Helena and others have been 
experimenting with 
<http://skagit.meas.ncsu.edu/~helena/wrriwork/tangis/tangis.html> and the kind 
of interface that has caught on in a big way with Apple's iPad and iPhone. The 
idea is that it is much more versatile and "intuitive" (if geospatial analysis 
can be intuitive) to be manipulating virtual landscapes and multidimensional 
data in a tactile/visual way than via a more standard computer interface. 
Imagine if you could put your hands into the screen with nviz, change the data, 
add and subtract layers by dragging them into or out of the view, grab a piece 
to analyze in any dimension, etc. I think that this kind of interface foresees 
the future of human-computer interaction, but is especially significant for the 
kind of high dimensional data and visual displays that we deal with in a GIS. 
While I don't suggest that we redirect our efforts into creating a GRASS app 
(not that it wouldn't be a bad idea for a future SOC project), but we might 
want to keep a close watch on the development of this new kind of tactile 
interface and see how we can incorporate it into a GIS setting in the future.

OK. I'll stop there, but am curious what you all think about this. A final 
question. Should we send this to the user list too or keep it in the dev list 
for the moment?

Cheers
Michael
______________________________
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
www:    http://csdc.asu.edu, http://shesc.asu.edu
                http://www.public.asu.edu/~cmbarton

_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to