RE: [Epiphany] More Topic/Keyword/Folder madness! Oh, no!

[mpeseng tin it]

>The first advantage, that of avoiding hierarchy through a flat list
>model, and thus gaining simplicity, is certainly admirable.  I'd
>definitely agree that an imposed hierarchical model can be a strong
>burden on end users, however, I fail to see why avoiding it is an
>inherent property of the keyword model.  The folder model is
>hierarchy-*optional*. No one is forced into creating a hierarchy - the
>user would have to do this themselves!

- A simpler model allows you to write a simpler ui around it. For example
while I would never think to use a mozilla like dialog (with a tree) to
browse my bookmarks, I can easily use a two-pane ui to do it.
Certainly you could make possible to add subfolders in the left pane, but
this would add complexity too.
- Nested folders are evil. They are difficult to use (both edit and browse).
We should not encourage the user to use them.
I heard your argument more than one time ... but when I get a mail by mpt
saying we should do something like that (he was not knowing we was already
doing it), well, I start to think I'm not that on crack ;)

> Thus, I believe the first
>advantage of keywords to be false - it is not an advantage of the model,
>it's an advantage of implementation.

Hmm nope, at least in our code it's not an advantage. It helps to keep the
ui simpler and that'also an implementation advantage but ...

>The second keyword advantage of providing incentive to organize through
>a simpler filing model, is flawed as well.  I don't think we're any more
>likely to persuade users to file their bookmarks with keywords any more
>than we are with folders.  Again, I believe this to be an implementation
>issue, not an inherent property to the model.

The whole point was to be able to associate more topics with the same bookmark.
I dont think terminology makes a big difference (folders vs keywords).

>Thirdly, there's nothing about keywords that makes them inherently more
>searchable than folders.  In fact, I think it might be interesting to
>pursue a hybrid model, whereby a user can put a bookmark anywhere in a
>folder hierarchy, and at the same time, assign keywords to a particular
>bookmark.  Of course, this may be too complex, and prove to be the
>Achilles Heel of my whole argument, but we'll see, eh? :-)

I think I explained in my first mail why having two topics on the same bookmarks
make them more searchable for me.

>The final advantage to keywords is the ability to have several keywords
>assigned to one bookmark, which enhances the browsing of bookmarks.
>This is nice, but I have a feeling that there is going to be a very
>small intersection between the groups of users that assign more than one
>(if any!) keyword to a particular bookmark, and the group of users that
>don't understand hierarchies.

MODEL 1
We ask to the user: what topics is this page related to ?
On the base of this we build a simple view.

MODEL 2
In a tree model you either
- ask to the user to organize his bookmarks in an abstract structure (a
tree). Normal people will just not grok that ...
(Now I'm very familiar with the file system hierarchy but I have not forgot
my father explaining me the concept of folder inside a folder, and how much
it was hard to understand. I could be wrong here but at the time I think
I already hacked a pair of asm programs, so I was not completely silly).

Even if we decide that multiple topics are too complex, I think we need
to choose model 1.

The interface to do it is also hard to use. As user, I dont even consider
to try to reorder a tree.

- leave him without a way to organize bookmarks

This was just to explain why I believe there is an intersection.

>Also, if one does assign multiple
>keywords to several bookmarks, one's keyword list can grow enormous very
>quickly, thus effectively slowing down the browsing of bookmarks quite
a
>bit.  (See my screenshot here of how long a keywords list can get in
>only a few weeks - http://upevil.net/ephy-keyword-list.png - note the
>length of the scrollbar.)

How a folders model would have improved that mess ?
Using subfolders ?

>1) Lack of familiarity.  Every single browser I've ever seen or used
>uses folders.  Most notably, evry version of Netscape, Safari, Opera,
>Galeon, Konqueror, and the big behemoth, Internet
>Exploder^H^H^H^H^H^H^H^H... er... Explorer, which commands a HUGE
>percentage of the current userbase of the web.  While we certainly
>shouldn't just ape the features and model of any one browser, IE in
>particular, it is important, to quote Havoc, that we "spend our
>different points wisely."  If we're really going to break from the
>folders model, we'd better be damn sure it's worth the lack of
>familiarity for anyone coming from another system, which *will* have
>used a folder system.

I probably agree here. There are some things I believe should be improved
to make it more familiar (see how to choose the topics, we may even go back
to a single topic mode ...).
But if with "familiar" you mean nested subfolders well ... I dont think
more than 1% of people actually used them, so it's not a big deal.

>2) Loss of the ability to choose a hierarchy.  The folders model can act
>much like the keywords model, if we implement correctly, but the keyword
>model is inherently lacking the ability to do "sub-keywords" - instead
>of having optional hierarchy, we have no choice but to use a flat
>structure, which can be really cumbersome as one's bookmark list grows,
>especially if one uses more than one keyword per bookmark!  Again, see
>the screenshot referenced before.

That's a positive side effect actually ;)

>There are some other issues I worry about with keywords, like fast
>access - using the current bookmarks window takes FOREVER compared to
>using something like a folder system in a bookmarks menu.  I realize
>that my real complaint here is "i want to be able to access bookmarks
>quickly", but I can't think of any implementation of keywords that could
>possibly work as well to access bookmarks quickly, using only the mouse.

Toolbars should be the way to access bookmarks quickly IHMO. And the autocompletion.
It's up to the user to decide which bookmarks needs to be fastly accessible.
For example I'd care only to have my News bookmarks fastly accessible, no
need to slow that down by going through submenus.
The dialog should be the way to browse them, when you dont know where exactly
what you are searching is but you need to have a powerful way to find them.
Obviously there are a few people that know exactly where to find one of
their 200 bookmarks and want to do that very fast and feel phisically
easy to go trough submenus. These people are not users I target but ...
no one stop us to let them put their whole bookmarks collection on the toolbar,
in one of these nice 10 levels submenus ;)

Marco

O.T.
The girl near me in the lab was in pain with one of these silly confirmation
dialogs.
What should I do now ?! Press OK ...
(What could I have said ? You know cookies are .... ;)
Thanks to Dave and Havoc to have convinced me to kill them :)