Hi all,
today we had a breakout meeting on #geoserver to discuss how to
move forward with the new UI, in terms of styles and functionality.
The participants to the meeting were all looking at a running GeoServer
with the new UI (which was running on my PC, so sorry, not available
for the world to see now).
The two core topics were:
- mixing wicket and extjs ui elements, how to deal with the obviuos
look and feel inconsistency? (think the styler integration, but
also the incoming geoext based layer preview)
The takeout from this is that we have two options
* we can redo the GeoServer css to look
like extjs components, but that might be difficult, and we had a
GSIP about branding and some time after that a designer redid the
GeoServer UI to use colors and fonts mandated by that GSIP,
so, do we still have to follow that GSIP?
And, how do other poeple feel about an GeoServer UI that looks
like a set of exjts widgets? (sample here:
http://extjswordpress.net/)
* we restyle the extjs UI to look like the new GeoServer UI instead,
that is, white background, blue titles, and so on.
We don't know how hard that would be, and would this be welcomed?
Of course a third option is possible, that is, to have the two
look different, but there was a decent consensus that it might
not have been the best way to go (feel free to say otherwise,
we're discussing this).
- second topic is a review of how the catalog tree UI is going to
be replaced with a pageable, sortable, filterable table based
pages, one for workspaces, one for stores and one for layers.
The topic goes on discussing how to increase connectinos between
the various pages, provide handy views for users, and how to
handle mass deletes
Feedback welcomed
Cheers
Andrea
----------------------------------------------------------------------
aaime: Ok, so to sum up, tenzochris is going to revamp the whole css one
more time?
tenzochris: and I think (from my taskload) that converting this to look
more like Styler is the biggest single task
jdeolive: would be easier to go the other way?
tenzochris: jdeolive: how so?
jdeolive: it seems to me like css is something easier changed in ext,
rather than wicket
jdeolive: but i am just guessing on that
tenzochris: jdeolive: that's an interesting question. I haven't played
with Ext at all, so don't know what that setup is like
tenzochris: there's probably an argument to be made that it'd be easier
to match styler (which is heavily Ext), by using Ext
tenzochris: I don't know what the implications are in terms of wicket
plus (or versus) Ext for any of this, though
jdeolive: no problem, i am open to either
aaime: there is no integration between the two, we'd have to grab a
javascript dev and make him redo the whole ui
aaime: (in pure javascript + rest)
aaime: I'm against this idea, but it's just me, if the GeoServer PSC
thinks it's better to redo it in javascript, so be it
jdeolive: tenzochris: yeah, we more or less decided that "integration"
would be just popping up a new page to run the javascript in
jdeolive: since integration is a pretty big pain
tenzochris: aaime: so it's sounding like a binary decision
jdeolive: aaime: noone is even putting that up for consideration :(
aaime: alterantives would be to have some ext components integrated in a
wicket page, but on that field, everything is to be developed from
scratch afaik
aaime: thought it's possible, there are existing jquery and dojo based
components in wicket as far as I know
jdeolive: and i managed to mock up an ext based one
jdeolive: but it was painful painful painful
jdeolive: and very basic
aaime: so having a wicket CSS that looks like extjs would indeed ease up
the future integration of extjs snipppets within a wicket based page
***jdeolive still thinks an ext css that looks like wicket would make
more sense at this point... and would ease aaime's hesitation to have
geoserver look like ext
jdeolive: i have seen ext demos that chagne teh style sheet and make the
app look completely differnet
jdeolive: i just think it has been better designed to allow for
customizabilty than wicket
jdeolive: i could be wrong
tenzochris: okay, so in terms of next steps, is this something the PSC
needs to discuss?
jdeolive: apologies for harping on this point
jdeolive: i will shut up now
aaime: Just take my UI hesitation as a personal feeling, I'm ok to have
the ui look like wicket, I just won't like it
tenzochris: or is the goal for me to come up with CSS for wicket which
matches the Ext work over on styler
pramsey [[email protected]] è entrato nella stanza.
aaime: (tyo have the ui look like extjs, that is)
aaime: tenzochris, afaik, another complete revamp should be matter of
some discussion on the ml at least
jdeolive: tenzochris: i was say the latter, and would prefer that we
make styler look like wicket, or come up with some common middle ground
between the two
aaime: given that the current UI look and feel was mandated by a proposal
aaime: and we have "rules" to have everytihng in geoserver look in a
certain way
aaime: logos, colors and so on
aaime: at least, that was what the look and feel gsip was all about, no?
pramsey ha abbandonato la stanza (quit: Remote closed the connection).
aaime: So to deviate from it at least some discussion on the ml is necessary
jdeolive: sure we can discuss / propose when tenzochris has somethnig to
show
aaime: indeed
***jdeolive thought that sort of went without saying :)
tenzochris: jdeolive: I'd prefer to have a little bit of direction up front
aaime: this is the relevant gsip:
http://geoserver.org/display/GEOS/GSIP+26+-+New+GeoServer+Branding
sigq: Title: GSIP 26 - New GeoServer Branding - GeoServer (at geoserver.org)
cabraham [[email protected]] è entrato nella stanza.
aaime: the new ui guidelines were made by some designer at OpenGeo,
don't remeber exaclty who
aaime: See also http://geoserver.org/display/GEOS/New+GeoServer+Branding
and
http://geoserver.org/download/attachments/10158143/GeoServer_BrandingGuide.pdf?version=3
sigq: Title: New GeoServer Branding - GeoServer (at geoserver.org)
tenzochris: the prospect of working to get the UI more Ext-ish only to
have it all thrown out is not super appealing
tenzochris: aaime: yeah, that was all acochran I think
jdeolive: tenzochris: i agree... which is why i think going the opposite
way is more appealing
jdeolive: and less of a change
aaime: tenzochris, would it be fast enough for you to make a quick
mockup of how it would look like without actually doing it?
aaime: So, tenzochris, would making a differet ext css be an option, or not?
aaime: Like, we don't know if it's hard/easy
aaime: (that is, a different stylesheet for styler)
aaime: (without actually doing it -> without actually redoing the
geoserver css)
tenzochris: aaime: because I haven't worked with Ext at all and have no
idea what kinds of conventions or style hooks they have, doing a quick
mockup is probably not realisitc
aaime: extjs wordpress there here: http://extjswordpress.net/
tenzochris: but if the direction we think we want to go is Styler when
shipped with Geoserver looks more like Geoserver, I can start looking at
how that might work
sigq: Title: Ext JS Wordpress Blog (at extjswordpress.net)
aaime: I guess It provides a decent idea of how the geoserver pages
would end up looking like?
aaime: So, let's recap the moving parts:
aaime: - geoserver has a css that follows some PSC mandated look&feel
guidelines. It can be changed, but after some discussion on the ml
aaime: - extjs has its own style, we don't know how hard it is to change
that to follow GeoSErver laf
aaime: - there is a desire for consistency
aaime: We can turn this into a mail on the gs-dev ml cc'ing the styler
people as well
jdeolive: #3 is my biggest concern
aaime: and see if we can reach any consensus
aaime: it just seems we're not in a position to take a decision on it
right now
jdeolive: tenzochris: I would say look breifly into option 2)
acochran [[email protected]] è entrato nella stanza.
jdeolive: if it looks like it will be a pain continue with part 1)
jdeolive: and like aaime says, we can propose it on the deoserver devel list
jdeolive: i don't think it will have a very hard time getting accepted
by teh community
aaime: I'll send a mail, so that if tenzochirs finds out it's hard to
restyle extjs (or the styler guys are simply against it) we have some
sort of backup to fall on
pramsey [[email protected]] è entrato nella stanza.
aaime: Let's move on?
tenzochris: aaime: reading the pages you linked, I don't see anything
about the app UI (like, dictating the current look and feel).
tenzochris: I'll move forward with seeing what the Extjs restyle options
are, regardless
aaime: Maybe I misunderstoo, but that css was re-made by some designer
on cholmes request to follow the new look and feel
aaime: (that is what I remember at least)
***jdeolive did not get the impression that set in stone
***jdeolive could be wrong though
aaime: A mail on the dev ml will clarify tghat
tenzochris: aaime: pretty sure the current 2.0 UI is just the work I did
on top of rpenate's, but I'm definitely in favor of this all being on
the mail list
aaime: I guess we discussed everything we could with just the 3 of us
aaime: mail and let's move forward?
tenzochris: sure - I'll look for the email, and will toddle off now to
learn about ext restyling :)
jdeolive: aaime: while on the subject do you want to continue on talking
about some esimtation stuff
aaime: sure just one question
aaime: I thought the topic of today was how the layers/stores/workspaces
revamp was going
aaime: and check with a designer is the direction was good
bmmpxf [[email protected]] è entrato nella stanza.
aaime: this css thing caught me totally by surprise :)
jdeolive: who is that question directed at?
aaime: the both of you I guess?
jdeolive: i am not sure, i just saw that you two were chatting about ui
stuff and was interested
aaime: thought I guess the expert on usability is tenzochris, so most to him
aaime: tenzochris, what do you think, still have time/energy to go
throught those pages?
tenzochris: oh - sorry to have derailed it. I'd grossly misunderstood
what you were looking for
aaime: no no, it's ok, the css topic is an important one too
tenzochris: aaime: I'm happy to look at the new layers / stores /
workspace stuff
cholmes [[email protected]] è entrato nella stanza.
aaime: cool
aaime: so, I guess both of you can go to the layers page
aaime: Generally speaking, any time there is a ton of information that
the user can go thru, I would like to setup things so that:
aaime: - the information is presented in a pageable table
rpenate [[email protected]] è entrato nella stanza.
aaime: - the table is sortable by clicking the headers
aaime: - it's possible to do a simple keyword filtering
jdeolive: aaime: what kind of feedback should we limit too here...
little nit picky stuff, or higher level workflow stuff?
aaime: - the links in the table bring the user to the relevant edit page
of the clicked entity
aaime: - the items are selectable, and the can be deleted
aaime: - some out of table control allows for adding new ones
aaime: jdeolive, I'm really open to anything
jdeolive: well my feedback is mostly small stuff... some of which i
already expressed on the mail list
jdeolive: so i could just do that
aaime: Another topic in which I'm looking forward to get some feedback is
tenzochris: aaime: is the only way a user will get to the "edit layer"
page via the Data > Layers result table?
aaime: for layers, yes
aaime: wheter the idea of having three separate pages, workspace, and
stores is a good one
aaime: tenzochris, the thing is, layer is a sort of a leaf, so it's the
only way
aaime: but stores and workspaces are repeated in the stores and
workspaces (missing) pages
jdeolive: it might make sense to have layers accessible from the store
page as well
aaime: I just thought it was handy to have direct links here too, since
we're citing the ws and stores anyways
jdeolive: the layers being limited (of course) to the ones coming from
that store
aaime: the stores page is a list of stores
aaime: (is the list of stores)
tenzochris: aaime: can a layer be associated with more than one store /
workspace pair?
aaime: no
jdeolive: aaime: i meant if you click on the link to a store
jdeolive: you go a page that has just connection info about that store
aaime: ah, in the store connection edit r page
aaime: yeah, it might make sense to add a tab that lists the layers in
that store
jdeolive: i think it would make sense to provide some info about rthe
resources of that store on that page as well
jdeolive: +1
tenzochris: aaime: okay, then on the layers page I think it'd be nice to
have links to the current store & workspace for the layer being viewed
aaime: tenzochris, you mean, in the page that allows one to edit the layer
tenzochris: aaime: yup
aaime: seems like a good idea, I like interconnectness
tenzochris: jdeolive beat me to my next enhancement request, which is
having stores / workspaces indicate what belong to them
aaime: so in the workspace editor, also have the list of stores into
that workspace
jdeolive: makes sense to me
aaime: do we want also some commands to add a new item there?
aaime: Like, adding a new store in a workspace?
jdeolive: i was just going to mention that for the store case
tenzochris: aaime: if that's at all a common case I think we ought to,
for sure
aaime: the same command is also in the general listings
aaime: so it would be available in multiple places
aaime: but I guess that would just make the interface easier to use
tenzochris: aaime: yeah, but we'd be able to pre-populate the "known"
information when coming from an existing store / workspace
aaime: as oppose to one that forces the user to go in a specific context
to get a specific action?
jdeolive: well, i dont think we want to give the user 10 ways to do one
thing
jdeolive: but in this case i think it makes sense
tenzochris: jdeolive: right
aaime: agreed
jdeolive: aaime: one thing for the store page might be a tab for
"available layers"?
aaime: yeah, the layers that the store might offer, but are still
un-configured
jdeolive: right
aaime: for that I was actually thinking something a little different,
let me explain
aaime: when the user chooses to add a new layer from a certain store
(see layers page)
aaime: I would like to show a page that contains all unconfigured layers
for that store
vhamer [[email protected]] è entrato nella stanza.
aaime: the user cherry picks what layers he wants to configure (just one
for starters)
aaime: and from there we go to the layer editor for the new layer
aaime: we could do the same for a "add layer" link inside the store page
jdeolive: yeah, seems like teh same workflow just with an extra step of
choosing the store if you are on the layer browser page
aaime: or have a tab that shows unconfigured layers, that actually
happens to be the same page the layers ui would lead to
aaime: yep, on the layers page I made it so that you go to the
unconfigured layer page the moment you choose an item in the drop down
aaime: so it's very "quick"
aaime: (actually atm you get a dialog, but you get the idea)
aaime: it makes sense to me because you are in the layers list
aaime: you can delete some
juliatorti [[email protected]] è entrato nella
stanza.
aaime: so it makes sense to have an "add" action as well?
aaime: "these are the layers, how do I make a new one? Oh, there is the
command, on the bottom of the page"
jdeolive: yup, i am for having the add remove on the layers browser page
jdeolive: in addition to on the store page
aaime: cool
aaime: tenzochris?
tenzochris: +1 from me on that (I think I've followed the conversation
correctly)
aaime: also, for uniformity sake, I would like to redo the styles page
using the same approach
tenzochris: aaime: is deleting layers / stores / workspaces something
which is common to do in batches?
aaime: tenzochris, for layers I believe it might be
aaime: for stores, not so common, but it's a quick way for a user to get
a clean data directory starting from the release one that contains quite
a bit of sample data
aaime: same goes for workspaces
tenzochris: here's what I'm struggling with - all of the other
interactions with rows in those result tables are for a single record,
and immediately take place
jdeolive: agreed... although i would be against having this
functionality on teh workspace and store pages
aaime: Note that deletion of a workspace would have to trigger some sort
of confirmation dialog listing all the stores and layers you're going to
wipe out
tenzochris: for delete, you have to check the appropriate boxes, and
then hit the "remove" button
aaime: actually add is not part of the rows, either
aaime: rows bring you to a different page
tenzochris: aaime: correct, although that's outside the table and is a
one-step action, right?
aaime: actually starts a sequence of pages you have to go thru
aaime: but withing the page, yeah, it's a one shot action
tenzochris: right
aaime: So if we add a "delete this" link in the row, how does one delete
multiple layers?
tenzochris: if we're making it different on purpose (to highlight that
deletion is a more "heavy" change) I can see it
tenzochris: aaime: if we did it in the row, I'd want the form submission
done via ajax
aaime: we can do that
aaime: but a user might want to delete many, really many
tenzochris: poof out the row (or other visual feedback), then reload the
existing results to fill in the gap (assuming that's fast enough)
aaime: we have users with thousands of layers configured
aaime: (see also the person with the OOM today on the ml, he said the
layers he's managing go into the 4 digits numbers)
tenzochris: aaime: yowza. although with the current approach, they'd
still have to click each layer in turn
tenzochris: then also click the remove selected, right?
aaime: right, I was thinking to add a select all
aaime: which would only select the current set of filtered layers
aaime: but maybe we could have single shot delete in this page, and have
batch deletes in a separate one?
tenzochris: aaime: would a delete all serve a similar purpose? iow,
would it be reasonable for a user to filter their result set
tenzochris: to get just the ones they wanted to get rid of
tenzochris: then blow them all away?
aaime: Hum... makes sense to me
jdeolive: i still thkn that might be cumbersome
aaime: how? :)
jdeolive: b/c they probably get a filter which matches some layers, but
don't want to delete all of the, but rather do some manual filtering
jdeolive: ie, give me layers from this database
jdeolive: returns 10
jdeolive: now i want to delete just 5 of them
jdeolive: sort of thing
aaime: size matters
tenzochris: I guess part of the question is UI responsiveness, too
aaime: 5 out of them you can do manually one by one
aaime: (delete 5 times)
jdeolive: oh god
jdeolive: and go through 5 confirmation dialogs
aaime: right right, I would not be confortable without a confirmation
dialog around
aaime: I for one am too fast clickling and sometimes I just pick the
wrong element in lists
jdeolive: yup
jdeolive: and now that we dont have an apply save workflow
jdeolive: confirmation dialogs are necessary
aaime: well, what about putting the batch deletes in their separate page?
aaime: maybe red background, scary background music. This is the place
where you can obliterate your server!
jdeolive: like only support batch deletes on the store page?
aaime: (kidding about the details, not about the idea)
aaime: No, I would like like to have batch deletes everywhere, but have
that functinality sitting in its own separage page
tenzochris: aaime: oh I see. so a link to that could be at the bottom of
the table
jdeolive: not sure i follow completely
tenzochris: like, where "remove selected" is now
tenzochris: ?
tenzochris: and that page would be all about mass-deletion
***tenzochris likes the scary music idea, fwiw :)
aaime: jdeolive, it's about having a like that brigs you to a page that
basically looks the same, but whose sole purprose in life is do scary
batch deletes
jdeolive: right, so i guess i am suggesting just put that on teh store
page that list the layers
aaime: so you'd still have table and filters, but no links, and just one
red button for mass deletion
jdeolive: i guess maybe that does not work
jdeolive: if your use case is batch deleting from multiple stores
jdeolive: nevermind..
aaime: jdeolive, that works for feature types, but for coverages, not
that well
aaime: since we can only have one coverage per store today
aaime: I'm not that enthusiastic about the separate page either, just
trying to explore alternative and loose up a little the tension :)
tenzochris ha abbandonato la stanza (quit: Read error: 54 (Connection
reset by peer)).
tenzochris [[email protected]] è
entrato nella stanza.
aaime: tenzochris, how would a "mass murder" page would look like in
your opinion?
tenzochris: oh hey I'm back
tenzochris: cool
tenzochris: was just getting ready to head to the local cafe
aaime: I guess the idea behind the direct delete link + separate page is
to make the common case immediate (kill a single layer) and make the
less common one (kill a group of layers) still possible?
tenzochris: aaime: I like the no-link idea, though we should still show
all the same info as the other page
tenzochris: aaime: yeah, I think that's the goal
tenzochris: and it's really only a single click away
tenzochris: we could even have the link to mass-delete propagate any
filtering the user has in place already
tenzochris: so they don't have to start over again
tenzochris: should probably also not be paginated, imo
aaime: I guess all in all I still prefer a direct "delete filtered" link
aaime: oh, what about the following
aaime: the user filters
aaime: follows a "batch delete link"
aaime: leads to a page that's not paged, and that has checkboxes in it
aaime: everything selected by default
tenzochris: aaime: yes. that's exactly what I was just trying to
describe above
aaime: and with the same filter as the layer spage
tenzochris: yes
aaime: so one can still manually refine the selection if he wants
tenzochris: exactly
aaime: and then press the big red scary button
aaime: jdeolive, what do you think?
tenzochris: it could be viewed by users as a confirmation screen
aaime: indeed
jdeolive: works for me, at first i was hesitant to have a separate page
for deletes, but it sounds like you two are coming to a consensus
jdeolive: and if tenzochris thinks the workflow is good that is good
enough for me
aaime: one downside, what if I have 100.000 layers (I like it big) and I
press that button by mistake?
aaime: sorry, not the button, the "batch delete" link
iwillig [[email protected]] è entrato nella stanza.
aaime: I guess we should put some limits to that? Maybe, never allow to
go to the mass delete page if the current filtered table contains more
than 1000 layers?
tenzochris: aaime: you get to wait and contemplate the action you're
about to make?
***bmmpxf just saw the "mass murder" line, and got very frightened...
tenzochris: less flippantly, rather than "not going" I'd prefer that we
give users a warning
aaime: Right, like in my notepad apps: "do you really want to load this
huge file?"
tenzochris: "hey, it's going to take a long time to load 100k layers -
are you sure you don't want to narrow that down first?"
tenzochris: exactly
aaime: smart
aaime: I like ti
aaime: what about the per store page listing the layers in the store?
aaime: same deal there?
tenzochris: aaime: yeah, I'd be in favor of consistency for all those
results tables pages
jdeolive: what about just paging in that case?
jdeolive: i would like to avoid pop-ups bring thrown in my face every
page I go to
jdeolive: bring = being
tenzochris: jdeolive: the problem with paging, in the context of a
mass-delete screen, is that it creates uncertainty about the scope of
the deletion
tenzochris: is it just going to be the ones on the current page?
aaime: the downside of paging is that the user might thing it's deleting
only what's inside the first page
jdeolive: right, i am fine with no paging in that case
tenzochris: how about if I selected on other pages
jdeolive: but the case of just showing layers on the store page
jdeolive: i think paging better applies there
jdeolive: sorry, maybe i got confused
jdeolive: i think i did
jdeolive: sorry aaime
aaime: ah yeah, I was thinking of making it look exaclty like the full
layers page, just pre-filtered
jdeolive: you meant deleting layers from the store page
aaime: to show only the layers inside a specific store
jdeolive: cool
aaime: and not have the ws/store columns
tenzochris: jdeolive: oh, I may have misunderstood what we were talking
about
tenzochris: I'm in favor of paging on all the vanilla results pages
aaime: Hmmm... this "confirm in separate page" thing is also going to
unclutter the paged tables pages too, nice
aaime: (I had to jump thrut some hoops to have paging and selection work
togheter)
tenzochris: ossum
tenzochris: anything else you wanted to talk through, aaime ?
aaime: Maybe just one thing, which is again maybe just a matter of
personal taste
aaime: go to the contact information page
aaime: I noticed that the form gets pretty long due to labels being put
on top of the field to be edited
aaime: I can see it fully on my desktop, but not on my laptop
aaime: I think I would like it better to have the labels be on the side
of the fields, as opposed as on top
aaime: jdoelive, tenzochris, how do you feel about that?
jdeolive: i woudl be fine with that, but again it would have to be
something applied globaly
aaime: yup
aaime: the same applies to some extent to the pages that edit the layers
aaime: it's somewhat hard to tell apart titles and labels
tenzochris: aaime: top-aligned labels (in general) are tied to faster
completion times, especially when the data being collected is familiar
tenzochris: it also gives us more room for verbose label text, which
IIRC was a concern a couple places in the 1.x UI
aaime: Ok, I'll adapt :)
tenzochris: okeydoke :)
funky_c ha abbandonato la stanza (quit: "Ex-Chat").
aaime: so I guess we're done
aaime: jdeolive, you wanted to do estimation? Or maybe I should open
tickets that came out of this discussion first?
aaime: and btw, do you mind if I post this irc discussion on the ml?
jdeolive: aaime: before that
aaime: (maybe skipping over the first 5 tense minutes?) ;)
jdeolive: i thikn we should sync up on how we want to organize jira
jdeolive: since we seem to have different ideas about that
aaime: sure
tenzochris: I'll let you guys hammer that out, and continue digging on
Ext style options (it looks so far like it's designed to be flexible)
jdeolive: cool, thanks tenzochris
----------------------------------------------------------------------
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
