On Wed, 2005-11-02 at 23:05 -0500, Adam Hooper wrote: > On Thu, 2005-11-03 at 14:43 +1100, Peter Harvey wrote: > > "Show all topics" makes the list show all topics. Clicking on a topic > > appends it to the text-entry widget (topics in the widget are comma > > separated) and removes it from the list. This "click-to-add" concept > > will be used for the other 3 options as well. > > Nowhere else on the desktop does clicking on a list item make it > disappear. At the very least, these list items should have checkboxes > instead.
Point taken, but I'm willing to try anyway. :) The only thing really similar is a menu, or a dialog box, where clicking on something makes it disappear. > (Potential visual problem: I take it that the list of topics will be a > tree in the "top-level topics" case; maybe tree expanders will look ugly > next to checkboxes?) No, no tree expanders. Think of it more like "eliciting topics from the user". You *don't* show a topic to them if they would have to pick a bigger topic first. It's not a tree, so no tree expanders. Try this pic for an older demo of how the "top-level topics" works: http://www.dsl.uow.edu.au/~harvey/mockup3.png If your topics are arranged precisely as a tree, then it will feel like you are browsing deeper into the tree. If you're topics are not arranged precisely as a tree it will feel similar, but not as restrictive or as cumbersome to click through as an actual tree widget. I've developed this under the presumption that the user has potentially forgotten all the topics that they've used for similar bookmarks. I know I do it all the time. But I don't like to sit and ask myself "I had a bookmark like this before, what topics did I associate it with?". I'd prefer that the program intelligently elicits topics from me. > In general, I think the idea is nice but way too complicated. When will > a given bookmark use more than, say, 5 topics? I get the feeling the > displayed list of potential topics could be around 5-10 long, > automatically generated (with suggested and deli.cio.us topics). If the > user wants more topics, perhaps an "Other topic..." button? The problem isn't the number of topics associated with each bookmark. It's the number of topics presented to the user to pick from, and the ability for us to determine precisely what topics should be shown to them. I don't like relying on deli.cio.us for any standard components of the user interface because of lag. I agree that generally a maximum of 5 topics would be used by someone for a given bookmark. So listing the selected ones in a text widget is OK by me. The problem is always going to be "which topics to offer to the user". > Compare that with the current user interface, which lists all topics: > showing only 5-10 topics would be a huge improvement, and it would be > simpler. We're coming to a time in computing when we have to trust that > the computer knows what we want; auto-suggesting topics ought to be > flawless, no? The t1 patch only shows an average of 5-10 topics *at a time*. It means the user has a smaller set to pick from. That set changes once they click a topic, but it's always a small set. > (Of course, this begs the question: if we can develop a system which > automatically suggests topics which are very reasonable, we ought to be > able to simplify to the point that the user would never have to choose > topics at all....) We'll never know the context of the users daily life without getting at least a list of topics from them. Without that we can't generate an appropriate set of topics. We will always need user interaction. We're just trying to minimise/optimise. :) _______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
