[Geoserver-devel] a couple of ui thoughts

GeoServer GeoServer Developer
1

First off I want to say that its looking great, some great work was done while I was away. However there are a few things i noticed today while hooking up persistence. I am curious as to other peoples thoughts.

* use of word "Manager"

It seems redundant. I mean... we could call everything a "manager" that is used to configure. What was wrong with "Resources", "Namespaces", and "Styles" in the menu?

* feedback under page heading

Feedback messages appear above the page heading and description. I think it might be a bit nicer if it apperd below the heading, and above the rest of the page content. Or maybe on the right hand side of the page so that none of the main content on the page shifts up and down.

* use of icons vs buttons

On the resources page, we have icons for add,edit,delete, but on the namespaces and style pages we have buttons with words on them. I am wondering if we could make these consistent, or if there is an explicit reason. I suspect maybe because of the limited real estate in the resource tree?

* line between data and publishing seems blurred

If you look at the ResourceConfigurationPage, the data tab seems to have content that i would think belongs on the publishing side of the fence. Things like title,keywords,abstract, and published bounding box all belong on the layer that is published, not the native resource. I cant remember if we came up with this at the sprint, i apologize for being out of the loop for so long.

-JD

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

2

Justin Deoliveira ha scritto:

First off I want to say that its looking great, some great work was done while I was away. However there are a few things i noticed today while hooking up persistence. I am curious as to other peoples thoughts.

* use of word "Manager"

It seems redundant. I mean... we could call everything a "manager" that is used to configure. What was wrong with "Resources", "Namespaces", and "Styles" in the menu?

I don't mind the names either way.

* feedback under page heading

Feedback messages appear above the page heading and description. I think it might be a bit nicer if it apperd below the heading, and above the rest of the page content. Or maybe on the right hand side of the page so that none of the main content on the page shifts up and down.

jdeolive++
It's easy to move too, just change its location in the main page.

* use of icons vs buttons

On the resources page, we have icons for add,edit,delete, but on the namespaces and style pages we have buttons with words on them. I am wondering if we could make these consistent, or if there is an explicit reason. I suspect maybe because of the limited real estate in the resource tree?

I think it was just because icons looked nicer, but buttons with text
you understand at a glance. One problem with buttons is that they use
lots of vertical space, that I perceive as a problem.

* line between data and publishing seems blurred

If you look at the ResourceConfigurationPage, the data tab seems to have content that i would think belongs on the publishing side of the fence. Things like title,keywords,abstract, and published bounding box all belong on the layer that is published, not the native resource. I cant remember if we came up with this at the sprint, i apologize for being out of the loop for so long.

I don't remember exactly me neither. I kind of remember something along
these lines: provide some basic publishing infos in the resource as
well, and have them play the role of the default for the layers, and
also be _the_ values for the "default" map, the one that you don't have
to manually configure and that shows everything by default (to avoid
adding extra steps that weren't there in the old interface, for the
simple case where just one map is sufficient).

Having title/keywords/abstract in a separate section is ok to me,
I'm a little disturbed by the idea of having the wgs84 bbox away
from the native one, since they do pretty much depend on each other.

Cheers
Andrea

3

Andrea Aime wrote:

Justin Deoliveira ha scritto:
  

First off I want to say that its looking great, some great work was done while I was away. However there are a few things i noticed today while hooking up persistence. I am curious as to other peoples thoughts.

* use of word "Manager"

It seems redundant. I mean... we could call everything a "manager" that is used to configure. What was wrong with "Resources", "Namespaces", and "Styles" in the menu?
    
I don't mind the names either way.

I am in agreement with Justin on this.

* feedback under page heading

Feedback messages appear above the page heading and description. I think it might be a bit nicer if it apperd below the heading, and above the rest of the page content. Or maybe on the right hand side of the page so that none of the main content on the page shifts up and down.
    
jdeolive++
It's easy to move too, just change its location in the main page.

I don't think we should put the feedback messages in the sidebar, they are a 'local' thing and sidebar stuff is 'global.' Above or below the title doesn't feel like it makes a big difference to me though. (Maybe we could move page titles into the page header?)

* use of icons vs buttons

On the resources page, we have icons for add,edit,delete, but on the namespaces and style pages we have buttons with words on them. I am wondering if we could make these consistent, or if there is an explicit reason. I suspect maybe because of the limited real estate in the resource tree?
    
