Hi,
the current CSS editor allows to edit associations between styles and layers with
the following dialog:
The dialog reacts immediately as one clicks on the checkboxes (notice the lack of a save button) and
associates the style with the layer as a secondary style.
The workflow is a bit odd as the rest of the user interface has save buttons, but it is understandable,
as with a paginated view it’s hard to see what one has selected before pressing the save button
anyways, and the association is non destructive, it’s not like you cannot easily undo what was
done by checking the button (you just press it another time).
However, there is no way to associate the style to a layer, as the default style, which is often
what the user wants to do when creating a new style.
Do you mind if we add this possibility via a new link, plus confirmation dialog?
Something like this:
(maybe the message could read "Current default style for topp:DrillHole is X. Make “point” the default style instead).
I believe the confirmation dialog is necessary in this case as there is no “quick link” to undo
the association, you have to either change the current style in the css dialog, or go to the layer
page
Opinions?
Do you mind if we add this one in the feature freeze, it’s a small feature in a extension module,
and more importantly, its logic would be decoupled from the rest of the code, so no chance of making existing
code regress.
I am not a module maintainer of the css extension so disregard this feedback as appropriate. But I think it would help if we had a common understanding of how we think and want the css module to evolve. Is the current incarnation of the UI what is intended to be there permanently? Or is a more integrated approach in the long term desired? And if a more integrated approach is desired how much of the current UI do we expect to salvage?
My opinion is that a more integrated approach with the current SLD editor would be a better long term plan. With the addition of a live map to render styles on the fly for instant feedback without having to navigate outside to the layer preview.
All that said I think any changes to the current UI are fine, even in feature freeze. And hopefully we can eventually implement the grand vision with the proper mandate and funding.
Hi,
the current CSS editor allows to edit associations between styles and layers with
the following dialog:
The dialog reacts immediately as one clicks on the checkboxes (notice the lack of a save button) and
associates the style with the layer as a secondary style.
The workflow is a bit odd as the rest of the user interface has save buttons, but it is understandable,
as with a paginated view it’s hard to see what one has selected before pressing the save button
anyways, and the association is non destructive, it’s not like you cannot easily undo what was
done by checking the button (you just press it another time).
However, there is no way to associate the style to a layer, as the default style, which is often
what the user wants to do when creating a new style.
Do you mind if we add this possibility via a new link, plus confirmation dialog?
Something like this:
(maybe the message could read "Current default style for topp:DrillHole is X. Make “point” the default style instead).
I believe the confirmation dialog is necessary in this case as there is no “quick link” to undo
the association, you have to either change the current style in the css dialog, or go to the layer
page
Opinions?
Do you mind if we add this one in the feature freeze, it’s a small feature in a extension module,
and more importantly, its logic would be decoupled from the rest of the code, so no chance of making existing
code regress.
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
On Wed, Jan 29, 2014 at 4:43 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
I am not a module maintainer of the css extension so disregard this
feedback as appropriate. But I think it would help if we had a common
understanding of how we think and want the css module to evolve. Is the
current incarnation of the UI what is intended to be there permanently? Or
is a more integrated approach in the long term desired? And if a more
integrated approach is desired how much of the current UI do we expect to
salvage?
Right. I agree we want a more integrated approach, and as a result, we
might have to throw away parts of the CSS GUI.
While I would like to see most of the existing functionality just be there
for SLD as well, we might have to rethink the
layout and interaction to make it usable with SLD styles, that need a much
larger amount of space to be edited
(they're just a lot bigger).
So... I'd go for the simplest solution that could possibly work for the
"associate style as default one with layer" functionality
for the time being.
All that said I think any changes to the current UI are fine, even in
feature freeze. And hopefully we can eventually implement the grand vision
with the proper mandate and funding.
Right... the more "usable" the current CSS module gets, they higher the
likeliness to find funding
to get significant funding to get it on par with SLD config wise (I find
that people are more willing
to invest if the functionality is 80/90% there already, both if in case of
real funding, that in the
case of spending own spare time).
Start with the CSS editor, and allow the editing area to be either CSS or SLD
Move some of the long text links from the top of the CSS editor closer to where they apply (example the layer preview settings to the layer preview tab, the upload SLD to the SLD editor, etc…)
Consider moving the preview tabs on top of the editor (allowing the editor to be longer for SLD)
I am not a module maintainer of the css extension so disregard this feedback as appropriate. But I think it would help if we had a common understanding of how we think and want the css module to evolve. Is the current incarnation of the UI what is intended to be there permanently? Or is a more integrated approach in the long term desired? And if a more integrated approach is desired how much of the current UI do we expect to salvage?
My opinion is that a more integrated approach with the current SLD editor would be a better long term plan. With the addition of a live map to render styles on the fly for instant feedback without having to navigate outside to the layer preview.
All that said I think any changes to the current UI are fine, even in feature freeze. And hopefully we can eventually implement the grand vision with the proper mandate and funding.
$0.02
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
Hi,
the current CSS editor allows to edit associations between styles and layers with
the following dialog:
The dialog reacts immediately as one clicks on the checkboxes (notice the lack of a save button) and
associates the style with the layer as a secondary style.
The workflow is a bit odd as the rest of the user interface has save buttons, but it is understandable,
as with a paginated view it’s hard to see what one has selected before pressing the save button
anyways, and the association is non destructive, it’s not like you cannot easily undo what was
done by checking the button (you just press it another time).
However, there is no way to associate the style to a layer, as the default style, which is often
what the user wants to do when creating a new style.
Do you mind if we add this possibility via a new link, plus confirmation dialog?
Something like this:
(maybe the message could read "Current default style for topp:DrillHole is X. Make “point” the default style instead).
I believe the confirmation dialog is necessary in this case as there is no “quick link” to undo
the association, you have to either change the current style in the css dialog, or go to the layer
page
Opinions?
Do you mind if we add this one in the feature freeze, it’s a small feature in a extension module,
and more importantly, its logic would be decoupled from the rest of the code, so no chance of making existing
code regress.
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
Hi all,
to close this one, here is my final proposal:
I am going to implement what I’ve proposed, as a short term solution
I’ve scheduled a story to make the current CSS page no longer be necessary here http://jira.codehaus.org/browse/GEOS-6325, referring to Justin’s work.
Hopefully we can make that work by 2.6, does not look like it would need a major amount of extra work, maybe we can organize and get it done in
spare time?
Hi,
the current CSS editor allows to edit associations between styles and layers with
the following dialog:
The dialog reacts immediately as one clicks on the checkboxes (notice the lack of a save button) and
associates the style with the layer as a secondary style.
The workflow is a bit odd as the rest of the user interface has save buttons, but it is understandable,
as with a paginated view it’s hard to see what one has selected before pressing the save button
anyways, and the association is non destructive, it’s not like you cannot easily undo what was
done by checking the button (you just press it another time).
However, there is no way to associate the style to a layer, as the default style, which is often
what the user wants to do when creating a new style.
Do you mind if we add this possibility via a new link, plus confirmation dialog?
Something like this:
(maybe the message could read "Current default style for topp:DrillHole is X. Make “point” the default style instead).
I believe the confirmation dialog is necessary in this case as there is no “quick link” to undo
the association, you have to either change the current style in the css dialog, or go to the layer
page
Opinions?
Do you mind if we add this one in the feature freeze, it’s a small feature in a extension module,
and more importantly, its logic would be decoupled from the rest of the code, so no chance of making existing
code regress.
