622452 - New groups need non null default name

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect)

Description

[Ravi Pina [:ravi]]

New tab groups default to a null name which do not appear in the Move to Group tab menu.  Non null values correctly appear in the list.  This behavior creates an unnecessary step of having to enter Tab Groups to name the group to allow adding subsequent tabs to that group from the tab menu.

Comment 1

[Michael Yoshitaka Erlewine [:mitcho]]

If we want the group's default name to be anything other than, say, that first tab's name (imho not the best idea), we'll need strings for this.

Comment 2

[Axel Hecht [:Pike]]

I don't see it necessary to give new groups a non-null default name. I think it'd actually be confusing, if there are more than one.

No idea why the Move-To-Group menu can't display unnamed groups, with a hint on what the groups are about derived from the content. Or do we have a last-modified date?

Comment 3

[Michael Yoshitaka Erlewine [:mitcho]]

I personally don't think we should have default names for the groups, i.e., the groups should start untitled. However, in order to add some item for those untitled groups to show up in the "move to group" menu, we will need some string, like "Untitled group 1", or "Untitled group with Gmail" or something. That's where we might need more strings.

Assigning to Faaborg for design.

Comment 4

[Ravi Pina [:ravi]]

"Untitled group 1" would be a default name if you asked me :)

Alternately, and I'm not sure how I feel about this, but a a text input box could open to input the new group name.  In fact the behavior could be similar to how bookmarks are now -- clicking the star in the location bar creates a bookmark without any input, but creating one with the keyboard shortcut brings the window of attributes for the bookmark.

Comment 5

[Kevin Hanes]

The behavior of a null named group is fairly intentional. In discussions about the "move to group" feature, we elected to have it only show named groups, both for the reasons mitcho names in comment 3, and because we want the user to "elevate" important groups by naming them.

I don't think adding a string, or changing the behavior is something we want.

Comment 6

[Ravi Pina [:ravi]]

Perhaps I am an edge case, but from a UX point of view the method I intended to add tabs to a group lead to confusion and a perceived broken state.  I am curious why all the groups wouldn't want to be "elevated".  Further the group name editor is not immediately obvious.  It is a pencil icon at the top-left that only changes to Name this tab group... on mouse over.  If group names are an important attribute (which I think they are) then more attention needs to be brought at the initial group creation.

Comment 7

[Raymond Lee [:raymondlee]]

This is related to bug 576409

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Possible future plan for dealing with Session Restore

I don't think we should include unnamed groups in the move to menu.  That's the short version :) The reason has to do with how we plan to eventually deal with groups and session restore.

-In future releases when we express multiple windows as tab groups (so a window is just a view onto a particular tab group), users may start to create a large number of groups without even knowing about panorama.  Some users still avoid tabs, so 10 windows with 1 tab each would become 10 groups.  We don't want to automatically restore the entire session on launch for these users, because they may amass thousands of tabs/windows/groups over the life cycle of the product.

-To keep these users from turning the tabstrip and panorama into a full history UI (with every tab they've ever seen), we can automatically close all of their tabs on exit, and allow them to restore their previous session when they re-open the browser.

-However, if users have specifically created groups that they want to have save, it is tedious for them to have to regularly click a button on launch to restore their data (imagine having to hit button on launch to restore your bookmarks).  They can opt to always restore their session (many people at mozilla have this pref already flipped), but then it is tedious in that they have to close a lot of unneeded tabs individually from time to time.  They can't use the single action of a browser close to clean up their work space.

-One solution to this problem is to eventually create two levels of groups, basically bookmarks versus session.  The distinction we've made previously in the Firefox UI is:

Bookmarks: explicit user action.  The user creates data, like clicking a star icon to say "never forget this"

Session/history: implicit user action. Firefox creates data, like opening a new tab from a link the user clicked.

In this modal named groups (bookmarked groups) will always persist, and Firefox will never forget them.  Unnamed groups will be tied to session restore.

If we list unnamed groups in the "Move to Group" sub-menu, once the user interacts with that, they've done an explicit action equivalent to clicking a star icon (they've created user data). So we would need to take that out of session restore.  We could do that, but users probably wouldn't be able to figure out why some groups persist, and others do not.  If we only list named groups in the move to list, then users will become more familiar with the process of creating a named group.  As part of this process we indicate to them that the group will become persistent, through use of a star icon, more opaque back, etc.  Note that if in this model the user clicks the star, and doesn't type a name in, then we would need to provide a string like "Unnamed group 1" (but it is still a starred/persistent/named group).

So, that's a rather long way of saying I don't think we should have any change for this release.  If we move forward with this plan named groups will pick up a star icon and move outside of session restore in the future, and the "Move to Group" menu will continue to have the same functionality.

Comment 9

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #8)
> Created attachment 501791 [details]
> Possible future plan for dealing with Session Restore

Looks good and makes sense for me. Alex, have you posted this plan elsewhere / do we have a bug for it? If not, we should make a target=future bug for it.

Comment 10

[Michael Yoshitaka Erlewine [:mitcho]]

In the meantime, this bug is then a wontfix, I believe.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

I copied the mockup and comments over to bug 604963