[Geoserver-devel] Some more ideas about the wicket data tree replacement

GeoServer GeoServer Developer
1

Hi,
so I've been working a little on a more scalable
component for presenting the catalog contents.

First thing I noticed while working on it is that
during the GeoServer IRC meeting, I forgot about
workspaces and stores, which are the first two levels
in the data tree.

Workspaces do not really have a scalability issue,
in most cases they will be only a handful... always
less than 100 I guess, unless we move to a model
in which one GeoServer instance is used to power
an ASP that gives one/more workspace per user,
and there is some uber-admin that can see them all.

Stores should not be that many either. On the
vector side the directory data store should cure the
proliferation of shapefile data stores, on the coverage
side, we can still have a ton, so until we fix that,
a server with lots of coverages can still have a lot
of stores.

Layers wise, we already know, there can be many, many
and ... many!
Ok so attached here a first proposal of how the layer
page could work:
- a keyword based filter to get only the elements one
   is interested into listed
- a table of layers, with links, lots of them. Each
   link points to an editing page, so from this one
   we can not only inspect layers, but also workspaces
   and stores
- checkboxes for a global, full list, not per page,
   selection model
- a remove link, that should pop up a dialog asking
   delete confirmation, with a list of the
   actual selection contents
- a drop down with datastores, you chosee one,
   you get into a dialog/page that lists all the layers
   that are still un-configured for that store.
   If we don't any, we can just pop up a warning, if
   just one, go straight to the configuration of the
   layer, if many, have the user choose (for the moment,
   just one, later, choose a set and leverage some
   auto-config)
- the headers should be clickable to get a globally
   sorted list (on a single column). Still have to implement
   this.

It's pretty minimalistic, but should work.

What about stores and worksapces? Well, I was considering
using the same approach, in two separate pages, it's simple
enough, and uniformity is a good thing.

So for workspaces a very simple table, a link to remove
the selected ws, and one to add a new one. In case of
removal, show which datastores and layers will be removed,
if confirmed, cascade delete.

For stores, same deal.

It's not as compact as the data tree, but scales up well,
and seems pretty simple to use (and a lot easier to implement).

Thoughts?
Cheers
Andrea

PS: menu wise you see "resources" which is the old data
tree, and layers, which is the page you're looking at.
For workspaces and stores we could do something similar,
that is, add two more menu items. Alternatively, we
can decide to have a single "resources" page and have
three tabs on top of it to switch between ws, stores
and layers. Imho it would start to be too much nesting, but
I'm happy to be convinced otherwise :slight_smile:

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

(attachments)

layerList.png

2

Looks nice Andrea, I like it. A couple of minor things, perhaps some of which you already plan to do, i know this is just a prototype:

* instead of the label "vector" or "raster", the use of icons. Perhaps making the "Type" column anonymous, just a column of icons, similar to the check box column.
* instead of an "Enabled" column perhaps just graying out the row, or perhaps a little icon that depicts the row as disabled
* this may be more of a Mac OS'ism but placing the filter text box on the right hand side

That is it for now. Nice work :slight_smile:

-Justin

Andrea Aime wrote:

Hi,
so I've been working a little on a more scalable
component for presenting the catalog contents.

First thing I noticed while working on it is that
during the GeoServer IRC meeting, I forgot about
workspaces and stores, which are the first two levels
in the data tree.

Workspaces do not really have a scalability issue,
in most cases they will be only a handful... always
less than 100 I guess, unless we move to a model
in which one GeoServer instance is used to power
an ASP that gives one/more workspace per user,
and there is some uber-admin that can see them all.

Stores should not be that many either. On the
vector side the directory data store should cure the
proliferation of shapefile data stores, on the coverage
side, we can still have a ton, so until we fix that,
a server with lots of coverages can still have a lot
of stores.

Layers wise, we already know, there can be many, many
and ... many!
Ok so attached here a first proposal of how the layer
page could work:
- a keyword based filter to get only the elements one
  is interested into listed
