[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Towards a release
|
Hey Jody,
Your User+Interface+Workflow is really helpful to me, thanks.
Here are some thoughts, not necessarily related to the 1.1 release but
related to the effort of formalizing the DESIGN of uDig so we can all
play together better.
I'm going to adopt your approach of talking about 6 generic "workflows":
Workbench
Map
Service
Scratch
Edit
Task
for the different approaches which uDig takes to user work. Obviously
user work will cross workflow boundaries but this workflow based
language will help us structure the discussion about internal uDig
subsystems affected by any user's work.
RULE 1: THE TERMS USED IN THE UDIG INTERFACE MUST BE CONSISTENT
IN REGARDS TO THESE WORKFLOW ELEMENTS.
Procedures:
----------
I'm going to compile a list of fundamental GIS user procedures. User
"Procedures" are 'descriptions of work steps by which users accomplish a
goal.' Procedures are sequences of atomic "Steps." With such a list we
can then:
I. map each step in the procedure sequence to steps in the
workflow
II. ensure the user has *enough visible information* to take
each step in the procedure.
(Does udig / refractions already have such a list? If so it would make
sense to extend it in the same format.)
****** Example:
*************************************************
A user wants to copy a section at the center of a map to a new
shapefile set. This procedure mixes parts of the Map workflow
(map-selection) with part of the service workflow
(service-selection and export). The user needs to know
1. What is selected in the map (assume a uDig 2.0 where
map-selection can span many layers at once)
2. What of that can be dumped to a shapefile set (e.g. some
layers may not be representable in shapefiles)
3. Which service is selected for the dump
4. Does the user have write access to that service
5. Is there enough space on the service for the dump?
6. What the name mapping going to be from the selection set
to the file set
After that the user, may be able to safely make the files. This
example only stretches current functionality a tiny bit so
addresses many current issues. You can see that there is lots of
info needed along the way that uDig needs to give the user to be
'user-friendly'.
*********************************************************************
SERVICE:
-------
Your "service" workflow is wrong or sloppy because it suggests that
"Import..." and "Export..." are parallel ideas. We have taken over
eclipse notation but it doesn't work for us since the actions are so
different:
1. Import... = add, into the catalog, a link to a service
2. Export... = dump, into the service, a data set
Note the first should always succeed (although we may not be able to
actually 'import' any data from it) while the second may cause a myriad
of issues such as filling disks, violating permissions... The lack of
parallelism and precision here, I think is part of the confusion in the
UI which I described to you in my separate mail: e.g. "New Layer" which
is really "Add a service link to the catalog" rather than the "Create a
blank layer to work with" one would expect in parallel to "New project"
and "new map".
I would argue strongly in favour of bringing the notion of "service" to
the fore and having a "Link to data service" menu entries or tooltips
and then representing these services in the catalog.
******************************************************************
BTW, this would start the process of greatly improving the
catalog for user friendliness and power
Catalog = list of services
Services = UI elements with info (so requires a better
widget)
Type -> file/db/web
User Rights -> read-only, write
Access -> yes /no (the latter *are* the web
catalog which is merely a list of services which
have not yet been accessed)
Access this session -> yes, no
Last access time
Result of last access
Coverages = UI elements contained in a service
This richer catalog would allow us to drag and drop data sets
("Coverages") onto services to copy them / transform their
schema. I use "Coverages" obviously in the vector sense and
because it's much simpler a problem to handle than any source of
Data. I don't think this 'rich catalog' is really straying into
the realm of 'resource management' although it is admittedly
getting close. This is definately out of your scope but doesn't
seem particularly hard and would be a *big* win for udig.
********************************************************************
all for now, it's time for lunch,
--adrian
On Wed, 2007-10-10 at 15:54 -0700, Jody Garnett wrote:
> I have started putting together the end game plan for uDig 1.1.0 (shock!).
> - http://udig.refractions.net/confluence/display/UDIG/uDig+1.1.0+Release
>
> Tomorrow I am going to go through the user interface and look and do a
> sanity check against the user interface guidelines
> (http://www.eclipse.org/articles/Article-UI-Guidelines/Index.html); The
> results will go up on a wiki page (incase anyone wants to help; or even
> just see what it would take to make your contribution part of uDig).
> Here is a link to the same kind of review performed for uDig 1.0
> (http://udig.refractions.net/docs/Usability.pdf).
>
> For today I have some light reading if you are interested:
> - http://udig.refractions.net/confluence/display/DEV/User+Interface+Workflow
>
> Cheers,
> Jody
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
