Closed Bug 1240022 Opened 8 years ago Closed 2 years ago

[UX] UI for the new profile picker

Categories

(Toolkit :: Startup and Profile System, defect, P5)

Product:
Toolkit
Component:
Startup and Profile System
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: phlsa, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 1 obsolete file)

profile-manager-toolbar-icon
3.23 KB, image/svg+xml
Details
patch 1 - Adding an icon in the hamburger menu and opening a window
19.95 KB, patch
Details | Diff | Splinter Review
MenuPanels-Assets.zip
468.84 KB, application/zip
Details
Toolbars-Assets.zip
522.62 KB, application/zip
Details 
Bug 1232629 introduced a new profile switcher that needs a bunch of UI improvements before it can ship.

Constraints for this ticket are that the picker still shows up when starting Firefox with the -p flag (or when »Always use this profile« has been checked off). Therefore, the profile switcher will still be a feature for a very technically skilled audience and not for the broad user base.

A design for more generic use cases can be devised in a separate ticket.
I’ve wireframed two different profile manager concepts here. One presents it as a vertical list. The other presents it like a New Tab Page or an OS login screen:

https://invis.io/8J5NTOFFG

A couple of questions:

1. How important is it for our users that we show the full path to Root and Local Directory, versus just having a button that says “Go to folder”?

2. What does the “Work Offline” checkbox mean, and is it usually utilised by most users? I notice that it’s a setting that you can toggle easily from the File menu. Can we take it out of the Profile Manager and rely on our users accessing the menu to toggle it if they need it?

Further comments are welcome either here or at InVision!
Flags: needinfo?(amarchesini)
> https://invis.io/8J5NTOFFG

cool! Personally I prefer the grid one.
A question: I see that there is a 'X' near the information box. What happens if the user clicks that 'X'? I guess we close the info box and that's ok but we don't have any place where we can store that information for the next time. Without a profile, we don't have preferences.

> 1. How important is it for our users that we show the full path to Root and
> Local Directory, versus just having a button that says “Go to folder”?

That could work. In the current version we have the full path root only and as tooltip.

> 2. What does the “Work Offline” checkbox mean, and is it usually utilised by
> most users? I notice that it’s a setting that you can toggle easily from the
> File menu. Can we take it out of the Profile Manager and rely on our users
> accessing the menu to toggle it if they need it?

I don't know if this is actually used but I think the use case is:
you have a profile with a set of tabs opened by default and you don't want them to be loaded.
Can we have some advanced menu for this and for the 'Use the selected profile without asking at startup'?
Btw this "use the selected profile' means: set the profile I choose as default one.
Flags: needinfo?(amarchesini)
Thanks for the feedback! I’ll get right to the responses.

> What happens if the user clicks that 'X'? I guess we close the info box
> and that's ok but we don't have any place where we can store that
> information for the next time.

You’re right. Having no pref means that we cannot modify the interface and have that modification persist.

One alternative to try is to only show this info only on the “Create New Profile” interface. So when you click “Create”, that page will tell you that “Each profile contains separate history, bookmarks, etc.” But on profile selection, that info isn’t there.

What do you think?


> I think the use case [for Work Offline] is:
> you have a profile with a set of tabs opened by default and you don't want
> them to be loaded.

Your proposed solution sounds sensible. “Work Offline” should be an advanced option that’s not always visible in the default interface.


> Can we have some advanced menu for […] 'Use the selected profile without
> asking at startup'?

I have a clarifying question about this, actually.

Is “Use the selected profile without asking as startup” different from “Set as default profile”?

My assumption:
* “Set as default profile” == “Set this profile as default, but don’t launch Firefox”.
* “Use the selected profile without asking at startup” == “Set this profile as default, then launch Firefox”

To reduce confusion and clarify intent, I separated the two actions of setting default and launching. You set default using one button, and you launch Firefox using another button. There is no longer a button to simultaneously set default and launch.

What do you think about taking out the “Use the selected profile without asking” checkbox, because that functionality is already covered by “Set as default”?
Flags: needinfo?(amarchesini)
> One alternative to try is to only show this info only on the “Create New
> Profile” interface. So when you click “Create”, that page will tell you that
> “Each profile contains separate history, bookmarks, etc.” But on profile
> selection, that info isn’t there.
> 
> What do you think?

Yes. I like it. In my previous ProfileManager UI I didn't touch the creation form, but that would be nice to be changed as well. Maybe in a follow up? Or if you prefer to do it all in once, let's do so.

> My assumption:
> * “Set as default profile” == “Set this profile as default, but don’t launch
> Firefox”.
> * “Use the selected profile without asking at startup” == “Set this profile
> as default, then launch Firefox”

Correct. 2 steps in once.

> What do you think about taking out the “Use the selected profile without
> asking” checkbox, because that functionality is already covered by “Set as
> default”?

Yes. it's ok. Maybe we can hide this feature in some advanced menu if someone really needs it.
Flags: needinfo?(amarchesini)
Hi Andrea,

I’ve updated the mockup per your feedback. Here are the changes:

1. I’ve decided to go with the vertical menu layout. It has one big benefit: we don’t need to design our own popup menu or details view, since everything is effectively the same layout. One small benefit: on the grid layout, if your profile name is too long, it won’t fit very well. That layout can work much better if each profile has a picture associated with it.

2. I’ve moved the Create New Profile interface away from a modal dialogue to in-content, and simplified it down to one step. Now it works more like the rest of Firefox. Test it by clicking “Create a New Profile”. Note the explanation copy that I wrote. It’s a bit longer than one paragraph, but not as long as the copy we currently have. It’ll need a formal rewrite and review from Matej, but the rough idea is what I’ve put down.

3. I’ve added a few advanced startup menu item on the details view. The first one is “Start and Work Offline”, and the second one is “Start and Set as Default”. Firstly, the wording is clearer and more consistent (compare “Use profile without asking as startup” to “Start and Set as Default”). Secondly, we have done our job in hiding the advanced option behind the details view, leaving the main interface straightforward and clean.

What do you think?
Flags: needinfo?(amarchesini)
> 1. I’ve decided to go with the vertical menu layout. It has one big benefit:

Sounds good to me. I would like to see how this vertical layout works in these 3 configurations:

1. no profiles at all (the user deletes all of them) - should we show a message?
2. only 1 profile - a lot of empty space, I guess...
3. >10 profiles - how do we scroll?

> 2. I’ve moved the Create New Profile interface away from a modal dialogue to

I like it.

> 3. I’ve added a few advanced startup menu item on the details view. The
> first one is “Start and Work Offline”, and the second one is “Start and Set
> as Default”. Firstly, the wording is clearer and more consistent (compare
> “Use profile without asking as startup” to “Start and Set as Default”).

How to set the default profile? Scenario: I want to set profile A as default, but then I want to start profile B.

Excellent job so far! Thanks!
Flags: needinfo?(amarchesini)
Hi Andrea,

Have a look at InVision for some more changes.

> no profiles at all (the user deletes all of them)

Can we disable the “Delete Profile” option if only one profile is available? That way, the user will never end up with no profile at all.

If we can’t disable this action, then we should show a message that encourages them to create a new profile.


> only 1 profile - a lot of empty space, I guess...

If we have a minimum height value, then we shouldn’t end up with a lot of empty space. In the mockup, I have set this minimum value at the combined height of 3x profiles + 1x create button.

What would be nice is if, after you delete a profile, the height of the window would resize down to fit exactly. And it will stop resizing down once it reaches the minimum height as specified above.

What do you think? Is it possible to resize the window like this?


> 10 profiles - how do we scroll?

In the design, I’ve specified the max-height of the profile manager to be the height of the user’s screen. So the number of profiles you see all at once depends on the height of your screen.

Is this a good idea? What if, instead of 100% of the screen, we set the window height to 80–85% of the screen, instead? The user can always resize it, of course.

What happens if you have more profiles than what the height of your screen allows? Nothing fancy here. We’ll show the scrollbar if the OS allows it. And if the OS doesn’t allow it, the user will know that some of their profiles are missing, so they will know to keep scrolling down.


> Scenario: I want to set profile A as default, but then I want to start profile B.

Inspired by suggestion from Ryan Feeley, I’ve designed a way to set default that’s directly inspired by our bookmark star.

The way you complete the above scenario is as follows:
1. Hover mouse over profile A, or click the arrow to the right of profile A
2. You’ll see the outline of a button called ‘default’. Click on this to set profile A as default
3. Finally, click on profile B to run it

When I set profile A as default, any profile I have previously set as default will be unchecked.

If I then uncheck profile A, but does not pick any other profile as default, I will have no default at all.

What do you think of this method?


In the mockup, Ryan has also suggested positioning the delete button below the fold, so you would always have to scroll a little bit in order to see it. This as a good idea, as this prevents accidental deletion. However, if our power users like to delete their profiles quite often, we will not want to hide this button. What do you think?
Flags: needinfo?(amarchesini)
Addedum:

You can try out this check/uncheck default feature on the details view. Try going to the profiles called “Default Profile” and “Lightbeam”.

In reality, you should be able to check/uncheck on the profile list view, but it’s not possible to accomplish using InVision. But what I’ve done here is show you what happens when you hover over each profile. Try it out, and you’ll see the “default” button appear in and out of view.
> Can we disable the “Delete Profile” option if only one profile is available?
> That way, the user will never end up with no profile at all.

What about if it's a fresh new installation of FF and the user does -P ?
We must cover this use-case.

> If we can’t disable this action, then we should show a message that
> encourages them to create a new profile.

Sounds good to me.

> What do you think? Is it possible to resize the window like this?

Yes it's possible. But usually desktop apps do not change size so often.
Plus, usually the user has 1 or < 5 profiles. This means that all the delete/creation operations will resize the window.
And resize the window cannot be done with a smooth operation (progressively) because it's often managed by the OS (thinking about linux for instance and all the Xorg compositor apps).

> Is this a good idea? What if, instead of 100% of the screen, we set the
> window height to 80–85% of the screen, instead? The user can always resize
> it, of course.

Yes, better. How do we combine this manual resize with the previous point?
The user manually resizes the window, then it deletes 1 profile and we resize the window again to make it smaller.
Could it be a bit confusing?

> What happens if you have more profiles than what the height of your screen
> allows? Nothing fancy here. We’ll show the scrollbar if the OS allows it.

It does, because the content will be full HTML. Right? :)

> The way you complete the above scenario is as follows:
> 1. Hover mouse over profile A, or click the arrow to the right of profile A
> 2. You’ll see the outline of a button called ‘default’. Click on this to set
> profile A as default

good.

> I will have no default at all.
> What do you think of this method?

It works.

> In the mockup, Ryan has also suggested positioning the delete button below
> the fold, so you would always have to scroll a little bit in order to see
> it. This as a good idea, as this prevents accidental deletion. However, if
> our power users like to delete their profiles quite often, we will not want
> to hide this button. What do you think?

This can be strange, does it? Think about this scenario:

the user has many profiles, so the window will be big and it will have a scrollbar to show all the profiles.
Then, the user clicks opens the menu of one of the profiles and he/she the list of options. The window is still big so it can contain 'delete' but the user must scroll to see it.

b
Flags: needinfo?(amarchesini)
Hi Andrea,

I agree with your suggestion to put the Delete button within reach, instead of hiding it. We should still put a little space between the button and the element above it, to create some distance and prevent misclick. But we should always show it.

As for the automatic window resizing, I think we should drop it. This behaviour tries to emulate how native apps work, but if we can’t do it smoothly or reliably in Firefox, it will look janky and unprofessional. And by removing it, we’ll have an easier development time.

What do you think if our window height behaviour is set like this:
* Every time profile manager is opened, figure out how many profiles currently exist
* Set window height based on number of profiles, plus the Create New button. For instance, window height for 5 profiles is (5*60px) + 60px for create new button = 360 px
* Allow user to freely resize height

We’ve figured out what happens when you resize height. Now what happens when you resize width?

I’ve tried to demonstrate it here:
http://brampitoyo.github.io/fx-profile-manager/

The demo isn’t perfect, but hopefully you can get a sense of what I’m trying to show. On medium and wide layouts, we have enough space to show the details view, so we can actually align the profile list left.

The layout logic actually works like this (paper diagram):
http://f.cl.ly/items/2D1y161L2e0e3a1h2O3m/profile-manager-responsive-layout.jpg

What do you think?
Flags: needinfo?(amarchesini)
> What do you think if our window height behaviour is set like this:
> * Every time profile manager is opened, figure out how many profiles
> currently exist
> * Set window height based on number of profiles, plus the Create New button.
> For instance, window height for 5 profiles is (5*60px) + 60px for create new
> button = 360 px
> * Allow user to freely resize height

Yes. This can be done. And I like it.

> The layout logic actually works like this (paper diagram):
> http://f.cl.ly/items/2D1y161L2e0e3a1h2O3m/profile-manager-responsive-layout.
> jpg


I see. I think it can work! The only concern is that we cannot store the size of the profileManager for the next session. That means that this responsive layout is somehow hidden and/or hard to discover.

Another approach would be to don't allow the width resize.
Flags: needinfo?(amarchesini)
I’ve updated the demo to show the correct layout logic:
http://brampitoyo.github.io/fx-profile-manager/

> The only concern is that we cannot store the
> size of the profileManager for the next session. That means that this
> responsive layout is somehow hidden and/or hard to discover.

You’re right that we cannot store window size. However, we can still code our CSS responsively so that users who resize their window will get an appropriate layout, while users who don’t bother resizing will still get a fully functional narrow interface. What do you think?

The example above is starting to show the visual style, but it’s still very early. I am hoping that the profile manager can use the existing CSS used by in-content pages and popover menus so that our interface will look native to Firefox, and you don’t need to code new elements (except maybe the “Default” flag).
Flags: needinfo?(amarchesini)
> fully functional narrow interface. What do you think?

Yes. Makes sense.
Do you want me to start 'animating' the demo you have?
Flags: needinfo?(amarchesini)
Hi Andrea,

I’ve reviewed the responsive design with Philipp Sackl yesterday evening, and he had a good point: on medium and wide layouts, our view closely resembles the two-pane interface of tablets and email apps/websites.

The problem is, our interface behaves differently from theirs. In ours, you need to click specifically on the arrow to get to the details view. Clicking anywhere else will launch the profile. But in tablet/email, you can click anywhere to get to the details view.

It seems, then, that sticking with the narrow layout will result in less confusion.

