[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Consistent use of Language
|
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).
