Christopher Patterson ha scritto: > > On Feb 23, 2009, at 5:10 PM, Andrea Aime wrote:
Sorry for my late answer, did not see your mail while I was in NY (mail client without folder filtering rules, resulting in ~200 mails dropping in the same folder a day). >> Christopher Patterson wrote: >>> I think this looks like a huge improvement over the tree structure. >>> The only question I had from the mockup was about the links on each >>> row of the result table: >>> http://skitch.com/dimmerswitch/bfa45/layerlist >>> It's not immediately clear (from looking) where those links would >>> take me. Would adding "[Edit]" buttons or text potentially clarify >>> where each of those might point? >> >> Each links brings you to an edit page for the workspace, store and layer >> respectively. Imho adding a edit icon would just clutter the UI, and it >> does not seem hard to figure out when you're looking at a working >> UI: you follow the link the first time, you see where it brings you, >> and then you should just know about it... or not? >> > Geoserver may be exceptional in that you'll tend to have fewer / deeper > users, so they'll learn the conventions. Although I'm not a fan of > interfaces where you have to click a link to discover where it goes, I'm > aware that I'm not necessarily a representative Geoserver user. Mumble.... the alternative would be to add a edit icon on the side of each link, and repeat it along the table? That would end up adding 10 * 5 = 50 equal icons into the table (assuming 10 rows per page, and 5 columns with a link, did not really count them), that's why I used the world "clutter" ;) Maybe we could add a tooltip on links with an explanation instead? >> >> Especially if all of the links in the tables bring you to edit pages, >> that is, if we're consistent throught the UI. Like, for example, >> adopting the same approach in the style list page. > Sure. I'd be +1 on this approach as long as we do it consistently: > whenever we're displaying a table of results, links should take you to > the relevant edit page. This also means that delete functionality would > be removed from the individual rows, in favor of the click-to-select, > then delete approach in Andrea's mockup. I'm not against that change, > but wanted to mention it up front. Yup, the idea would be that each table shows one type of object (layers, in the mockup page you've seen) and the selection allows one to delete only that kind of object. So in the layers page one would have the selection, and that would affect only deleting the layers, the links to stores and workspaces are provided only as a convenience for inspection/quick editing, but if one want to delete stores, he would have to go into the page that do list stores instead. My guess is that the most common operation against stores and workspaces is actually deleting just one (as opposed to a group of them), so we should probably add a "delete this" operation into the edit pages as well, just as it happens in a some wiki systems (confluence comes to mind). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
