212203 - analyze bookmark-related use cases and design a coherent UI before implementing

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Bookmarks & History, defect)

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612

PLEASE analyze bookmark-related use cases (usage modes) and come up with 
a coherent UI design and then implement it, instead of hacking things 
incrementally.

The current user interface is unusable for serious bookmark management.
(See bug reports about how the search function that lists matching 
bookmarks is useless for managing bookmarks.)

The reason is that functionality that is useful for going to bookmarked 
pages is mixed up with bookmark-management functionality (in the current 
design and in bug-report discussions).

Within the sub-area of searching for bookmarks, there are two main cases:
1.  To manage bookmarks.
2.  To go to bookmarked pages.

To manage bookmarks (to move them around in the hierarchy; to go to pages 
to check what they are before moving, deleting, or editing them), users 
use the Bookmark Manager window.

To find a bookmark in the hierachy (without searching for it manually), 
users need a function that shows the matching bookmark in context in 
the bookmark hierarchy.

However, to choose a bookmark and go to a bookmarked pages, users might
want to see all matching bookmarks at once (e.g., in a list), and then
select one whose page to retrieve.

Designers need to realize that there are two usage modes, and two search 
functions are needed.

That is, regarding bug 95748, bug 118393, etc., the problem is not that 
the find command lists matches instead of showing them in context; the 
problem is that there is no second command to find matching bookmarks 
in context.

The lack of at least the level of bookmark-management capability that 
Netscape 4.x has/had is a showstopper for a number of us who want to 
upgrade to Mozilla but can't because maintaining our large bookmarks
files is impossible in Mozilla.

Please be careful when trying to improve things.  Don't take away old
features when adding new features.  Be careful when changing features.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 3

[Daniel B.]

> This bug has had no comments for a long time. Statistically, we
> have found that bug reports that have not been confirmed by a 
> second user after three months are highly unlikely to be the 
> source of a fix to the code.

Well, duh!  Bug reports aren't the source of fixes--developers
are!

Isn't there a process to confirm reported bugs?  Why wait for
a second user to happen to pick the same thing to report?  And 
why depend on that second user's finding the same bug report 
and not reporting it in a new bug report?


> This bug has been automatically resolved ...

Wrong.  It was _marked_ resolved--it was not resolved.  The 
problem still exists.  Look at the other bookmarks-related
bug reports.


> If anyone thinks this is incorrect, they should feel free to 
> reopen it.

Unless a bug is fixed, the project specifically decides not to
fix it (or disagrees that it's a bug), or the bug is not 
reproducible (either because the report was bad or something
changed), bug reports shouldn't be closed.  Closing them
like this destroys the reliability of the bug-reporting
system.  

(One can't report a bug and know that the report will be 
remembered and kept visible (open) until the bug is fixed.  
One has to keep monitoring the bug report indefinitely
(for cancellations like this) to avoid having one's effort
at reporting the bug be wasted by the cancellation.

Comment 4

[Ray Booysen]

Reassigning as per Bug #32644

Comment 5

[Misak Khachatryan]

Do we need this bug ? Places system and awesome bar seems reasonable advantage over old bookmark UI, and we hope it will be in Seamonkey 2, but we have bug filed for it. This is safe to close IMHO

Comment 6

[Justin Wood (:Callek)]

Daniel B.

I am resolving this bug as incomplete.

In SeaMonkey 2 we will likely be keeping the same UI as SeaMonkey 1.1.x though if you have any specific mockups or specific change suggestions UI wise we can analyze those on a case-by-case-basis. Or if you do have a wide-sweeping-proposal, you can fill it out on wiki.mozilla.org and link it here and in the newsgroup for feedback.

Other than that I don't see anything here that would facilitate us in resolving this to your liking.