- a table of layers, with links, lots of them. Each
  link points to an editing page, so from this one
  we can not only inspect layers, but also workspaces
  and stores
- checkboxes for a global, full list, not per page,
  selection model
- a remove link, that should pop up a dialog asking
  delete confirmation, with a list of the
  actual selection contents
- a drop down with datastores, you chosee one,
  you get into a dialog/page that lists all the layers
  that are still un-configured for that store.
  If we don't any, we can just pop up a warning, if
  just one, go straight to the configuration of the
  layer, if many, have the user choose (for the moment,
  just one, later, choose a set and leverage some
  auto-config)
- the headers should be clickable to get a globally
  sorted list (on a single column). Still have to implement
  this.

It's pretty minimalistic, but should work.

What about stores and worksapces? Well, I was considering
using the same approach, in two separate pages, it's simple
enough, and uniformity is a good thing.

So for workspaces a very simple table, a link to remove
the selected ws, and one to add a new one. In case of
removal, show which datastores and layers will be removed,
if confirmed, cascade delete.

For stores, same deal.

It's not as compact as the data tree, but scales up well,
and seems pretty simple to use (and a lot easier to implement).

Thoughts?
Cheers
Andrea

PS: menu wise you see "resources" which is the old data
tree, and layers, which is the page you're looking at.
For workspaces and stores we could do something similar,
that is, add two more menu items. Alternatively, we
can decide to have a single "resources" page and have
three tabs on top of it to switch between ws, stores
and layers. Imho it would start to be too much nesting, but
I'm happy to be convinced otherwise :slight_smile:

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Justin Deoliveira ha scritto:

Looks nice Andrea, I like it. A couple of minor things, perhaps some of which you already plan to do, i know this is just a prototype:

* instead of the label "vector" or "raster", the use of icons. Perhaps making the "Type" column anonymous, just a column of icons, similar to the check box column.

Yep, that's what I thought to do. I just did not remember right away
how, so I kept it toString-simple :wink:

* instead of an "Enabled" column perhaps just graying out the row, or perhaps a little icon that depicts the row as disabled

Icon might work better, the rows are already alternating. Green checkbox
and red "forbidden" mark?

* this may be more of a Mac OS'ism but placing the filter text box on the right hand side

Hum, this is something for the design team I guess... as a Windows/Linux
user I would find the right location a bit odd but, provided that is
consistent across the UI, why not.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

On Thu, 2009-02-19 at 17:25 +0100, Andrea Aime wrote:

Hi,
so I've been working a little on a more scalable
component for presenting the catalog contents.

First thing I noticed while working on it is that
during the GeoServer IRC meeting, I forgot about
workspaces and stores, which are the first two levels
in the data tree.

Workspaces do not really have a scalability issue,
in most cases they will be only a handful... always
less than 100 I guess, unless we move to a model
in which one GeoServer instance is used to power
an ASP that gives one/more workspace per user,
and there is some uber-admin that can see them all.

Stores should not be that many either. On the
vector side the directory data store should cure the
proliferation of shapefile data stores, on the coverage
side, we can still have a ton, so until we fix that,
a server with lots of coverages can still have a lot
of stores.

Layers wise, we already know, there can be many, many
and ... many!
Ok so attached here a first proposal of how the layer
page could work:
- a keyword based filter to get only the elements one
   is interested into listed
- a table of layers, with links, lots of them. Each
   link points to an editing page, so from this one
   we can not only inspect layers, but also workspaces
   and stores
- checkboxes for a global, full list, not per page,
   selection model

This sounds dicey; I am a bit concerned by the idea of a selection model
that survives page loads, if only because that's not how things usually
work in my experience. I'd like to bring this up with the design team
as well.

- a remove link, that should pop up a dialog asking
   delete confirmation, with a list of the
   actual selection contents

