60206 - "Side[bar] Pockets" - To Group Sidebar Entries

Status: NEW

(SeaMonkey :: Sidebar, enhancement)

Description

[Morbus Iff]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
BuildID:    2000111404

Side Pockets would allow hierarchal treating of side bar entries, and would 
solve the problem of having so many sidebar items that they are shown off 
screen, or else where you only have a sliver of viewable space due to crunching.

For example, when clicking on "Tabs", you now see:

  Customize..
  Entry 1 
  Entry 2

With side pockets, you'd see:

  Customize
  Side Pocket #1
    Entry 1
    Entry 2
  Side Pocket #2
    Entry 3
    Entry 4

Allowing people to group sidebar entries will allow more sidebar entries to be 
chosen without crunching, better organizational skills ("tech entries", "things 
that go moo", "games"), and help the sidebar become more flexible for people 
who want tons of entries (not me, whistle, whistle).

To add a feature request onto a feature request, the hierarchal "Tabs" window 
described above would function like so:

  Clicking on a Side Pocket would create a sidebar much like 
  one we have in M18.

  Clicking on an Entry from the "Tab" menu, however, would 
  show the Entry in the full side bar.

This would allow the current functioning to continue, as well as allow quick 
and full reading of an entire sidebar entry without scrolling.

Comment 1

[Keyser Sose]

Changed to RFE - Request for Enhancement, seems like a cool idea to me. Marking NEW.

Comment 2

[Caspy7]

I came up with an idea that looks like it might be almost identical to this, so 
I'll just add my two cents here.
Basically make it like it says above, where instead of what you see now under 
tabs those will all be directories, and under the directories will be the 
sidebar panels.  Also make the behavior of selecting the directories more like 
that of a radio button.  IE, put either a radio button or check mark that 
behaves like a radio button in front of each directory, so that only one 
directory can be selected at a time, and that will be your currently viewed 
sidebar.
Additional behaviour that might be practical with the implementation of these 
ideas would be to allow the effects of a click to take effect without making the 
tabs menu disappear, thereby allowing a user to browse through their categories 
or multiple sidebars without having to keep clicking the tabs button constantly 
and finding the right directory all over again.

Comment 3

[shrirang khanzode]

spam : changing qa to sujay (New Sidebar QA)

Comment 4

[Caspy7]

Attachment: This is a doctored screenshot I hacked together illustrating my proposal for the "Sidebar Pockets" feature.

Comment 5

[Caspy7]

You'll note in my last attached screenshot that "Sidebar" at the top of the 
sidebard is changed to "Sidebar - General" corresponding to the current pocket.

I would also suggest a change of behavior so that the the menu doesn't disappear 
when you check or uncheck a tab so it wouldn't be so much work to alter multiple 
tabs.  Would it be possible to update the sidebar without clearing the menu?  
It would be nice if the same were true when switching pockets.  This way one 
could easily scroll through the different pockets.

The main question of behavior here would be the combo menu/radio buttons.  Often 
a user will click on a menu with a submenu to quickly bring up the submenu.  So 
perhaps keep that behavior except when clicking directly over the radio button 
(which will make the corresponding pocket the active one).

Comment 6

[Caspy7]

Attachment: Mock Screenshot illustrating suggested behavior 1

Comment 7

[Caspy7]

Attachment: Mock Screenshot illustrating suggested behavior 2

Comment 8

[Caspy7]

I hacked together a few more mock screenshots illustrating how the UI for the 
sidebar menu can reflect the difference between clicking to list the pocket 
contents and clicking to make the selected pocket the current sidebar.

Comment 9

[Gervase Markham [:gerv]]

I'm not convinced that this is the best UI in the case that someone has a large
number of sidebar tabs. I'm tempted to say that they should just turn some of
them off. :-)

Gerv

Comment 10

[Blake Ross]

reassigning matt's old bugs.

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 18

[Karsten Düsterloh]

Marking as valid RFE for now, though with rather low likelihood.