[udig-devel] Procedures == Tasks

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Hi Adrian the bulk of the online help is devoted to *just* this subject. 
The section is called "Tasks" and represent the really useful part of 
online help.

Online help for tasks has a *strict* structure; tasks are captures as a 
simple list of steps (if you want to explain anything link to a 
*Concept* page).

From this page: 
http://udig.refractions.net/confluence/display/EN/Home#Home-WritingGuidelines

Tasks: How to do something. Literally an introduction followed by a step 
by step procedure

With a quote from 
http://devresource.hp.com/drc/technical_white_papers/ecliphelp/index.jsp
> Task topics tell users how to do something. Users who access task 
> topics typically are focused on the job at hand, so provide them with 
> a procedural presentation of the information they require. Task 
> descriptions are step-by-step instructions for performing specific 
> actions and tasks in the platform. For example, the Tasks section 
> contains step-by-step instructions for creating a repository location, 
> and for importing a file from the file system into the workbench.
>
> Task topics are comprised of the following sections:
>
>     * A brief introductory section, which helps orient the user to the
>       task.
>     * A procedure, which is a series of steps that describes how to
>       accomplish a specific goal.
>
> Use links to direct the user to related information; task topics do 
> not provide conceptual information or present reference material.
When we did the design phase of uDig we wrote down the task page first; 
and then wrote the application to accomplish the task.
Jody
> 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'.
>         *********************************************************************
>