If we allow global selection this list may be quite large. I suppose
some sort of summarization could be done (perhaps just listing
namespaces and the number of layers from each or so) to avoid the sorts
of issues that the paged list is supposed to fix in the first place.
Perhaps we can ignore this for now and revisit when we've made some more
final-ish decisions about the store list.

- a drop down with datastores, you chosee one,
   you get into a dialog/page that lists all the layers
   that are still un-configured for that store.
   If we don't any, we can just pop up a warning, if
   just one, go straight to the configuration of the
   layer, if many, have the user choose (for the moment,
   just one, later, choose a set and leverage some
   auto-config)
- the headers should be clickable to get a globally
   sorted list (on a single column). Still have to implement
   this.

It's pretty minimalistic, but should work.

What about stores and worksapces? Well, I was considering
using the same approach, in two separate pages, it's simple
enough, and uniformity is a good thing.

So for workspaces a very simple table, a link to remove
the selected ws, and one to add a new one. In case of
removal, show which datastores and layers will be removed,
if confirmed, cascade delete.

For stores, same deal.

It's not as compact as the data tree, but scales up well,
and seems pretty simple to use (and a lot easier to implement).

Thoughts?
Cheers
Andrea

PS: menu wise you see "resources" which is the old data
tree, and layers, which is the page you're looking at.
For workspaces and stores we could do something similar,
that is, add two more menu items. Alternatively, we
can decide to have a single "resources" page and have
three tabs on top of it to switch between ws, stores
and layers. Imho it would start to be too much nesting, but
I'm happy to be convinced otherwise :slight_smile:

it took me a minute or two to parse this out and I'm still not sure I
got it right. I think what you are saying is that we need two more
page-able lists, one of workspaces and one of stores, and that you see
two options for how to present the three lists (layers, workspaces,
stores) to the user:
* as tabs in one giant "Resources" page, or
* as separate pages linked from the navigation sidebar

and that you prefer the latter. I would tend to agree with that. Having
a "Resources" link in the "Data" section of the sidebar seems pretty
confusing to me.

I also have a couple of observations:
* There is an SRS field in the layer table. Is this appropriate
information for the layer list? It seems like a configuration detail
that is not likely to be useful for {sorting,searching} to me.
* Should the 'enabled' field be editable? Actually, come to think of
it, the 'enabled' attribute may need some revisiting in the light of the
new multiple map concept. If I disable a layer, but it has been added
to a map, does it show up in that map? What if it is used in several
maps? Maybe we should scrap the 'enabled' attribute and leave its role
to be played by security permissions. Or maybe 'enabled' should be an
attribute of published layers and not the data itself.

--
David Winslow
OpenGeo - http://opengeo.org/

5

David Winslow wrote:

This sounds dicey; I am a bit concerned by the idea of a selection model
that survives page loads, if only because that's not how things usually
work in my experience. I'd like to bring this up with the design team
as well.

The are not actually "page loads" as the things flips page with AJAX,
but yeah, I get the point, the user is actually not seeing the current
selection fully, so the results of a delete might be confusing.
That's why I added a confirmation box for the delete with a list of
the resources that are going to be deleted.
Having a per page selection is doable, but harder (the selection
state is kept on the server, not in the page).
It also makes the use case of willing to delete layers that match
a certain filter awkard, as you have to delete one page, realize
there is another one, delete that, and so on.

it took me a minute or two to parse this out and I'm still not sure I
got it right. I think what you are saying is that we need two more
page-able lists, one of workspaces and one of stores, and that you see
two options for how to present the three lists (layers, workspaces,
stores) to the user:
* as tabs in one giant "Resources" page, or * as separate pages linked from the navigation sidebar

and that you prefer the latter. I would tend to agree with that. Having
a "Resources" link in the "Data" section of the sidebar seems pretty
confusing to me.

Yep, you got that right, and yes, I would like to have a total of three
pages to handle resources, one for workspaces, one for stores, and one
for layers.

