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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to