[Geoserver-devel] GeoServer 2 Interface Update

GeoServer GeoServer Developer
1

Hey everybody-

My name's Chris Patterson, and I've been working recently on the GeoServer 2 interface.

Thought it might be good to check in and send along my $.02 on where we stand regarding UI stuff right now:

==Sidebar
* needs reorganization
* needs a listing (with at-a-glance status bars) for all the currently active services
* there was some conversation in IRC about bringing the [Persist] [Revert] buttons back into the sidebar, so they'd be always accessible (rather than on the server admin screen, where they are now).

==Data Manager
* Needs a lot of attention. Individual pages need to be converted to use the same markup conventions as the rest of the UI, and may need to be reordered / reorganized to be easier to use.
* We're using a tree view on the main data manager page (and have a fair amount of work invested in it). I'm not convinced this is the best approach for displaying this data, as I don't think we'll ever be nested more than two layers deep. This may be a moot point, given the amount of time invested in the tree view and our time constraints - but I'd love to get a better solution if we end up with time to do it.

==Demo pages
* Needs some attention to avoid the link-overload effect of listing every single format for every item.

==Avoiding overwrite collisions
* David and I have chatted about various ways to help users avoid overwriting each other's changes. The last time we'd talked, the options (in descending order of preference) were:
** Since wicket keeps track of what page each user is on, display messaging to the effect of "Hey! So-and-so is already on this page" when accessing a page that's already in use.
** Store the configuration time with the session data, and display messaging if the configuration is updated by another user
** Display the relevant configuration update time on pages which need it

==Errata
* Pagination will probably be needed on all pages which may display sufficiently-long result sets
* All result sets should be sorted by a sensible column. Time pending, adding client-side sorting by other columns might be nice (although it could be confusing in conjunction with pagination [users could think that they were looking at a different set of results])
* Adding animation and more AJAX-y effects as appropriate are all time-permitting at this point

Chris

2

Christopher Patterson ha scritto:

Hey everybody-

My name's Chris Patterson, and I've been working recently on the GeoServer 2 interface.

Thought it might be good to check in and send along my $.02 on where we stand regarding UI stuff right now:

==Sidebar
* needs reorganization

Oh yeah, see my other mail on this subject ("Web2 left menu reorganization mini proposal").

* needs a listing (with at-a-glance status bars) for all the currently active services

+1

* there was some conversation in IRC about bringing the [Persist] [Revert] buttons back into the sidebar, so they'd be always accessible (rather than on the server admin screen, where they are now).

+1

==Data Manager

snip

* We're using a tree view on the main data manager page (and have a fair amount of work invested in it). I'm not convinced this is the best approach for displaying this data, as I don't think we'll ever be nested more than two layers deep. This may be a moot point, given the amount of time invested in the tree view and our time constraints - but I'd love to get a better solution if we end up with time to do it.

It gets as deep as workspace/datastore/layer. I don't care about
throwing away the code I've written to make the tree work.
And yeah, I'm not psyched about it either, it updates slowly,
does not handle huge amount of layers properly (how do you page
a tree?), and having to switch from the tree to the buttons to
actually do something is not ideal imho.

What do you propose? Two dropdowns and a list? A mini tree (workspace,
datastore) and a table? Three stacked tables (woskpaces, datastores
in the selected workspace, and layers)?
Workspaces will always be few, datastores and coverages might be
very very many (thousands), layers even more.

==Demo pages
* Needs some attention to avoid the link-overload effect of listing every single format for every item.

Yep, not very fond of it either.

==Avoiding overwrite collisions
* David and I have chatted about various ways to help users avoid overwriting each other's changes. The last time we'd talked, the options (in descending order of preference) were:
** Since wicket keeps track of what page each user is on, display messaging to the effect of "Hey! So-and-so is already on this page" when accessing a page that's already in use.

Makes sense. Not sure how to make this technically, David, did you
look into it?

** Store the configuration time with the session data, and display messaging if the configuration is updated by another user

Yeah, easier, but drawback, you know you're screwed up too late
and have no tools to assess what the other user changed.

** Display the relevant configuration update time on pages which need it

Easiest, better than nothing :slight_smile:

==Errata
* Pagination will probably be needed on all pages which may display sufficiently-long result sets

+1

* All result sets should be sorted by a sensible column. Time pending, adding client-side sorting by other columns might be nice (although it could be confusing in conjunction with pagination [users could think that they were looking at a different set of results])

+1

* Adding animation and more AJAX-y effects as appropriate are all time- permitting at this point

Yeah, we don't really need it to be flashy, just no nonse and
quick to use.

Cheers
Andrea

3

Thanks for the update Chris. Let's push for an initial 2.0.x release by the end of this week, so we can get something live that people can poke at. More thoughts on specifics inline.

Christopher Patterson wrote:

Hey everybody-

My name's Chris Patterson, and I've been working recently on the GeoServer 2 interface.

Thought it might be good to check in and send along my $.02 on where we stand regarding UI stuff right now:

==Sidebar
* needs reorganization
* needs a listing (with at-a-glance status bars) for all the currently active services
* there was some conversation in IRC about bringing the [Persist] [Revert] buttons back into the sidebar, so they'd be always accessible (rather than on the server admin screen, where they are now).

This all sounds good.

==Data Manager
* Needs a lot of attention. Individual pages need to be converted to use the same markup conventions as the rest of the UI, and may need to be reordered / reorganized to be easier to use.
* We're using a tree view on the main data manager page (and have a fair amount of work invested in it). I'm not convinced this is the best approach for displaying this data, as I don't think we'll ever be nested more than two layers deep. This may be a moot point, given the amount of time invested in the tree view and our time constraints - but I'd love to get a better solution if we end up with time to do it.

I think it'd be great to hear suggestions on a better solution, but I think at this point we all felt good about the original design, and we've put a good bit of work in to it and time is limited.

==Demo pages
* Needs some attention to avoid the link-overload effect of listing every single format for every item.

==Avoiding overwrite collisions
* David and I have chatted about various ways to help users avoid overwriting each other's changes. The last time we'd talked, the options (in descending order of preference) were:
** Since wicket keeps track of what page each user is on, display messaging to the effect of "Hey! So-and-so is already on this page" when accessing a page that's already in use.
** Store the configuration time with the session data, and display messaging if the configuration is updated by another user
** Display the relevant configuration update time on pages which need it

I'd put this at a pretty low priority for now. It's an admin application, generally will be used by only a couple users, and probably not at the same time. We should agree on a design that's easy to implement, but hold off on actually implementing it.

==Errata
* Pagination will probably be needed on all pages which may display sufficiently-long result sets
* All result sets should be sorted by a sensible column. Time pending, adding client-side sorting by other columns might be nice (although it could be confusing in conjunction with pagination [users could think that they were looking at a different set of results])
* Adding animation and more AJAX-y effects as appropriate are all time- permitting at this point

Yeah, these are all 'nice to have', but I don't even know if I'd put them as required for 2.0 release. Let's make jira issues for them though to track.

C

Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel