This page last changed on Jan 30, 2008 by aaime.

Downsides of current UI

  • Apply/save cycle is simply a burnen, remove it.
  • Requires too much time to add a new feature type, add a data store, jump on feature types, choose new one, specify SRS, build bound, submit, apply save, oh my... I want to be able and configure the data store and say "pretty please, add all feature types in it to geoserver". Most information can be gathered automatically anyways, such as SRS, so don't make me go thru all those steps.
  • Automatically register new feature types found in datastores (kind of a poor man's ingestion engine).
  • Allow to inspect SRS list, as well as data store, styles and feature types in read only mod without the need to be logged in. Log in should be required only to modify those. Provide summary pages with real information, not just anemic pages with a single drop down with names.
  • Make good use of screen real estate, 640x480 monitors are long gone, and browers do have scroll down capabilities (yes, they do!).
  • Provide better error messages, current ones are hard to notice.
  • Give us good look and feel, not hospital white and green appearance
  • Lack of being able to provide nice widgets or wizard screens for datastores. The dynamic DataStore.Param method doesn't really cut it. The parameter names and descriptions are written in programmer terms.
  • a flat list of feature types works if you have tens of them, not when you have hundreds. We
    need a better way to organize layers inside the administration UI.

Ideas for the new UI

  • Search SRS like in (a rest based implementation is already available btw)
  • Allow for per datastore configuration panels, both at the datastore connection level and at the feature type / coverage level (since for some datastores some information may not be required to be specified, or some datastore may have extra config options, and so on)

Good Examples

  • Continnum, nice and simple for both monitoring and configuration


Our existing workflow was based around a simple WFS and WMS editing cycle, and was not completed. We were able to configure our "catalog" of available information (ie Data), and then seperatly configure the WFS Service and WMS service. We did have some cross talk between these (the default style for wms was configured as part of the data).

To start off discussion: "Cross Bar Navigation"

  • tree of data on the left
    • Root - used to describe the service as a whole
    • Source - ie IService
    • Resource - ie GeoResource
  • open ended list of web services arranged along the top:
    • "Connection", used to useage information, connection parameters modification performed here
    • "My WMS" - title taken from configuration, care and feeding of service as a whole (say enabling protocols 1.0, 1.1.1, and WMS Soap)
    • "My WFS" - title taken from configuration, respondible for OGC WFS
    • "My WCS" - title taken from configuration, etc...
    • "Metadata" - user supplied additional information that is not derrived from origional data source

If a user wants more then one "WFS", perhaps for different users they can configure the system with more then one WFS bean (each one would show up as a service along the top). May be easier to support WFS 1.0 and WFS 1.1 as seperate web services (although common version negotiation will be needed).


We will still need a JMX Bean for monitoring in an Enterprise Setting, for bonus points this JMX bean may want to duplicate the configuration options for supplying a common Oracle connection pool.

I think its noteable to comment that the geotools catalog ( or something like it ) will be necessary to pull some of these off effectivley. Most notabley "pretty please, add all feature types in it to geoserver". To pull this off and not kill the user experience lazy loading will be very important. Correct me if I am wrong, but our current system loads up all datastores on startup.

Posted by jdeolive at Dec 25, 2006 11:11

I agree that the apply/save cycle is cumbersome. However, one thing I do like about it is it removes the need for events. I have written direct manipulation ui's before ( no save ) and they are plagued with a mess of events and listeners to keep all models in sync. In the current system a single save applys all DTO's to the model removing the need for listeners.

Posted by jdeolive at Dec 25, 2006 11:17

I suppose this depends on how fast we can load stuff, but I was thinking that perhaps we could just hook up all the 'submit' calls to apply the DTO's to the model. That's the big annoyance for me, we have people hit 'submit' and then also 'apply', and then 'save' again if they want it to persist.

I suppose the other route, which may be easier with something like wicket, is to get rid of all those 'submit' calls, just let people edit values and hit 'apply' when they're done.

Posted by cholmes at Dec 25, 2006 12:45
Document generated by Confluence on May 14, 2014 23:00