Re: Patch for topic selector, and dnd for bookmarks menu

[Peter Harvey <pah06 uow edu au>]

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. :)