[udig-devel] Consistent use of Language

[Jody Garnett]

Morning Adrian:
> Your User+Interface+Workflow is really helpful to me, thanks. 
>   
It was just something quick; I agree the service (ie anything to do with 
the catalog needs a more careful description). The major point was the 
the workflows (even for import and export are not defined by us - having 
a good definition of these things is part of why we chose RCP).

For example Wizard Completion *Guideline 5.11:*

    If a new object is created, select and reveal the new object in the
    appropriate view.

The reason we chose import (for services) is because the web service, 
database or file exists regardless of the uDig application (it is an 
external entity). We open up the catalog view and select the new service 
when it is imported into our application.

I will revise that page over the course of the day; but the eclipse ui 
guidelines are key here. I have messed them up before and will do so 
again ;-) On the bright side we are serious about following these 
guidelines.

If you have questions about how Map Editor works (and the relationship 
with the Edit menu) Guideline 6.8 gives you the answer:
> An editor may contribute items directly to the window menu bar.  All 
> of the commands available in the editor should be displayed in the 
> window menu bar, for accessibility and clarity. Exceptions are for the 
> obvious commands, e.g. basic navigations such as next / previous 
> character, line, word.
This is why operations should appear in the menu bar (instead of just in 
the context menu). Please note that operations should be categorized 
(into say analysis, data, etc...) and shuffled into the appropriate 
menu. If you can think of a category for operations that change the data 
please let me know (in Excel they are called "Tools" but that presents a 
naming conflict).
> 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.
>   
You are going to have to tempt Jesse in to that conversation; I don't 
mind planning for the future but I got some priorities to balance. A 
quick question about DESIGN so I can understand your perspective:
- User Interface DESIGN - is all about the uDig product making sure that 
what we present as the example application is approachable to one and all
- SDK DESIGN - is all about making the extension points hooks and user 
interface guidelines clear to the developer community (so contributions 
slot in smoothly)
- Community
> 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.
>   
Agreed this is why I am writing down my language upfront before I look 
at either the application or the online help. I don't have the Catalog / 
Service work flow sorted properly - but it is a background activity and 
may not be a priority at this time. When we go to flesh it out we should 
talk about how services are "imported", how they are "connected" or 
obtain "warning" or "failure" states. You will also notice gapping holes 
when you try to figure out how to fix a service that is not working (or 
even figure out why one is not working).