Re: [Epiphany] Bookmarks (was Armchair Dev...)

[Peter Harvey <pah06 uow edu au>]

> On Tue, Oct 28, 2003 at 11:17:46PM +1100, Peter Harvey wrote:
> 
>  > In a similar vein, I'd like to bookmark my reference documentation by
>  > sub-categories (Programming, Constraints, Web, etc). So we have two
>  > examples here where shallow hierarchies are useful.
> 
>  I see what you mean.
> 
>  I still think the correct solution is to separate the bookmark thing
>  from Epiphany, reimplement the current thing as a separate application
>  and ship it with Epiphany.  And just for the fun's sake, make it damm
>  hard to change the default... :-)

Agreed. Have snipped your detailed explanation - it makes sense, but
I've never written Gnome/Epiphany code so I can't say too much on it.

>  > I will say that I loved the idea put forward by Eric Newman for
>  > auto-detecting the hierarchy
>  > (http://mozdev.org/pipermail/epiphany/2003-August/000093.html) though
>  > I am concerned that it wouldn't work well in practise.
> 
>  Any particular objection to that idea or is it just a hunch?  My
>  problem with that is that it doesn't solve the "the menu is too large"
>  problem.  It does solve the "I can't find anything in the submenu
>  because it contains too much stuff" problem, for some users at least.
> 
>  Having the following bookmarks with topics:
> 
>         B0: T0
>         B1: T0
>         B2: T1

<snip> 

>  or (my preference):
> 
>         T0: B0, B1
>             T1: B2
> 
>  What do you do with:
> 
>         B0: T0
>         B1: T0
>         B2: T0, T1
>         B3: T1
> 
>  In this case I'd prefer:
> 
>         T0: B0, B1, B2
>         T1: B2, B3
> 
>  yes, that's the current solution.  And yes, I can see this can lead to
>  some pretty frustating situations.

You hit my problems with it exactly. It is non-deterministic in how to
construct the menu. Only thing I can think of is having two different
types of topics:
 Primary   - which creates a menu as the current topics do.
 Secondary - which creates a dividing line as Eric suggested, or if 
             there are too many items creates a sub-menu.
Essentially the user needs to provide hints as to how each topic should
be treated. This would be ugly though. Maybe someone who has studied
usability in depth can define the optimum mapping from "topics" and
"sub-topics" to a menu structure.

I still feel that a hierarchy of topics is the best way to go. For me,
specific sub-topics don't always apply (I don't categorise people's
websites the same way I categorise my reference docs).

The real reason I liked Eric's proposal was:
 a) It makes the hierarchy auto-magically (this would be so nice)
 b) It avoided sub-menus while still categorising bookmarks better

Unfortunately, without someone from usability to define the optimum
mapping, I don't think it would work in practise. I've only recently
studied information theory, and while using that as a basis for deciding
how the menu is constructed might help, I still fear that any algorithm
would need hints as to what the user wants.

-- 
Peter Harvey.
Mostly Quiet.