I think it was just because icons looked nicer, but buttons with text
you understand at a glance. One problem with buttons is that they use
lots of vertical space, that I perceive as a problem.
  

It shouldn't be a problem to reduce the padding on the buttons or just make them simple (borderless) links. Best of both worlds?

  

* line between data and publishing seems blurred

If you look at the ResourceConfigurationPage, the data tab seems to have content that i would think belongs on the publishing side of the fence. Things like title,keywords,abstract, and published bounding box all belong on the layer that is published, not the native resource. I cant remember if we came up with this at the sprint, i apologize for being out of the loop for so long.
    
I don't remember exactly me neither. I kind of remember something along
these lines: provide some basic publishing infos in the resource as
well, and have them play the role of the default for the layers, and
also be _the_ values for the "default" map, the one that you don't have
to manually configure and that shows everything by default (to avoid
adding extra steps that weren't there in the old interface, for the
simple case where just one map is sufficient).

Having title/keywords/abstract in a separate section is ok to me,
I'm a little disturbed by the idea of having the wgs84 bbox away
from the native one, since they do pretty much depend on each other.
  

The ResourceConfigurationPage is divided up based on where settings are stored in the catalog API. Everything that comes from a ResourceInfo is on the Data side, everything that comes from a LayerInfo is on the publishing side.

The Publishing tab on a ResourceConfigurationPage should contain all the default settings for Layers based on that resource.

-David Winslow

4

On Aug 7, 2008, at 8:31 AM, David Winslow wrote:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

First off I want to say that its looking great, some great work was done
while I was away. However there are a few things i noticed today while
hooking up persistence. I am curious as to other peoples thoughts.

* use of word "Manager"

It seems redundant. I mean... we could call everything a "manager" that
is used to configure. What was wrong with "Resources", "Namespaces", and
"Styles" in the menu?

I don't mind the names either way.

I am in agreement with Justin on this.

+1 for removing "manager" from the sidebar items. I don't mind the names either way as page titles, though

* feedback under page heading

Feedback messages appear above the page heading and description. I think
it might be a bit nicer if it apperd below the heading, and above the
rest of the page content. Or maybe on the right hand side of the page so
that none of the main content on the page shifts up and down.

jdeolive++
It's easy to move too, just change its location in the main page.

I don't think we should put the feedback messages in the sidebar, they
are a 'local' thing and sidebar stuff is 'global.' Above or below the
title doesn't feel like it makes a big difference to me though. (Maybe
we could move page titles into the page header?)

Color me in agreement with dwins about not pushing feedback messages off to the side. I'm fine with them being above/below the page title, too.

I thought that page titles were supposed to be in the page-header div? I know some pages already have them there, but I haven't done a patrol to check for inconsistent usage.

* use of icons vs buttons

On the resources page, we have icons for add,edit,delete, but on the
namespaces and style pages we have buttons with words on them. I am
wondering if we could make these consistent, or if there is an explicit
reason. I suspect maybe because of the limited real estate in the
resource tree?

I think it was just because icons looked nicer, but buttons with text
you understand at a glance. One problem with buttons is that they use
lots of vertical space, that I perceive as a problem.

It shouldn't be a problem to reduce the padding on the buttons or just
make them simple (borderless) links. Best of both worlds?

I'm still not a fan of the tree view on this page, but agree with the idea to make the edit / delete buttons on the resources page more consistent with the rest of the UI.

* line between data and publishing seems blurred

If you look at the ResourceConfigurationPage, the data tab seems to have
content that i would think belongs on the publishing side of the fence.
Things like title,keywords,abstract, and published bounding box all
belong on the layer that is published, not the native resource. I cant
remember if we came up with this at the sprint, i apologize for being
out of the loop for so long.

I don't remember exactly me neither. I kind of remember something along
these lines: provide some basic publishing infos in the resource as
well, and have them play the role of the default for the layers, and
also be _the_ values for the "default" map, the one that you don't have
to manually configure and that shows everything by default (to avoid
adding extra steps that weren't there in the old interface, for the
simple case where just one map is sufficient).

Having title/keywords/abstract in a separate section is ok to me,
I'm a little disturbed by the idea of having the wgs84 bbox away
from the native one, since they do pretty much depend on each other.

The ResourceConfigurationPage is divided up based on where settings are
stored in the catalog API. Everything that comes from a ResourceInfo is
on the Data side, everything that comes from a LayerInfo is on the
publishing side.

