Re: [Epiphany] Some more input about bookmarks



Marco Pesenti Gritti wrote:

>So Matthew Thomas sent me some thoughts about bookmarks.
>(The main problem is still multiple topics against single topic ...
>I wonder if it's not better to stay on the safe side and start doing the
>simpler thing. Maybe we will not miss multiple topics ... dunno.)
>
>-------------------------------------------------------------------------
>1.  I think the ability to add a bookmark to more than one `topic', when
>    you first create the bookmark, would be more confusing than useful.
>
I think it depends on the ui. I don't think of topics as folder, so i 
don't really think its all that confusing, but maybe real world testing 
is needed. Another option (perhaps even favorable) is to hide topics in 
the new bookmark dialog using a disclosure widget (remembering state).   
I mean how many people actually go to the trouble to categorize their 
bookmarks anyway (for the longest time while using galeon i just had a 
long list of them).

>
>2.  `Add a bookmark to the collection' probably should be `Add
>    Bookmark'.
>
>3.  `Add a New Topic' should be `New Topic...', since it requires
>    further input after you've clicked the button.
>
Once again depends on the ui, but i agree pretty much. I'm not convinced 
that the ability to add topics is necessary from the new bookmark dialog 
or from the properties window (more of an organizational thing that can 
be done later if needed).

>
>4.  Why `topic'? What percentage of people arrange all their bookmarks
>    by topic? Is it really desirable to try and increase this
>    percentage, by using the word `topic' rather than `folder'? Back
>    when I used bookmarks at all (before I started relying on Google
>    instead), I had Daily, Weekly, and Monthly folders for bookmarks I
>    visited that often. They weren't `topics'.
>
I disagree with MPT here. Ignoring his specific use case (which i think 
is pretty unusual), most users i know that use bookmark categorize them 
by topic. Furthermore I think the using the folder as metaphor (but 
changing its behavior) is potentially more confusing than introducing a 
new metaphor.

examples:

1. In a file manager deleting a folder deletes all files contained in 
the folder. In our database bookmark system, deleting a topic only 
removes the topic, not the bookmarks that include that topic.

2. In file managers, there is a one to one mapping of files to folders, 
this is not true in a database.

>
>5.  The bookmark list should have column headers for Name and Address.
>    Not only would this mean I could search by URL fragment, as well as
>    title, it would also make the two panes look less lopsided.
>
Don't really have a strong opinion here. Ideally it would be nice if one 
could navigate the web without using urls (something similar to google's 
do you feel lucky search). On the other hand, currently URLs are a 
necessary evil so maybe users will find them useful.

>
>6.  If the search field filters the bookmarks you see in the list, it
>    should be above the list rather than below it.
>
agree..

>
>7.  How does the search interact with the folder list? Does it make a
>    new temporary pseudo-folder called `Search Results'? (It may be
>    useful to provide the ability to save such a folder permanently.)
>
This would be possible in my design:

1. file -> new topic
2. Edit -> select all
3. Drag and drop the bookmarks to the new topic

>
>8.  Apart from the two-pane thing, the bookmarks editor should look and
>    work pretty much the same as a folder in the file manager. For
>    example, there should be a `File' menu containing New..., Open,
>    Rename..., Info etc items. And removing a bookmark should send it to
>    Nautilus's Trash.
>
Agree about the menus obviously. The nautilus trash thing is tricky. I 
mean you could always create a .desktop file in the ~/.trash folder 
representing the bookmark, which could be dragged back into the bme 
(also trash handling could be moved out of nautilus and into vfs). But 
again this kind of interaction is way tricky right now from both 
implementation and ui perspectives.

/me dreams of a database file system.

dave




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]