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

NEW
Unassigned

Status

SeaMonkey
Sidebar
--
enhancement
17 years ago
6 years ago

People

(Reporter: Morbus Iff, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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.

Updated

17 years ago
URL: n/a

Comment 1

17 years ago
Changed to RFE - Request for Enhancement, seems like a cool idea to me. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: "Side[bar] Pockets" - To Group Sidebar Entries → [RFE] "Side[bar] Pockets" - To Group Sidebar Entries

Comment 2

17 years ago
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

17 years ago
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay

Comment 4

16 years ago
Created attachment 47917 [details]
This is a doctored screenshot I hacked together illustrating my proposal for the "Sidebar Pockets" feature.

Comment 5

16 years ago
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).

Updated

16 years ago
Target Milestone: --- → Future

Comment 6

16 years ago
Created attachment 51185 [details]
Mock Screenshot illustrating suggested behavior 1

Comment 7

16 years ago
Created attachment 51186 [details]
Mock Screenshot illustrating suggested behavior 2

Comment 8

16 years ago
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.
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

16 years ago
reassigning matt's old bugs.
Assignee: matt → sgehani

Updated

15 years ago
Summary: [RFE] "Side[bar] Pockets" - To Group Sidebar Entries → "Side[bar] Pockets" - To Group Sidebar Entries
Product: Browser → Seamonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: sujay → sidebar
Target Milestone: Future → ---

Comment 11

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 12

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

8 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED

Updated

6 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Marking as valid RFE for now, though with rather low likelihood.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.