What if we take your approach on comment 11 and don’t allow width resize (but still allow height resize)? Can you work with that behaviour?
Flags: needinfo?(amarchesini)
I'm trying to understand how to allow the resize of the height but not the width. This is a crucial point.
Flags: needinfo?(amarchesini)
Agreed. Keep me posted of your attempt, and please needinfo me if I can help further.
(In reply to Bram Pitoyo [:bram] from comment #16)
> Agreed. Keep me posted of your attempt, and please needinfo me if I can help
> further.

Can we move on and manage this in a separate step? What's next?
Flags: needinfo?(bram)
What’s next: I finish the visual design, then it’s time to implement it. In the meantime, perhaps you can work on the page navigation functionality?

Other than functionality, I am also concerned about how the profile manager can behave similarly to the hamburger menu and control center (example: http://f.cl.ly/items/1h2L0H361H0r020J2S2O/control-center-animation.gif). I imagine that it’s possible to accomplish.
Flags: needinfo?(bram)
(In reply to Andrea Marchesini (:baku) from comment #2)
> cool! Personally I prefer the grid one.
> A question: I see that there is a 'X' near the information box. What happens
> if the user clicks that 'X'? I guess we close the info box and that's ok but
> we don't have any place where we can store that information for the next
> time. Without a profile, we don't have preferences.

In Profilsit v3 I hit this issue as well. Profiles preferences don't exist until the profile has been launched after creation. So I use profiles.ini to save important piece of info there. I prepend special keys with Profilist. However when the regular profile manager is launched it resets the profiles.ini which clears out all my keys. So what I did was, on read of profiles.ini if it finds no /^Profilist/ in there, then it reads from a backup copy I made next to profiles.ini called profiles.ini.profilist.bkp
Just some words on ```“Use the selected profile without asking as startup” different from “Set as default profile”?```

The word "Default" is used improperly in profiles.ini, it helps understand it if we think of the Default key in profiles.ini as "OnNextLaunch-LaunchWithThisProfile".


It is possible that "use selected profile is in checked state" (by checked state, I mean the value in profiles.ini for StartWithLastProfile is 1 [as opposed to 0 when it is not checked]) but there is no default profile. This happens if the default profile was not running, and it was deleted. When this is the case, on next launch of Firefox.exe;Firefox.app/Contents/MacOS/firefox;firefox (the binary), IF no arguments provided, it will launch up the profile manager.


If we wanted to change profiles.ini we would get rid of the Default key and the StartWithLastProfile key. In its place profile entries would simply get the "OnNextLaunch-LaunchWithThisProfile" key.
Some words about the "Work Offline" feature. I've been dealing with profile manager for Firefox for the last 2 years, I have never seen this feature used or requested, ever. It doesn't mean its used, its just my contribution to your stats pool.
Some words about root/local directory.

Local directories also do not exist for profiles created at an absolute path (when IsRelative=0). (most temporary profiles [profiles that do not have an entry in the profiles.ini - are IsRelative=0). After dealing with it for some time, I really don't understand that reason for this.

It might be better to leave that control out of the profile manager, I am sure it would confuse technical users (except tip top technical users).

It wouldn't hurt to display that path though, but giving them control over it, can lead to errors maybe. I like how you guys did that, you didn't give control over it, but just display it. (in profilist i dont even display it, because then I might have to explain why some profiles dont have a local directory - and I dont know that reason).
> In Profilsit v3 I hit this issue as well. Profiles preferences don't exist

hehe, nice hack. If we really need some value stored in the profiles.ini, we can change the serialization of that file.
(In reply to Andrea Marchesini (:baku) from comment #23)
> > In Profilsit v3 I hit this issue as well. Profiles preferences don't exist
> 
> hehe, nice hack.

Haha thanks :D
(In reply to noitidart from comment #21)
> Some words about the "Work Offline" feature […]

I was going to make this feature less prominent (ie. you have to click the arrow to access advanced startup options, which includes start Firefox with Work Offline), so this data point helps confirm it. We can promote it to the forefront when we see that it’s used often.


(In reply to noitidart from comment #22)
> Some words about root/local directory […]

Changing path of local directory sounds extremely dangerous if you don’t know what you’re doing. It’s a good idea that we only have a button to “Show folder”, then.
One thought: is it possible to have a toolbar or hamburger menu icon that serves as an access point to this Profile Manager?

That way, it’s possible to get to this feature without using the command line.

The icon, which is based directly off Firefox Account’s default avatar, is attached.

This is how it might look like on the toolbar:
http://f.cl.ly/items/3S0t0T2O0j0z190r2d13/profile-manager-toolbar.png

This is how it might look like inside the hamburger menu:
http://f.cl.ly/items/3W2E3I2z3V1r2j00021F/profile-manager-hamburger-menu.PNG

Thoughts?
Flags: needinfo?(amarchesini)
(In reply to Bram Pitoyo [:bram] from comment #26)
> Created attachment 8720062 [details]
> profile-manager-toolbar-icon
> 
> One thought: is it possible to have a toolbar or hamburger menu icon that
> serves as an access point to this Profile Manager?


From my experience, people have not liked the separate profile manager. It's an "out of" Firefox experience. These users feel, the access point to profile manager should be within each Firefox process. And these users feel the access point to startup in a different profile should be desktop/system shortcuts.

My data is not scientifically based though, just on observations (and I'm sure my personal bias).

Food for thought - Google Chrome does not have an out of process profile manager. Its built in as well. I think the biggest beneift of built in, is to display what the current profile is. So I like your http://f.cl.ly/items/3S0t0T2O0j0z190r2d13/profile-manager-toolbar.png but I think it should have a badge or something to indicate which profile it is something like:

http://i.imgur.com/Rfj5eC5.png

and

http://i.imgur.com/GVmoTvk.png
Oh also I like your icon a lot, for the toolbar button icon, but its very similar to that of "Sync". We might have to differentiate that a bit. http://i.imgur.com/0sqZsU0.png
Another nice feature of having it within the Firefox process, is that you can show what is currently running and allow focusing of the windows of that profile on click.
> One thought: is it possible to have a toolbar or hamburger menu icon that
> serves as an access point to this Profile Manager?

In theory we have about:profiles for that. The profile manager works without having any profile running.
I tried to combine about:profiles and Profile Manager but it doesn't really work:

. in about:profiles you cannot open a profile (yet)
. you cannot delete the active profile

I guess that, what you are proposing, is a follow up where we introduce a better about:profiles that allows people to open multiple profiles at the same time.
Flags: needinfo?(amarchesini)
(In reply to noitidart from comment #27)
> From my experience, people have not liked the separate profile manager. It's
> an "out of" Firefox experience. These users feel, the access point to
> profile manager should be within each Firefox process. And these users feel
> the access point to startup in a different profile should be desktop/system
> shortcuts.

This is a really interesting data point.

When you run Firefox with --P, it opens the Profile Manager. The difference is, this Profile Manager will not have the old design, but the design that Andrea has landed on about:profiles. This design is what I’m trying to come up with.

As I understand it, about:profiles is a subset of Profile Manager that is less capable. You can view information about profiles, but you cannot actually run it. And obviously, you cannot delete your current profile because you are currently running it. However, in terms of design, it should look and function the same way.

The problem of how to access this manager/switcher is a bit out of scope for this bug, but it’s fascinating.

In the past, I’ve designed a few means of accessing this manager, but I have always had these two problems:

* When I create a new profile (let’s call this Profile 2), Firefox does not make me a new desktop shortcut. Therefore, to access this new profile, I have to run Profile Manager first.

* When Firefox makes me a desktop shortcut, it’s not easily accessed via the Start Menu and also impermanent (ie. when I delete that shortcut, I cannot easily recreate it). It’s also unclear what would happen when I click on the “original” Firefox icon.


I posit that running multiple profiles from the desktop shortcut seems easy, but is incredibly complex to do without causing confusion. And this may be why Google Chrome chose to move their profile picker out-of-process, so that there is one place to do all profile-related stuff, even when your desktop shortcut is erased.

* When Profile 2 is created, I want a way to access it easily. So Firefox should create new shortcuts in Desktop, Start Menu, Dock, Application folder, etc. Then, label that shortcut icon with my name and avatar. This way, I know how to run Profile 2.

* The moment I create Profile 2, Firefox should create a new shortcut that will run Profile 1. This is important, so I’m not confused about how to run Profile 1.

* In addition to this, when every icon has been labelled, Firefox should erase the icon that’s labelled “Firefox”, because it’s now meaningless. When you want to run Profile 1 or 2, you click on the respective shortcuts. But what happens when you click the shortcut labelled “Firefox”? It’s unclear. So we should erase that shortcut.

* Each profile has a name, and each Sync account has an email address and an avatar. The problem is, profile and Sync is technically separate, but in user’s mind, they’re kind of the same as they’re both things that you “sign into”. So we’re in danger of conflating the two concepts.


And this is why I’m more comfortable with proposing something that’s conservative and closer to what we already have today (“There is one Firefox icon. Profile Manager is out-of-process”) instead of something that can be potentially confusing to manage (“There are many Firefox icons for many profiles. Profile Manager is in-process.”)


Either way, we can explore these design alternatives because we’re designing for the DevEdition audience, not for everybody. So let’s keep discussing! Although maybe I would suggest moving it in a different bug?


You can see some of my prior works here:
* https://www.lucidchart.com/documents/view/9aa96a8d-a597-455b-b70e-f3ef348dc3e6
* https://www.lucidchart.com/documents/view/b2e30bc8-36be-4f17-aa04-a09b2aea75f5
* https://www.lucidchart.com/documents/view/d9c7ddb2-1c73-486b-bb7e-10ca7c30fca4/7
(In reply to Bram Pitoyo [:bram] from comment #31)
> The problem of how to access this manager/switcher is a bit out of scope for
> this bug, but it’s fascinating.

Ah ok I'll keep it to a minimum. 

I address all those in issues but with a different take on it in Profilist v3. My primary access to profile-manager and other-profiles as each profile itself. Desktop shortcuts in Profilist are secondary, they are recreated from the options page though.

Whenever a new profile is created no launcher is made. However on launch, in the userApplicationDataDir, Profilist creates a launcher (in windows its a shortcut, in mac its a symlinked .app, in Linux its a .desktop). This launcher icon and name is always kept up to date based on build/channel/profile name/badge. Name is with "Firefox [channel_name_here] - [profile_name_here]".

About the default launcher. v3 still keeps it around, however whenever a user set a new default profile, the main launcher (Firefox.app/Firefox.exe/binary) is given the badge of the newly defaulted profile, it's not renamed though. Updating all locations windows, platform locations (Win8 start menu, OS X locations, Linux Docks) etc is in the "Icon/Shortcuts Robustness" category which I have to complete for v3 - https://github.com/Noitidart/Profilist/wiki/3.*-Task-List

I think yeah I'll keep this discussion out of this topic, as you guys work here Ill finish the robustness on that and then release to AMO. Then we can maybe/hopefully discuss that later. That's cool I didn't know GChrome made an out of process profile manager.
By the way that "password protected profile" feature in your past work, is really cool, I got a couple requests for that, but couldn't offer them anything on that end yet.
Noit, we should definitely have a chat about what you have learnt from all the years working on Profilist. I’m doing design but am missing actual user feedback and data that you already have – and it could help inform the design of our manager. I’ve tried Profilist in the past, but I wasn’t able to get v3 to work.

I *think* Chrome’s profile manager runs on a different process, yes, although it shares the same icon.
Bram, what about if we support the opening of a different profile via about:profiles and we keep the ProfileManager as it is (well, with your new UI, of course), instead thinking about different icon, link, app shortcut, etc.
The idea behind this is that you always have a default profile and you can open other profiles only via the default profile.
This would be a nice simplification of the problem and it makes the 'non-default' profile connected with the default one as the private browsing can be opened only from the default browsing mode.
Flags: needinfo?(bram)
Andrea, your idea of simplifying the system sounds great to me. Let’s do that and get it deployed on Nightly and maybe DevEdition. If the behaviour doesn’t feel right, we’ll tweak it.

In the meantime, we’ll have something that looks reasonably good, works reasonably well, and can be tested (meaning, we can ask users “What do you think? Would you use it?”)
Flags: needinfo?(bram)
Sounds good. So the next steps for me will be to implement your work and propose a patch. Plus support the opening of different profiles via about:profiles.
I’ve updated the InVision mockup with visual design refinements. It should look very close to how it’s supposed to.

https://invis.io/8J5NTOFFG
Bram, do you think it's possible for you to give me that mockup in HTML?
Flags: needinfo?(bram)
I’ve sent you an email about this. I think I can generate a static HTML prototype, but will need help with the more interactive parts. For example:

1. ‘Default’ flag that appears on hover and can be switched on and off
3. Animation and secondary panel when you access the preference of a specific profile
2. Edit profile name interface
Flags: needinfo?(bram)
Attached image profile-manager-hamburger-menu-icon.svg (obsolete) — 
(In reply to Andrea Marchesini (:baku) from comment #41)

I’ve rescaled and adjusted the 16x16 icon so that it looks good at 32x32 – the size that fits into the hamburger menu.

Let me know if there’s any other visual work to do!
Thanks Bram! Will update with a mockup similar to yours using HTML very soon.
One thing that concerns me is achieving the same ‘slide-over’ transition used by the Control Center (and other menus in Firefox). It will be important, I think, for this feature to look and feel as similar to other Firefox features as possible.

Example transition: http://f.cl.ly/items/1Y1u3l340A2i0r0H220e/control-center-animation.gif

Blake Winton has done some work here – http://firefoxux.github.io/StyleGuide/#/components/panels – that you might be able to take advantage of. I’m CCing him on this bug in case it’s relevant to his interest.
Me too Bram, thats why I had resisted showing you for a while :D.

I have uploaded my current progress here: http://jonathankingston.github.io/profile-switcher-mockup/lib/ (The top one clicks)

I will let you know when I have further progress.
Ooh, neat…  I recommend grabbing the styles from http://firefoxux.github.io/StyleGuide/static/css/all.css to make it look a little more Firefox-y…  :)
Can we consider to add the 'Guest' mode in this UI?
Flags: needinfo?(bram)
Hi Andrea, adding a “Guest User” on the Profile Manager UI is just a matter of adding a line item. It’s simple enough.

We just need to explain it in a clear and simple way. Maybe as a caption text below the username?

Here are some potential explanatory text. It’s just my first stab at the problem, so they’re rather rough:

* “Hand your browser over to someone else without giving them access to any of your data”
* “After being used, all data will be wiped clean and returned to its original state”
* “All data saved will be deleted when this profile is closed”
* “Let other people have temporary access to your browser”
Flags: needinfo?(bram)
> * “Hand your browser over to someone else without giving them access to any
> of your data”

+1

So, yes, the idea is that we create a temporary profile, and we delete it on shutdown.
We need to expose that this is a guest profile in the UI as well.
So maybe we can work on it as follow up. What do you think?
Sounds good. Let’s work on guest profile as a follow up. Adding a line item is easy, but I have no idea about all the platform work required to support it (you might know better)?
Right. For a platform point of view, I need to change quite few things, but I can easily do it in the follow up. I'll file bugs for this new feature.
Great. Please CC me on the bug if relevant. There are some minor design things to work on, like naming (Guest? Temporary?), and how best to describe the concept.
Re temporary profiles. `jpm run`, while in a addon dev directory, does this. After the profile is done running it deletes itself. Or if it doesnt delete itself, it might be jpm that deletes its directory after it sees its not running. It's interesting.

How temp profiles are handled in profilist - Temporary profiles show in list of profiles when it is running (so clicking it in profile manager, will focus its windows), or the profile directory has not yet been deleted (so clicking in in profile manager launches it again). Once it is found to be deleted then it is no longer shown in the list. Profilist does not have a button to create a temporary profile. It's an awesome idea though. I would love to add that feature in so Ill watch bug 1270383 closely :)
bram, can you provide icons for the new profile Manager button in the hamburger menu as you did for containers?
Flags: needinfo?(bram)
Attached file MenuPanels-Assets.zip — 
Flags: needinfo?(bram)

    
  

        Attachment #8746336 -
        Attachment is obsolete: true

    
    

    
  
Icons added as part of the spritesheet. This time, I made sure to run them through ImageOptimise, and trim off the unneeded files (Windows XP @2x, Linux @2x).

    
    

    
  
Hey Bram and Andrea! I worked around the e10s problems on Profilist v3 so it should now work for you.

Please try out beta 5 (latest beta) when you get a chance - https://addons.mozilla.org/en-US/firefox/addon/profilist/versions/beta - it has some of the ideas I was trying to show you (like jumping to windows of curently running profile, badging icons etc)

I updated the buzilla topic with what caused that e10s bug too - https://bugzilla.mozilla.org/show_bug.cgi?id=1249929#c28

    
    

    
  
Whoops was so excited that I worked around e10s bug, I forgot to test the other things. Uploaded beta 6 now.

    
    

    
  
Hi Noit,

These are all cool ideas!

What are the rules for badging icons, and how do I do it? It’s a smart idea. I think that it’s a natural tie to either a person’s identity (so, their avatar picture) or a website’s favicon (if you’re using a profile only to access a specific site).

At the moment, my Profilist beta 7 shows a “Moved in preparation for an HTML future”. When clicked, the picker opens in a new pinned tab. Is this an intended behaviour?

    
    

    
  
(In reply to Bram Pitoyo [:bram] from comment #60)
> Hi Noit,
> 
> These are all cool ideas!
> 
> What are the rules for badging icons, and how do I do it? It’s a smart idea.
> I think that it’s a natural tie to either a person’s identity (so, their
> avatar picture) or a website’s favicon (if you’re using a profile only to
> access a specific site).
> 
> At the moment, my Profilist beta 7 shows a “Moved in preparation for an HTML
> future”. When clicked, the picker opens in a new pinned tab. Is this an
> intended behaviour?

Hey bram! Yep thats the intended behavior. So excited to hear it worked for you! That e10s issue was a huge hurdle for me haha.

That's correct, as people migrating from v1.x will expect to see a menu item there. So clicking that item should open a pinned tab to about:profilist?html

The badging is different from sync profile, so i dont use that image, as users can sync multiple profiles to same account or any other combination.

To apply a badge, click on "user" icon in the html page. Then it opens a file browser. You can select a previously saved iconset from there. Or browse your computer for an folder with an iconset in there (i give error messages as you browse so users know what a valid iconset folder is like). For testing though, you can go to "Download" then double click "Badges" folder - http://i.imgur.com/mvjH9rv.png - and then apply any of the ones contained within - such as dinomoz - http://i.imgur.com/gpsuzLc.png - and then it will change the icon.

Beta 7 does not refresh the system icons, so you won't see the update to the dock until you log out or log back in. But to refresh the icons, please pop open your terminal then type in "killall Dock" "killall Finder". If you had a desktop shortcut to this, its icon will also be updated.

If you want to make a desktop shortcut, go to about:profilist (options page) then create one from the drop down. :)

    
    

    
  
Oh by the way I am redoing a lot of stuff, with new techniques I learned in the last couple months. I haven't tested beta7 in mac yet. It should work, but if it doesn't please do let me know, I'll update you when beta8 is out, should be soon. :)

    
    

    
  
Bram, do you think we need some UI changes based on what happened for about:containers?
Flags: needinfo?(bram)

    
    

    
  
I don’t think we need to change our UI. Profile management happens at the level above the browser – similar to how OS profile happens at a level above the desktop (ie. the login screen), so putting them on an in-content page like Container Tabs preferences doesn’t sound like the right approach.
Flags: needinfo?(bram)

    
    

    
  
It is a rather odd situation if we have an experimental feature known not to be fully functional in Release. 

Is this feature being documented anywhere ?
For instance maybe update the documentation at https://developer.mozilla.org/Firefox/Multiple_profiles
The existing Sumo KB has discussions including 
> [fx46] New Profile Manager UI: about:profiles
> https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles/discuss/6449
  

What is the intention of the clickable button in the Release 
>[Launch profile in new browser]
It may seem reasonable for it to do as it says and immediately launch Firefox with the selected associated profile. In fact it just opens a new Firefox window in the current profile when I try it. If I were working with the longstanding profile manager or a commandline I would be thinking about using -no-remote   

Firefox has a *Refresh* feature. 
That has clickable buttons to initiate the feature in various places including in about:support and the kb article https://support.mozilla.org/kb/refresh-firefox-reset-add-ons-and-settings  that creates a backup profile on the User's Desktop. 
*Is about:profiles intended to interact with that profile ?* 
In my opinion that would be very useful. Mozilla aggressively promotes this one click solution: for instance  even if you do not use Firefox for while it pops up. End users click this lose add-ons then find there is no one click, or remotely use friendly method of reversing this.

    
    

    
  
This thing is a joke! Just discovered this flaw after reading a contributors thread that John99 posted in and decided to try this new feature out.

Launched from command variables as such; "C:\Program Files\InternetBrowsers\Firefox 48 RC2\firefox.exe" -Profile D:\0-Firefox\0-RemoteProfiles\RC2-07-29-2016

This is what about:profiles comes up with:

Profile: default-1454043906128
Default Profile	no
Root Directory	C:\Users\Administrator\AppData\Roaming\Mozilla\Firefox\Profiles\7c2s0qyn.default-1454043906128
Local Directory	C:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\7c2s0qyn.default-1454043906128

Profile: default-1454191149183
This is the profile in use and it cannot be deleted.
Default Profile	yes
Root Directory	C:\Users\Administrator\AppData\Roaming\Mozilla\Firefox\Profiles\bajte06i.default-1454191149183
Local Directory	C:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\bajte06i.default-1454191149183

It's like Firefox can't "see" the Profile that it is using and incorrectly assumes it is using the Default Profile which happens to be Profile1 and also shows Profile0 the two in the profiles.ini file.

True that I am using an esoteric method of launching Firefox by having the Profile outside of the Roaming / AppData location and using command line arguments to launch it, but this thing should be quite a bit "smarter" and "know" which Profile is being used as displayed via about:support > Profile Folder -> Show Folder.

about:support can find it, about:profiles should, too or say something like "can't be found".

    
    

    
  
the-edmeister, Thanks for your comment. What you found is a bug and I'll fix it in bug 1300357.

    
    

    
  
(In reply to John Hesling [:John99] (NeedInfo me) from comment #65)
> Firefox has a *Refresh* feature. 
> […]
> *Is about:profiles intended to interact with that profile ?*

Good point. What if we add this feature as a menu item inside the preference menu of each profile? Call it “Refresh Profile” or something, and then have another dialogue explain what it does before you select “Confirm” or “Cancel”. But we need to warn them that their profile will be closed momentarily and then reopened.

    
    

    
  
Thanks for the reply Bram

Advanced users with multiple profiles probably do not want or need a Refresh option. It may be more appropriate to only offer that option on the default profile. (Maybe Reset once worked like that, but I note it will now Refresh other profiles)

One point I was asking about was the ability to reverse the Refresh option, but that will presumably be another topic and another bug. If you do opt to offer a Refresh option from the Profile picker then I would consider a prominent warning that extensions were being removed would help, much more so than any warning about a momentary closure. There is a warning at present, but it is probably clicked through, on the assumption that extensions will only be disabled or reset but not fully removed.

My main question about the Refresh & Profile Picker was the ability to interact with the profile that is on the desktop. Displaying its details and path would be  good. Being able to move it back to a regular location would be very good, because the profile picker would then be able to reverse the Refresh if necessary.

As for the Profile Picker itself. Have you any comments please on 
The documentation for the Profile Picker, and why it is in Release if it is still not fully functional
The use of the Profile Picker's  [Launch profile in new browser] which apparently does NOT do that.

    
  
Priority: -- → P5

    
    

    
  
Bram, we could probably find some energy to spend in this project in 2017. I wonder if you think this UX is ok or not.
What about having an approach similar to profilist addon based on an hamburger menu panel?
Flags: needinfo?(bram)

    
    

    
  
Can we also establish if HTML can be used prior to starting it. I spent some time on some HTML UX studies to replicate animations used in XUL however I want to make sure that would be what would be used recoding from one to another isn't a good use of time. The test pilot for containers might however use some of these animations though. Not sure who would be the code reviewer for the profile manager but asking them first if they would accept a HTML solution would be nice.

    
    

    
  
(In reply to Andrea Marchesini [:baku] from comment #70)
> Bram, we could probably find some energy to spend in this project in 2017. I
> wonder if you think this UX is ok or not.
> What about having an approach similar to profilist addon based on an
> hamburger menu panel?

My original intention was to have a UX that’s “one level up” from the user level, similar to how an OS profile launcher sits a layer above your desktop. To do this, everything needs to be on a separate window.

But having a Profilist-like approach may also be a good idea.

If we keep in mind that the profile switcher is “a feature for a very technically skilled audience and not for the broad user base” (comment 0), we can actually run user test to compare Profilist vs. the window-based UI before starting engineering.

Regardless, we want user indicator and entry point for profile management to be located inside the hamburger menu.
Flags: needinfo?(bram)

    
    

    
  
(In reply to John Hesling [:John99] (NeedInfo me) from comment #65)
> What is the intention of the clickable button in the Release 
> >[Launch profile in new browser]
> It may seem reasonable for it to do as it says and immediately launch
> Firefox with the selected associated profile. In fact it just opens a new
> Firefox window in the current profile when I try it. If I were working with
> the longstanding profile manager or a commandline I would be thinking about
> using -no-remote   


It actually does launch the profile in a new instance of the browser, as long as the instance it is being launched from was started with -no-remote

ideally, this should be passed by the profile manager ui itself.

    
    

    
  
> (In reply to John Hesling [:John99] (NeedInfo me) from comment #65)
> It actually does launch the profile in a new instance of the browser, as
> long as the instance it is being launched from was started with -no-remote
> 
> ideally, this should be passed by the profile manager ui itself.

It seems like this could be handled by adding "-no-remote" to this argument list: http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/toolkit/components/startup/nsAppStartup.cpp#1018(In reply to Danial Horton from comment #73)

    
    

    
  
I am not a UX expert but that seems a chicken and egg paradox. If the user does not understand comandlines or profiles.ini & -no-remote and is using the easier method provided by this bug and clicking buttons in about:profiles they are never going to be starting with -no-remote in the first place.

(In reply to Danial Horton from comment #73)
> (In reply to John Hesling [:John99] (NeedInfo me) from comment #65)
> > What is the intention of the clickable button in the Release 
> > >[Launch profile in new browser]
> > It may seem reasonable for it to do as it says and immediately launch
> > Firefox with the selected associated profile. In fact it just opens a new
> > Firefox window in the current profile when I try it. If I were working with
> > the longstanding profile manager or a commandline I would be thinking about
> > using -no-remote   
> 
> 
> It actually does launch the profile in a new instance of the browser, as
> long as the instance it is being launched from was started with -no-remote
> 
> ideally, this should be passed by the profile manager ui itself.

I will also add use of the button sometimes results in a warning message about Firefox already running.
I wonder if bug 1300357 (comment 67) should block this bug? 

Mission creep?
I am not intending to drag these comments  out of scope, the discussion scope already seems to have widened somewhat. 
I find it rather odd that this is in Release, albeit not yet from the hamburger menu whilst it is experimental, and I note comment 0 was suggesting a separate ticket be used for the general use case - but I do not see any such bug.  
*It appears the subject and purpose of this bug may be widening to encompass such use by Release users.*
- Bram - are you happy with such discussions being kept in one place, here in your bug or is a separate bug preferred as comment0 advised.

It is worth remembering use of a additional profile can be a useful troubleshooting step, and that use of the Firefox Reset feature along with moving the original profile; removes Add-ons, an issue that the then Sumo Content manager was mentioning (bug1017919 comment1) as the last hurdle to be fixed in Reset/Refresh, but so far that remains an elusive goal. This about:profiles feature could become a very useful tool used by ordinary none technical Release users. 
Reset now gets promoted as a *tune-up* and I am sure many users choose it clicking through the warning about addons only realising too late that they can not easily reinstate their addons. Realistically currently they need to rediscover them and redownload them.


(In reply to Michael Layzell [:mystor] from comment #74)
> .... 
> It seems like this could be handled by adding "-no-remote" to this argument
> list:
> http://searchfox.org/mozilla-central/rev/
> 7419b368156a6efa24777b21b0e5706be89a9c2f/toolkit/components/startup/
> nsAppStartup.cpp#1018(In reply to Danial Horton from comment 73)

Michael, I personally do not understand the consequences of that. I wonder if you could help me by clarifying that please:
- Would such a change merely resolve this issue when the about:profiles feature is in use ?
- OR would that result in the default profile starting in -no-remote every time; as seems may be required for the button discussed to work. 
- Could such a change IF for the default profile possibly have any undesired consequences for Firefox use ?? {However I note Bug 716110 fixed, & not to be confused with bug 1080319 ).

    
    

    
  
I can answer for Michael,

The issue is that when firefox is launched without any arguments, any external links from other applications open links in that existing instance. The behavior occuring with the profile manager currently is because of this.

Passing the -no-remote argument in that code would mean the new profile is launched correctly in the new instance, and without this instance binding. Links opened from an external source will continue to open in the original instance.

You can replicate the existing behaviour with desktop shortcuts.
any attempts to open the profile manager from a shortcut (Firefox.exe -P) will result in a new window opening up instead of the profile manager.

Pass -no-remote as well and the profile manager selection appears.

The downside is that passing no-remote on the initial instance will cause external links to throw up "firefox is already running" 

There is no downside to passing -no-remote from about:profiles. if the first instance is closed, it will  be opened anew if any external links are opened.

    
    

    
  
(In reply to John Hesling [:John99] (NeedInfo me) from comment #75)
> - Bram - are you happy with such discussions being kept in one place, here
> in your bug or is a separate bug preferred as comment0 advised.

I’d prefer for the discussions for a more general use case to be kept on a separate bug. This one was intended mainly to ship the new interface, and have that interface be most helpful for our power users. If we can make it more accessible here, then that’s a bonus, but if we’d like to ship it under the hamburger menu – for example, or other places – then we should create a new bug for that.

    
  
Depends on: 1367743

    
    

    
  
(In reply to Andrea Marchesini [:baku] from comment #4)
> > What do you think about taking out the “Use the selected profile without
> > asking” checkbox, because that functionality is already covered by “Set as default”?
> 
> Yes. it's ok. Maybe we can hide this feature in some advanced menu if
> someone really needs it.

Is an advanced about:profiles menu that includes the "Use the selected profile without asking" option still being considered?  I don't think such an option should be hidden, by the way. Users with multiple profiles will need to UNcheck the "Use the selected profile without asking" checkbox if they want the Profile Manager to always appear at startup, for example, to select a dedicated profile for different Firefox versions. See
https://wiki.mozilla.org/Nightly#How_do_I_install_Firefox_Nightly_alongside_Firefox_Release.3F_2
and https://support.mozilla.org/en-US/kb/using-dedicated-profile-firefox-nightly

    
  
See Also:  → 1406300

    
    

    
  
The bug assignee didn't login in Bugzilla in the last 7 months.

:mossop, could you have a look please?

For more information, please visit auto_nag documentation.


Assignee: bram → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(dtownsend)

    
    

    
  
This bug is effectively dead at this point.


Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(dtownsend)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: