[Geoserver-devel] Preview page updated

Andrea_Aime3 · April 7, 2009, 2:05pm

Hi,
so here is the preview page in its last incarnation.
The two dropdowns were taking too much horizontal
space so I went back and did as you suggested, using
a select with optgroup.

The page is missing a title. And all the wfs output
formats are using 50 as the max number of features
returned, to avoid people killing gs while playing
with the preview over big layers, I guess I'll have
to make this configuraable (little js managed text box
on the page I guess)

Cheers
Andrea

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

(attachments)

Michael_Melvin · April 7, 2009, 2:15pm

Thanks Andrea. Screenshots are very helpful for those who aren't ready to build their own trunk.

Q: Are we going to replace the MIME types in that pull down list with more human-readable entries? Or perhaps have the MIME types in parentheses (or as tooltips?)

I've not been following the discussion terribly closely, so sorry if this was discussed already.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Andrea Aime wrote:

Hi,
so here is the preview page in its last incarnation.
The two dropdowns were taking too much horizontal
space so I went back and did as you suggested, using
a select with optgroup.

The page is missing a title. And all the wfs output
formats are using 50 as the max number of features
returned, to avoid people killing gs while playing
with the preview over big layers, I guess I'll have
to make this configuraable (little js managed text box
on the page I guess)

Cheers
Andrea

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

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com

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

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

Andrea_Aime3 · April 7, 2009, 3:12pm

Mike Pumphrey ha scritto:

Thanks Andrea. Screenshots are very helpful for those who aren't ready to build their own trunk.

Q: Are we going to replace the MIME types in that pull down list with more human-readable entries? Or perhaps have the MIME types in parentheses (or as tooltips?)

Mumble, I'm a little torn on that one. That drop down is kind of the "advanced" thing of that dropdown. To make for human readable names
we'd have to extend the output formats classes to provide a straight name, or try to use the mime as an entry into the i18n files (not sure
mime types are valid property names thought).
Not sure which path to go, but the issue might be deeper than just the
UI page code.

Cheers
Andrea

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

Michael_Melvin · April 7, 2009, 4:06pm

Hmm. I think that menu is likely to be used by standard users as well as developers. If I wanted to get a shapefile output, I would need to navigate this menu and I would only find SHAPE-ZIP, which someone may not know is a zipped shapefile. Okay maybe not the best example, but I still think it should be user facing if at all possible. (I know it's easy for me to say this since I won't be the one coding it!)

I can file a JIRA for this, and Those Who Implement can decide whether to fix or ignore?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Andrea Aime wrote:

Mike Pumphrey ha scritto:

Thanks Andrea. Screenshots are very helpful for those who aren't ready to build their own trunk.

Q: Are we going to replace the MIME types in that pull down list with more human-readable entries? Or perhaps have the MIME types in parentheses (or as tooltips?)

Mumble, I'm a little torn on that one. That drop down is kind of the "advanced" thing of that dropdown. To make for human readable names
we'd have to extend the output formats classes to provide a straight name, or try to use the mime as an entry into the i18n files (not sure
mime types are valid property names thought).
Not sure which path to go, but the issue might be deeper than just the
UI page code.

Cheers
Andrea

Andrea_Aime3 · April 7, 2009, 4:09pm

Mike Pumphrey ha scritto:

Hmm. I think that menu is likely to be used by standard users as well as developers. If I wanted to get a shapefile output, I would need to navigate this menu and I would only find SHAPE-ZIP, which someone may not know is a zipped shapefile. Okay maybe not the best example, but I still think it should be user facing if at all possible. (I know it's easy for me to say this since I won't be the one coding it!)

I can file a JIRA for this, and Those Who Implement can decide whether to fix or ignore?

Sounds good to me
Cheers
Andrea

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

Michael_Melvin · April 7, 2009, 4:16pm

Done:

http://jira.codehaus.org/browse/GEOS-2836

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Andrea Aime wrote:

Mike Pumphrey ha scritto:

Hmm. I think that menu is likely to be used by standard users as well as developers. If I wanted to get a shapefile output, I would need to navigate this menu and I would only find SHAPE-ZIP, which someone may not know is a zipped shapefile. Okay maybe not the best example, but I still think it should be user facing if at all possible. (I know it's easy for me to say this since I won't be the one coding it!)

I can file a JIRA for this, and Those Who Implement can decide whether to fix or ignore?

Sounds good to me
Cheers
Andrea

Cliff_Patterson1 · April 7, 2009, 5:05pm

Consolidating feedback based on some discussion in #toppdzn :

* Big +1 on having the MIME types in that dropdown be more human readable.
* Rollie's been curating a set of GeoSilk icons for styler, which includes icons to indicate vector-based / rasterized output. It'd be nice to use these in the 'Type' column instead of the strings "Vector" and "Raster". We could include tooltip text to clarify for newer users via the "title" attribute.
* Let's consolidate the "Workspace" and "Name" columns into Qualified names
* Let's add "Title" as a column
* Both Qualified name and Title should link to GeoSearch pages whenever those exist. Otherwise, let's leave the text unlinked.

I can turn these into a JIRA if that's best (I see that Mike created GEOS-2836 for the human-readable dropdown text), but wanted to bring these to the list for discussion first.

Chris

On Apr 7, 2009, at 10:12 AM, Andrea Aime wrote:

Mike Pumphrey ha scritto:

Thanks Andrea. Screenshots are very helpful for those who aren't ready to build their own trunk.

Q: Are we going to replace the MIME types in that pull down list with more human-readable entries? Or perhaps have the MIME types in parentheses (or as tooltips?)

Mumble, I'm a little torn on that one. That drop down is kind of the
"advanced" thing of that dropdown. To make for human readable names
we'd have to extend the output formats classes to provide a straight
name, or try to use the mime as an entry into the i18n files (not sure
mime types are valid property names thought).
Not sure which path to go, but the issue might be deeper than just the
UI page code.

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Andrea_Aime3 · April 7, 2009, 5:23pm

Christopher Patterson ha scritto:

Consolidating feedback based on some discussion in #toppdzn :

* Big +1 on having the MIME types in that dropdown be more human readable.

Ok, ok, I'll look into it.

* Rollie's been curating a set of GeoSilk icons for styler, which includes icons to indicate vector-based / rasterized output. It'd be nice to use these in the 'Type' column instead of the strings "Vector" and "Raster". We could include tooltip text to clarify for newer users via the "title" attribute.

We already have a icon set, I just haven't had the time to use them
again (we were using them in the data tree). But I'm open to upgrading
them.
Anyways, icon usage wise, we have a jira already:
http://jira.codehaus.org/browse/GEOS-2717
which is part of a larger umbrella of improvements (non feature parity
with the old ui) tasks:
http://jira.codehaus.org/browse/GEOS-2705

Anyways, I wanted to tackle this today anyways, or at worst tomorrow, so
I'll follow up with a new screenshot "shortly".

* Let's consolidate the "Workspace" and "Name" columns into Qualified names

That way it's no more possible to sort them independently thought.

* Let's add "Title" as a column

That can be quite long, how can I fit it into the table?
(Quite long: one row long)

* Both Qualified name and Title should link to GeoSearch pages whenever those exist. Otherwise, let's leave the text unlinked.

They will stay unlinked until geosearch graduates (it still hasn't
if I'm up to date, but I'm really giving up trying to follow all
that's happening lately, I cannot keep up).

Cheers
Andrea

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

Chris_Holmes1 · April 7, 2009, 5:38pm

>> * Let's add "Title" as a column

That can be quite long, how can I fit it into the table?
(Quite long: one row long)

Well, having it listed here will probably help make people put less long Titles on their layers. Which they probably should, since it's used in other UI's, like GeoExt, where it shouldn't be so long there. We might have to adjust some of our titles, but I think our UI should be gently pushing people to best practices.