I've been using the developers documentation for
the past 7 weeks developing a plug-in of reasonable complexity which extends the
catalogue to accept data in the form of
continuous data streams rather than stored data sets, and allows users to
register continuous queries against these data steams. The results of the
queries are displayed in part by a pseudo layer over a basemap in this
case the OSGB ITN layer the rest
in extensions to the interface and found both the web site and the documentation
perfectly adequate for the purpose and for a project with your timescales
amazing.
However, I
think you should keep in mind when you make design decisions that people will be
extending uDig, and in doing so will be thinking outside of the GIS box ,
particularly UI decisions, for instance we make extensive use of projects and
have extended them to make use of version control, we have many data
sets which we need to rerun, this a typical situation in the world of remote
sensing, and many others that use spatial data, uDig makes a very useful
component for displaying spatial information for these
applications.
I think that you should not try too hard to save the user from
themselves. Applications that do end up being rigid and complex. The problem is
that the work process are rarely structured, and that an application that
tries to force them into an arbitrary structure is more of a hindrance than a
help.If the user wants to do something silly (in your opinion), don't
obstruct him a just politely warn him, and get out of the way and let the
user get on with things. This approach to the UI derives from Alan Cooper,
his books About Face, and The Inmates are Running the Asylum, are a
good starting point for those interested.
Regards
Tony Kennedy
|