web2 ui: Improve Namespace editor
---------------------------------
Key: GEOS-2074
URL: http://jira.codehaus.org/browse/GEOS-2074
Project: GeoServer
Issue Type: Bug
Components: WMS
Reporter: Andrea Aime
Assignee: David Winslow
Fix For: 2.0
Based on discussion on IRC, it would be good to modify the page so that:
* the label gets reset if the user clicks outside of the text editor instead of
pressing ENTER
* mimick flickr behaviour, add an OK and CANCEL button when the label turns
into a text box for editing
* provide feedback msg for both successful changes and failures, ideally at the
end of the top header section
Full IRC log:
{panel}
18.13.51) aaime: Namespace manager:
http://geo.openplans.org/~aaime/2719210873_c36ef14e86_o.png
(18.14.08) dwins: i don't see the alternating colors here in ff3
(18.14.29) aaime: I was using ff2 and I can see a light light light gray bg on
odd items
(18.14.38) aaime: so light that I don't see it if I look at it directly
(18.14.45) tenzochris: okay, I may have gone too subtle then
(18.14.56) aaime: tenzochris, rpenate made me notice
(18.14.58) tenzochris: last time I did alternating rows I got jumped on for
being heavy-handed :)
(18.15.16) aaime: there is a difference in color rendering between Mac and
Win/Lin
(18.15.33) aaime: I believe different alpha settings, not sure
(18.15.40) ahocevar [EMAIL PROTECTED] è entrato nella stanza.
(18.15.42) aaime: (or color temperature)
(18.15.46) tenzochris: aaime: gamma I think ,but yeah I know that YMMV
(18.15.51) aaime: gamma, right
(18.15.57) tenzochris: I can make those more contrasty
(18.16.04) ***dwins gets out his color picker app
(18.16.07) vhamer [EMAIL PROTECTED] è entrato nella stanza.
(18.16.09) aaime: lol
(18.16.22) dwins: oops, I still have to fix that compile issue
(18.16.48) tenzochris: the hover effect I'm okay with being subtle - the row
isn't selected, it's just an aid in scanning
(18.17.03) tenzochris: consciously seeing it is less important
(18.17.06) aaime: yeah, but I can only see it on odd rows
(18.17.15) aaime: (gamma issue again I guess)
(18.17.33) tenzochris: aaime: that's fair - I'll try to make it similarly
visible on each
(18.17.57) tenzochris: I agree with the tabbing, but no idea how to fix, since
AFACT wicket is creating those on the fly
(18.18.13) tenzochris: ditto on clicking out behavior
(18.18.22) aaime: I see
(18.18.28) aaime: dwins, this is yours then?
(18.18.43) dwins: sorry?
(18.19.07) aaime: see comments in the sshot
(18.19.15) aaime: in place editing is hard to use imho
(18.19.17) dwins: the problem is that if you deselect the element it saves your
change without asking?
(18.19.24) aaime: no, it does not save
(18.19.30) dwins: ah
(18.19.30) aaime: but the label is not reset to the old value
(18.19.44) aaime: I also find it annoying I cannot tab to the next element
(18.19.53) tenzochris: hitting enter submits, clicking elsewhere does not
(18.19.59) dwins: so do you want in-place editing, or not?
(18.20.08) aaime: eh, good question :)
(18.20.11) aaime: seems kind of cool
(18.20.57) aaime: dunno, let's ask other people maybe?
(18.21.01) aaime: or see reactions?
(18.21.27) aaime: but at least let's fix the "click outside" issue
(18.21.42) tenzochris: I like it, but the clicking off the field should revert
to the old value - and messaging indicating when changes are saved would help
(18.22.25) aaime: like a status bar for messages at the bottom of the window?
(18.22.27) tenzochris: if we add messaging it should pull in to the same place
as normal form-submission confirmation
(18.23.06) aaime: ah right, one thing I did not try was to force in a mistake,
like trying to set two prefixes to the same value
(18.23.12) aaime: (what feedback do you get?)
(18.23.29) tenzochris: towards the top of the page is a more common place for
those kinds of messages, but as long as we're consistent I'm less concerned
with the actual location
(18.23.48) tenzochris: aaime: good point - we may need failure messaging as well
(18.23.57) aaime: tried, got no message, but it did not update
(18.24.23) aaime: actually, it seems to never save, period (not even when the
value is ok)
(18.24.26) dwins: probably an 'okay' button should come up next to the field
while you're editing
(18.24.44) dwins: a number of pages aren't actually hooked up right now
(18.24.57) aaime: Meh, at that point it's probably better to have a separate
edit window?
(18.25.10) aaime: (with its own errors messages in the usual places and the
like)
(18.25.32) dwins: what point?
(18.26.25) aaime: having to add a ok button aside of the edit field
(18.27.10) tenzochris: we'd also need a cancel button
(18.27.26) tenzochris: (flickr does this for in-place editing, but of course I
can't access it atm :))
(18.27.37) dwins: i'm thinking just a little ok/cancel link so that it's got
something to click on
(18.27.38) groldan ha abbandonato la stanza (quit: Connection timed out).
(18.27.53) dwins: for those of us who don't guess all the keyboard shortcuts
(18.28.21) aaime: which is looking more and more like like a small form
(18.28.33) aaime: tenzochris, yes, saw what flickr does
(18.28.37) aaime: but it's separate fields
(18.28.54) aaime: with this kind of editing you may the config inconsistent for
some time
(18.29.04) aaime: (if you need to change both prefix and url)
(18.29.15) tenzochris: aaime: good point - folks here would be editing two at a
time (on this screen at least)
(18.29.36) aaime: like, they should...
(18.29.49) tenzochris: dwins: if adding status messages & okay / cancel isn't
too daunting, in-place editing would be nice imo
(18.30.05) dwins: what status message?
(18.30.08) tenzochris: it wouldn't address aaime's desire for tabbing through
fields
(18.30.29) aaime: tenzochris, that's a minor annoyance
(18.30.43) aaime: dwins, messages telling you that save did go we or that you
made a mistake
(18.30.50) aaime: (we -> well()
(18.31.34) tenzochris: dwins: messaging indicating when changes are saved would
help (it should pull in to the same place as normal form-submission
confirmation). any validation error messages should also be pulled in to the
same place as normal validation errors (ideally, in the same screen location as
confirmation messages, just styled differently)
(18.31.52) dwins: where is that place going to be?
(18.32.09) tenzochris: dwins: towards the top of the page is a more common
place for those kinds of messages, but as long as we're consistent I'm less
concerned with the actual location
(18.32.34) tenzochris: I'd vote for that being at the end of the page-header div
{panel}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
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