I also have a couple of observations:
* There is an SRS field in the layer table. Is this appropriate
information for the layer list? It seems like a configuration detail
that is not likely to be useful for {sorting,searching} to me.

It depends. SRS is kind of a cornerstone of geographic data, you don't
have that, you're not doing GIS. If you're in the simple case and all
your data are in the same SRS, then yes, it's obviously not useful.
If on the other side you have data in different projections, it's actually a quite effective way to get all the data in a particular
projection. For example, in Italy we have 4 main based on transverse
mercator plus a cadastral one plus the wgs84. Each municipality I've
seen in Italy has data in at least 3 of them, and conversions between
one and the other are not trivial. So that can become a very effective
filter (what data is based on the cadastral system?), especially when
combined with some other filter.

* Should the 'enabled' field be editable? Actually, come to think of
it, the 'enabled' attribute may need some revisiting in the light of the
new multiple map concept. If I disable a layer, but it has been added
to a map, does it show up in that map? What if it is used in several
maps? Maybe we should scrap the 'enabled' attribute and leave its role
to be played by security permissions. Or maybe 'enabled' should be an
attribute of published layers and not the data itself.

Enabled is not a user editable element at the moment, it's a reflection
of an inner state of your data. Enabled is true if data loading went
fine, it's false if the datastore could not be connected, or the feature
type could not be found in the datastore (as tables can be deleted on
your back).
From an admin point of view spotting quickly which layers are not
enabled is important, as it tells you that something is not working
as expected, and that you should take corrective actions (we should
actually reinstate the green/gray/red bars in the config as that
gives you a quick summary on the condition of the catalog,
then you can drill down and find what's not working).

Cheers
Andrea

6

I think this looks like a huge improvement over the tree structure.

The only question I had from the mockup was about the links on each row of the result table:

http://skitch.com/dimmerswitch/bfa45/layerlist

It's not immediately clear (from looking) where those links would take me. Would adding "[Edit]" buttons or text potentially clarify where each of those might point?

Chris

On Feb 19, 2009, at 10:25 AM, Andrea Aime wrote:

Hi,
so I've been working a little on a more scalable
component for presenting the catalog contents.

First thing I noticed while working on it is that
during the GeoServer IRC meeting, I forgot about
workspaces and stores, which are the first two levels
in the data tree.

Workspaces do not really have a scalability issue,
in most cases they will be only a handful... always
less than 100 I guess, unless we move to a model
in which one GeoServer instance is used to power
an ASP that gives one/more workspace per user,
and there is some uber-admin that can see them all.

Stores should not be that many either. On the
vector side the directory data store should cure the
proliferation of shapefile data stores, on the coverage
side, we can still have a ton, so until we fix that,
a server with lots of coverages can still have a lot
of stores.

Layers wise, we already know, there can be many, many
and ... many!
Ok so attached here a first proposal of how the layer
page could work:
- a keyword based filter to get only the elements one
is interested into listed
- a table of layers, with links, lots of them. Each
link points to an editing page, so from this one
we can not only inspect layers, but also workspaces
and stores
- checkboxes for a global, full list, not per page,
selection model
- a remove link, that should pop up a dialog asking
delete confirmation, with a list of the
actual selection contents
- a drop down with datastores, you chosee one,
you get into a dialog/page that lists all the layers
that are still un-configured for that store.
If we don't any, we can just pop up a warning, if
just one, go straight to the configuration of the
layer, if many, have the user choose (for the moment,
just one, later, choose a set and leverage some
auto-config)
- the headers should be clickable to get a globally
sorted list (on a single column). Still have to implement
this.

It's pretty minimalistic, but should work.

What about stores and worksapces? Well, I was considering
using the same approach, in two separate pages, it's simple
enough, and uniformity is a good thing.

So for workspaces a very simple table, a link to remove
the selected ws, and one to add a new one. In case of
removal, show which datastores and layers will be removed,
if confirmed, cascade delete.

For stores, same deal.

It's not as compact as the data tree, but scales up well,
and seems pretty simple to use (and a lot easier to implement).

Thoughts?
Cheers
Andrea

PS: menu wise you see "resources" which is the old data
tree, and layers, which is the page you're looking at.
For workspaces and stores we could do something similar,
that is, add two more menu items. Alternatively, we
can decide to have a single "resources" page and have
three tabs on top of it to switch between ws, stores
and layers. Imho it would start to be too much nesting, but
I'm happy to be convinced otherwise :slight_smile:

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
<layerList.png>

7

Christopher Patterson wrote:

I think this looks like a huge improvement over the tree structure.

The only question I had from the mockup was about the links on each row of the result table:

http://skitch.com/dimmerswitch/bfa45/layerlist

It's not immediately clear (from looking) where those links would take me. Would adding "[Edit]" buttons or text potentially clarify where each of those might point?

Each links brings you to an edit page for the workspace, store and layer
respectively. Imho adding a edit icon would just clutter the UI, and it
does not seem hard to figure out when you're looking at a working
UI: you follow the link the first time, you see where it brings you,
and then you should just know about it... or not?

Especially if all of the links in the tables bring you to edit pages,
that is, if we're consistent throught the UI. Like, for example,
adopting the same approach in the style list page.

What do you think?
Cheers
Andrea

8

Christopher Patterson ha scritto:

On Feb 23, 2009, at 5:10 PM, Andrea Aime wrote:

Sorry for my late answer, did not see your mail while I was in NY
(mail client without folder filtering rules, resulting in ~200 mails
dropping in the same folder a day).

Christopher Patterson wrote:

I think this looks like a huge improvement over the tree structure.
The only question I had from the mockup was about the links on each row of the result table:
http://skitch.com/dimmerswitch/bfa45/layerlist
It's not immediately clear (from looking) where those links would take me. Would adding "[Edit]" buttons or text potentially clarify where each of those might point?

Each links brings you to an edit page for the workspace, store and layer
respectively. Imho adding a edit icon would just clutter the UI, and it
does not seem hard to figure out when you're looking at a working
UI: you follow the link the first time, you see where it brings you,
and then you should just know about it... or not?

Geoserver may be exceptional in that you'll tend to have fewer / deeper users, so they'll learn the conventions. Although I'm not a fan of interfaces where you have to click a link to discover where it goes, I'm aware that I'm not necessarily a representative Geoserver user.

Mumble.... the alternative would be to add a edit icon on the side of
each link, and repeat it along the table? That would end up adding
10 * 5 = 50 equal icons into the table (assuming 10 rows per page,
and 5 columns with a link, did not really count them), that's why I used the world "clutter" :wink:

Maybe we could add a tooltip on links with an explanation instead?

Especially if all of the links in the tables bring you to edit pages,
that is, if we're consistent throught the UI. Like, for example,
adopting the same approach in the style list page.

Sure. I'd be +1 on this approach as long as we do it consistently: whenever we're displaying a table of results, links should take you to the relevant edit page. This also means that delete functionality would be removed from the individual rows, in favor of the click-to-select, then delete approach in Andrea's mockup. I'm not against that change, but wanted to mention it up front.

Yup, the idea would be that each table shows one type of object
(layers, in the mockup page you've seen) and the selection allows
one to delete only that kind of object. So in the layers page
one would have the selection, and that would affect only
deleting the layers, the links to stores and workspaces are
provided only as a convenience for inspection/quick editing,
but if one want to delete stores, he would have to go into
the page that do list stores instead.

My guess is that the most common operation against
stores and workspaces is actually deleting just one (as opposed
to a group of them), so we should probably add a "delete this"
operation into the edit pages as well, just as it happens
in a some wiki systems (confluence comes to mind).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.