182004 - Bookmarks & History Palette

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, enhancement)

Description

[Stephane Moureau]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021125 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021125 Chimera/0.6+

Having the B&H in a Drawer is perfect for browsing:
- with big windows, like users who are using Tabbed Browsing
- with few documents opened at the same time in individual windows
- with very few and clean named bookmarks
- with a very small hierarchy of bookmarks (sub-folders ^n)
- with fast computers able to quickly resize a window to show "its" Drawer
- with fast computers able to quickly refresh all the windows behind
- with a computer with a (very) wide screen

All users are not browsing with big windows or under Tabs.
Sometimes several windows must be visible at the same time (Stockmarkets, java
chats, etc)

A work-around, for those who know HTML, would be to use frames.
But a lot of sites refuse to see their pages, or parts of it, inside frames.

The Drawer disadvantages are:

- unusable with small windows or several windows opened (crowded)
- slow on windows crowded screen due to the resize/redraw
- multiple openings required each time you switch to another window
- web pages are bigger 800x600 or 1024x768 making the drawer 'inaccessible'
- waste screen space as several drawers might need to be opened
- reopened in a new window if previous window was showing it
- probably using more memory (RAM) as one Drawer is attached to each window

Moving the B&H inside a Palette (AAHIG: application-wide toolbar) has all the
advantages of the Drawer plus :

- accessible from any window
- usable no matter the size of the current window
- user can size it and position it without being linked to a window
- can be 'reduced/expanded' to its title by a click on its green button (zoom)
- spare memory as only one is opened
- can be placed on a second screen independently
- B&H can be maintained without requiring an empty document that has to be
opened, resized, then enlarge the drawer, maintain your bookmarks. Then reduce
the drawer, resize the window and close it in order for the next new window to
appear 'correctly'.

Using a Palette will solve/help the following bugs and it will avoid some of the
choices made which are against AAHIG - Drawers :

- Bug 160411 Maximize window puts Sidebar out of screen
  It's not a bug, see AAHIG "...If the user makes a window so big
  that there's no room on either side, the drawer opens off the screen."

- Bug 154862 Drawer state (opened) does not persist btwn sessions

- Bug 180002 Bookmark drawer width not applied to new windows.
  This will lead to confusion, the width is kept but not the visible state;
  see Bug 154862

- Bug 164180 unable to tab between toolbar and bookmarks in the sidebar

- Bug 164193 no keyboard access between browser window (content) and sidebar

- Bug 180731 remember if sidebar is open/closed for next new window
- Bug 167777 ? Save sidebar position (expanded/contracted)


I suppose someone will quickly paste that extract of the AAHIG about Drawers:
"Some examples of uses of drawers include access to favorites lists, the Mailbox
drawer (in the Mail application), or BROWSER BOOKMARKS."

This is just an example and nothing is said against using a Palette instead.

Everyone knows the problems with bookmarks, they accumulate very quickly, their
name are huge, etc...
And even if you clean them, sort them in folders under a nice hierarchy, the
Drawer's width will annihilate that cleaning.

Using the Bookmarks menu when you have a lot of bookmarks is very slow and not
very handy to use when you have a big hierarchy (lots of sub-folders, sub-menu
are closing and jumping on left and right).

I think we should see the B&H Palette as a B&H Manager window, which of course
can also be used to select a bookmark.

By using the Green button (zoom) a Palette can be "reduced" to its title bar and
expanded very quickly. By dragging it just below the menu bar, it will not take
any space on the screen once "reduced", it will just be over a window title bar.

I hope I have been able to convince you... sorry for the length.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Greg K.]

I doubt Chimera would get this. As I've suggested elsewhere, the sort of
fundamental UI changes you've been proposing, while perfectly valid, are
probably best done as a Mozilla skin or an entirely separate third-party browser
project based either on the Mozilla or Chimera code.

Comment 2

[Sören 'Chucker' Kuklau (gone)]

Not going to happen.

Comment 3

[Stephane Moureau]

Sorry to reopen, no offense to Soren.
I would like to have Mike Pinkerton or Simon Fraser among others on this one, if
they don't mind. Is it a definitive no or just no until v1.0 ?

>Anyway, I'm not a Chimera developer. I'm just a triager: I go
>through bugs, check them, confirm or resolve them eventually,
>etc. My opinion on what should be implemented and what not may
>differ from that of Mike or Simon.
>Sören 'Chucker' Kuklau
>Chimera Wannabe Bug Triager

Comment 4

[Stephane Moureau]

Attachment: Sample preview

Capture mock-up.

Comment 5

[Sören 'Chucker' Kuklau (gone)]

Alright, just let me get this off the infamous huge UNCONFIRMED list.

Mike Pinkerton: Please comment if you actually want this (I don't, but this is a
matter of preference).

Comment 6

[Mike Pinkerton (not reading bugmail)]

an interesting idea, worth keeping around, but probably not going to happen any
time soon.

Comment 7

[Mike Pinkerton (not reading bugmail)]

we already have other bugs on this. i agree the drawer was inappropriate
entirely for bookmark management. we have other bugs to cover this discussion,
marking wontfix just to get it off the radar (not to reject the idea).