The Publishing tab on a ResourceConfigurationPage should contain all
the default settings for Layers based on that resource.

-David Winslow

-------------------------------------------------------------------------
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

5

I don't think we should put the feedback messages in the sidebar, they are a 'local' thing and sidebar stuff is 'global.' Above or below the title doesn't feel like it makes a big difference to me though. (Maybe we could move page titles into the page header?)

Just to clarify i meant putting them on the right hand side of the page, and making them part of the "page content". By sidebar do you mean the navigation sidebar on the left? Or is there is a sidebar on the right handle side of the page i dont know about?

  

The ResourceConfigurationPage is divided up based on where settings are stored in the catalog API. Everything that comes from a ResourceInfo is on the Data side, everything that comes from a LayerInfo is on the publishing side.

You are correct, the api currently does not draw the line we keep speaking of, a lot of the publishing fields are on ResourceInfo. However that does not need to stop us from presenting those fields on the publishing tab.

Maybe it will just be easier to do it once we do have all the publishing related stuff on LayerInfo.

The Publishing tab on a ResourceConfigurationPage should contain all the default settings for Layers based on that resource.

-David Winslow

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

6

On Thursday 07 August 2008 10:31:15 am David Winslow wrote:

Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> First off I want to say that its looking great, some great work was done
>> while I was away. However there are a few things i noticed today while
>> hooking up persistence. I am curious as to other peoples thoughts.
>>
>> * use of word "Manager"
>>
>> It seems redundant. I mean... we could call everything a "manager" that
>> is used to configure. What was wrong with "Resources", "Namespaces", and
>> "Styles" in the menu?
>
> I don't mind the names either way.

I am in agreement with Justin on this.

>> * feedback under page heading
>>
>> Feedback messages appear above the page heading and description. I think
>> it might be a bit nicer if it apperd below the heading, and above the
>> rest of the page content. Or maybe on the right hand side of the page so
>> that none of the main content on the page shifts up and down.
>
> jdeolive++
> It's easy to move too, just change its location in the main page.

I don't think we should put the feedback messages in the sidebar, they
are a 'local' thing and sidebar stuff is 'global.' Above or below the
title doesn't feel like it makes a big difference to me though. (Maybe
we could move page titles into the page header?)

>> * use of icons vs buttons
>>
>> On the resources page, we have icons for add,edit,delete, but on the
>> namespaces and style pages we have buttons with words on them. I am
>> wondering if we could make these consistent, or if there is an explicit
>> reason. I suspect maybe because of the limited real estate in the
>> resource tree?
>
> I think it was just because icons looked nicer, but buttons with text
> you understand at a glance. One problem with buttons is that they use
> lots of vertical space, that I perceive as a problem.

It shouldn't be a problem to reduce the padding on the buttons or just
make them simple (borderless) links. Best of both worlds?

>> * line between data and publishing seems blurred
>>
>> If you look at the ResourceConfigurationPage, the data tab seems to have
>> content that i would think belongs on the publishing side of the fence.
>> Things like title,keywords,abstract, and published bounding box all
>> belong on the layer that is published, not the native resource. I cant
>> remember if we came up with this at the sprint, i apologize for being
>> out of the loop for so long.
>
> I don't remember exactly me neither. I kind of remember something along
> these lines: provide some basic publishing infos in the resource as
> well, and have them play the role of the default for the layers, and
> also be _the_ values for the "default" map, the one that you don't have
> to manually configure and that shows everything by default (to avoid
> adding extra steps that weren't there in the old interface, for the
> simple case where just one map is sufficient).
>
> Having title/keywords/abstract in a separate section is ok to me,
> I'm a little disturbed by the idea of having the wgs84 bbox away
> from the native one, since they do pretty much depend on each other.

The ResourceConfigurationPage is divided up based on where settings are
stored in the catalog API. Everything that comes from a ResourceInfo is
on the Data side, everything that comes from a LayerInfo is on the
publishing side.

The Publishing tab on a ResourceConfigurationPage should contain all
the default settings for Layers based on that resource.

on a related note, note I've added the available metadata for FeatureTypeInfo
from FeatureSource.getInfo(), tried it with arcsde and shapefile and seems to
be working quite well, providing default keyworkds, bounds, etc

Gabriel

-David Winslow

-------------------------------------------------------------------------
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