Closed Bug 602682 Opened 14 years ago Closed 14 years ago

Sync UI: Implement easy setup

Categories

(Firefox :: Sync, defect)

Product:
Firefox
Component:
Sync
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- beta8+
fennec 2.0b3+ ---

People

(Reporter: philikon, Assigned: philikon)

References

(
URL
)

Details

(Whiteboard: [strings][has patch][has reviews])

Attachments

(5 files, 5 obsolete files)

Design v1: "Mobile" flow
314.15 KB, image/png
Details
Design v1: "Desktop" flow
151.86 KB, image/png
Details
Design v1: Balsamiq Source Files (zip)
6.55 KB, application/octet-stream
Details
Part 2 (v1): "Add a device" wizard
18.12 KB, patch
Details | Diff | Splinter Review
Part 1 (v1.1): Add easy-setup screen to setup wizard
35.56 KB, patch
Details | Diff | Splinter Review
No description provided.
Blocks: 592375
This would have two parts: a) 3rd button in the setup wizard ("Transfer account information from another device") that leads to a page showing the PIN. Once you've entered it on your other device and the two machines have exchanged their things, the wizard automatically goes to the "Success" page. b) a link/button in the Sync pref pane ("Transfer account information to another device") that opens a dialog where you enter the PIN that's showing on the device you want to set up. Once the two machines have exchanged their things, the dialog closes automatically. CCing Faaborg for input/critique.
cc:ing beltzner as he has some thoughts on the design/flow.
I would like the PIN to be a section of the sync key. This makes it easier for users to enter (smaller amount of information), and still emphasizes that they should hold onto their sync key in a safe place. If users never need to use their sync key again, they are going to throw it away, and then they are going to call us once they hit zero machines and would like to access their bookmarks and passwords.
(In reply to comment #3) > I would like the PIN to be a section of the sync key. This isn't going to be possible, for two reasons: 1. The PIN also needs to contain information about the channel on the server that the two clients use to communicate. This information obviously isn't in the Sync Key. 2. The PIN should be random for security reasons. Otherwise an eavesdropper might not just get one attempt at guessing the (now static) PIN but multiple times. It's also not clear how this would work with custom secret phrases. Finally, it doesn't make sense to me from a UX point of view. If the PIN were to be part of the Sync Key, the device *showing* the PIN would have to be the one that's already set up and you would have to *enter* it on the new device. We'd like to do the reverse. That way you never have to enter *anything* on a mobile device. The mobile generates shows a random PIN and you enter that on the computer that's already connected to Sync (where it's much easier to enter stuff). > This makes it easier for users to enter (smaller amount of information), I don't understand this argument. > If users never need to use their sync key again, they are going to throw it > away, and then they are going to call us once they hit zero machines and would > like to access their bookmarks and passwords. Well, that's why we're making them back it up when they first sign up, right.
>The PIN should be random for security reasons. Otherwise an eavesdropper >might not just get one attempt at guessing the (now static) PIN but multiple >times. yeah, I was able to put that attack together in my head a bit after posting as well. nevermind! >If the PIN were >to be part of the Sync Key, the device *showing* the PIN would have to be the >one that's already set up and you would have to *enter* it on the new device. That's what I thought the order was, but I agree that doing the reverse and not having to enter anything on the mobile device is preferable (just as you don't have to enter anything on your xbox or bluray player for netflix activation). Back to the original problem I was worried about though, perhaps we should add a quick sentence that is otherwise peripheral to the flow saying something to the effect of "remember to keep a backup of your _sync key_ in case you lose all of your devices"
That sentence really makes it sound like Sync is meant as a backup service. It is not, and we need to be careful to not imply that anywhere. I actually think that if we're using J-PAKE, we're not going to show the Sync Key by default as part of the flow...
Regardless of how hard we try to frame sync as not a backup service, after the user hits zero machines they are still going to want thier data back. We could name Sync "Mozilla NotABackupService" and I would still expect users to become frustrated if they lose their passwords or bookmarks. We can try to deempasize the sync key and say that since we never promised anything their frustration is their own problem. But nonetheless I'm worried that we are not going to be able to effectively set the correct expectations regardless of how hard we try. (which is why I am trying to continually remindt them to keep a long term backup of the key).
blocking2.0: --- → ?
Blocks: 605740
No longer blocks: 601644
I just broke mconnor's brain with a request that I will lodge here as well. To regain some of the "magic", it would be great if: - after the first 4 characters are entered on the "desktop", it connects to the channel and that sends a ping to the mobile - upon receipt of that ping, the mobile shows the next 4 characters - after the next 4 characters are entered on the "desktop", another ping is sent - upon receipt of that ping, the mobile shows the final 4 characters - after the final 4 characters are entered on the desktop and submitted, as soon as the connection is forged, the mobile moves on to the connected state Basically, replace all the user tapping on "next" with "magic" based on the fact that the two devices are talking (via the J-PAKE service).
Axel: heads up, these strings will be landing after the b7 freeze. Wish it were otherwise, and yet ...
blocking2.0: ? → betaN+
Whiteboard: [strings]
Comment on attachment 485132 [details] Design v1: "Mobile" flow Can you explain what's happening on pages 4-6? The "Next" button on those pages also doesn't make sense. There's no next action. Once the mobile displays you the code and you entered it on the desktop, the two machines will do their thing amongst themselves. If that's successful, page 7 should appear automatically IMHO. I do like the way the code is presented a lot, though.
(In reply to comment #13) > Can you explain what's happening on pages 4-6? The "Next" button on those pages > also doesn't make sense. There's no next action. Once the mobile displays you Page 4 presents the first four characters of the code Page 5 presents the next four characters of the code Page 6 presents the final four characters of the code Visually chunking the 12 characters into three sets of four allows the user to hold the "chunks" in their head as they turn their focus to the computer to type them in. Similarly the input areas on the desktop side will initially show four spaces, then once those have been filled in four more spaces will appear, then once those are filled in the final spaces will appear. The user must press Next to get the next four digits, giving them opportunity to check, and the previous characters will continue to be shown. Basically I'm splitting the task up. As mentioned in comment 12, I'd really love it if once the characters were entered on the deskop, the phone would just show the next four. It would make it clear that the two devices were connected. The alternative would be to show all 12 characters in one page: h4t3 jp4k 4u7h But when I looked at the mockup that way, I found it visually overwhelming and hard to instantly find the "chunk" that I was working on.
Still to do: - design the fallback mode when the J-PAKE service is down - figure out what happens if we have a longer than 12 character code* - hate myself
(In reply to comment #11) > I just broke mconnor's brain with a request that I will lodge here as well. > > To regain some of the "magic", it would be great if: > > - after the first 4 characters are entered on the "desktop", it connects to > the channel and that sends a ping to the mobile > - upon receipt of that ping, the mobile shows the next 4 characters > - after the next 4 characters are entered on the "desktop", another ping is > sent > - upon receipt of that ping, the mobile shows the final 4 characters > - after the final 4 characters are entered on the desktop and submitted, as > soon as the connection is forged, the mobile moves on to the connected state > > Basically, replace all the user tapping on "next" with "magic" based on the > fact that the two devices are talking (via the J-PAKE service). I don't think this is really possible because we use the key entered as a whole. Looking at individual parts and acknowledging them is breaking the strength of the crypto and also not supported by the protocol. If we need some protocol on the side just to communicate that some amount of characters have been typed in a checkbox then I would certainly NOT build it into the JPAKE protocol. But instead do some alternative channel to communicate that. JPAKE is pretty well defined. We should not mess with it. The crypto side of things needs to stay very simple and not polluted.
(In reply to comment #16) > I don't think this is really possible because we use the key entered as a > whole. Looking at individual parts and acknowledging them is breaking the > strength of the crypto and also not supported by the protocol. Yes, I acknowledge that we couldn't check that the entered characters were correct, only that they had been entered. I don't care if we bake it into the protocol. I care about the experience. However you get us there is fine.
I also like the experience. So after entering the third line of text on the desktop, the desktop pings the mobile a final time to tell that the code is complete and that we can proceed with the J-PAKE exchange. I think it makes sense to have a progress/status screen in between the displaying of the 'Code Screen' and the 'Connected' screen. The J-PAKE transaction could take a little while since half a dozen requests and periodic polling are involved. It might run in a second or it could take 5.
"design the fallback mode when the J-PAKE service is down" The mobile side is probably the first to know. Do you think it makes sense to first try to generate the code and then show the 'Get Ready to Sync' screen? If J-PAKE is unavailable and we can't generate the code then we probably want to know this as soon as possible and not tell the user to start doing stuff at all. We can then explain that they have to do manual setup and show a different path in the UI.
More notes: * starting the implementation such that the mobile shows the entire code and the desktop has space to accept the entire code is a good first step; we can decide if we want to do the multi-screen thing later * yes, the fallback mode will appear on both the mobile and desktop side if the J-PAKE server is detected to be down
>The mobile side is probably the first to know. Do you think it makes sense to >first try to generate the code and then show the 'Get Ready to Sync' screen? If >J-PAKE is unavailable and we can't generate the code then we probably want to >know this as soon as possible and not tell the user to start doing stuff at >all. We can then explain that they have to do manual setup and show a >different path in the UI. makes sense to me, is the fall back flow just entering the full sync key? Beltzner: would you like me to continue iterating on the desktop flow now?
That is the fallback, yes. One thing to note is that we're considering making the Sync Key a full 128-bit AES key, and getting rid of the passphrase->PBKDF2->AES key aspect, and killing user-generated secrets. Not sure if there's a bug on that, but if the Sync Key is a <1% case, 25 chars vs. 20 doesn't seem like a major difference.
Comment on attachment 485133 [details] Design v1: "Desktop" flow I've just thought of an addition to the first screen to cover the use case of physically separate devices (think home + work desktops). A fourth button saying "I don't have the device with me right now" or something like that would be good. It would bring up something like the "My Sync Key" dialog where you could print or save the Sync Key artifact. You would then take that with you and be able to do the manual setup.
>I've just thought of an addition to the first screen to cover the use case of >physically separate devices (think home + work desktops). A fourth button >saying "I don't have the device with me right now" or something like that would >be good. It would bring up something like the "My Sync Key" dialog where you >could print or save the Sync Key artifact. You would then take that with you >and be able to do the manual setup. yeah, we might branch after they select computer (still trying to decide if the extra step is better than limiting the the number of initial options), but in general I was thinking about the same approach to the user having a remote machine.
Here is a new version of the desktop flow, which includes some sketches of mobile UI from Madhava: http://people.mozilla.com/~faaborg/files/firefox4Mockups/jpakeFlow-i1/jpakeFlow-i1.htm To cut down on the number of steps, I've done two things: -Moved detailed technical manual style directions off into support documents that are each linked by a "Show me how" hyperlink. There are three of these: 1) How to click "add a device" 2) How to click "connect" 3) How to find your sync key It is the role of the support documents to deal with any slight differences between platforms (windows/os x/linux/meego/meamo/android/iOS). As well as formats (desktop/mobile/tablet/television/handheld game console:) -Used generic terminology throughout the interface since we can't predict ahead of time what platforms are in play (right?). The one assumption in these mockups that might not be correct is that fennec is going to have an Add a Device link in preferences after it has been activated. I think it's really important that we avoid creating two classes of devices (computers and phones) where only computers can be used to activate other devices. In particular, I believe that users are more likely to maintain access to their sync account over time if they can use fennec to activate other devices. (since phones are often personally owned, so the user will continue to have access even if they return a work computer). Additionally, this allows us to remove the "from what to what" steps of the flow, and just have the user quickly exchange codes.
URL: http://people.mozilla.com/~faaborg/fi...
I like the simplicity of this on the mobile side. I just have one concern: the fact that that 'Enter my Sync Key' button is on the second screen. This might mean that some users may never see it since they will not go to their sync-connected computer and thus never use that wizard.
(In reply to comment #25) > Here is a new version of the desktop flow, which includes some sketches of > mobile UI from Madhava: > > http://people.mozilla.com/~faaborg/files/firefox4Mockups/jpakeFlow-i1/jpakeFlow-i1.htm This looks really nice. Two comments: * The option to manually enter your credentials should be given on the first mobile setup screen, not after you've kind of agreed to do the transfer method by clicking "Next" * The "Finish" button is indeed not necessary. It will just automatically finish. > To cut down on the number of steps, I've done two things: > > -Moved detailed technical manual style directions off into support documents > that are each linked by a "Show me how" hyperlink. There are three of these: > 1) How to click "add a device" > 2) How to click "connect" > 3) How to find your sync key > It is the role of the support documents to deal with any slight differences > between platforms (windows/os x/linux/meego/meamo/android/iOS). As well as > formats (desktop/mobile/tablet/television/handheld game console:) Heartily agreed. > -Used generic terminology throughout the interface since we can't predict ahead > of time what platforms are in play (right?). > > The one assumption in these mockups that might not be correct is that fennec is > going to have an Add a Device link in preferences after it has been activated. > I think it's really important that we avoid creating two classes of devices > (computers and phones) where only computers can be used to activate other > devices. In particular, I believe that users are more likely to maintain > access to their sync account over time if they can use fennec to activate other > devices. (since phones are often personally owned, so the user will continue to > have access even if they return a work computer). Additionally, this allows us > to remove the "from what to what" steps of the flow, and just have the user > quickly exchange codes. Agreed, though I don't see much of the aforementioned assumption in these mockups, or the "from what to what" steps.
FWIW, I don't know how much the term "device" has equivalents in other languages. Seems that the usage patterns aren't strictly defined yet either? Anyway, could one of you open a thread on .l10n and detail a bit on why you're using different terms for sync participants, and in which context? I guess that'll help localizers to pick the right translation. Thanks
>Agreed, though I don't see much of the aforementioned assumption in these >mockups, or the "from what to what" steps. What I mean is that when it says "go to Sync preferences and select Add a Device" the assumption is that you could be clicking that link on anything (an already set up PC, Android, or iOS device). So not only are we no longer asking what kind of new device you want to add, it is also implied that you can use any kind of device to activate any other kind of device (for instance setting up a new computer when you only have Fennec, or Firefox Home). >Anyway, could one of you open a thread on .l10n and detail a bit on why you're >using different terms for sync participants, and in which context? I guess >that'll help localizers to pick the right translation. Thanks Ok, just started a thread. The context is unfortunately a bit vague, all we know at this stage in the UI process is that the user has some other kind of hardware that runs Firefox.
Actually, one moment while post the message without it bouncing :)
Hi Alex, seems you didn't succeed yet? Just mail it to me and I'll make it a post on your behalf?
Depends on: 610839
A few quick comments >Here's the Fennec side of this: >http://www.flickr.com/photos/madhava_work/5164827140/sizes/l/ -we're trying to avoid over use of the sync logo, on desktop we are only using in the setup flow as the confirmation icon. Removing it from this screen might help to simplify the UI. -I would avoid spaces between the code characters so users don't manually enter them (we can check and remove them either way, but it might increase the number of keys they think they have to type). Sign in (not near my computer) screen: -"Account Name" needs to be "Email Address" -There should be some way for users to find out what their sync key is, like a small help icon that loads a screen with text similar to what we have on the desktop: "You can get a copy a of your Sync Key by going to Sync Options on your other device, and selecting “My Sync Key” under “Manage Account”. Show me how."
(In reply to comment #34) > -"Account Name" needs to be "Email Address" Actually, it should be "Email Address / Username" because existing users need to enter their username here. If that's too long I suggest "Account" (instead of "Account Name").
(In reply to comment #35) > (In reply to comment #34) > > -"Account Name" needs to be "Email Address" > > Actually, it should be "Email Address / Username" because existing users need > to enter their username here. If that's too long I suggest "Account" (instead > of "Account Name"). This is what we did for Firefox Home: Username became 'Account Name' We did this to keep things consistent with the desktop.
Error cases we need to consider (from a conversation with Philipp): -Network goes down (could happen at any moment) -User enters the wrong code -User enters the correct code, but someone attacks at the same time (will surface as the user entering the wrong code) -The user runs out of time (may be 5 minutes)
One more suggestion: Doing the exchange on two local Firefoxen with the server running locally as well takes between 3 and 5 seconds. It will likely take more in the Real World(tm). I would suggest that we add some visual feedback (e.g. a throbber or a label that says "Adding this device..."). Otherwise the user will think it's hanging or something.
(In reply to comment #34) > A few quick comments > > >Here's the Fennec side of this: > >http://www.flickr.com/photos/madhava_work/5164827140/sizes/l/ > > -we're trying to avoid over use of the sync logo, on desktop we are only using > in the setup flow as the confirmation icon. Removing it from this screen might > help to simplify the UI. Well, OK. This style of android panel typically has an icon in that spot, but we could use a generic alert icon instead. > -I would avoid spaces between the code characters so users don't manually enter > them (we can check and remove them either way, but it might increase the number > of keys they think they have to type). Fair enough. > Sign in (not near my computer) screen: > > -"Account Name" needs to be "Email Address" We standardized on "Account Name," I'd thought. Happy to change it if that decision is changing, of course. > -There should be some way for users to find out what their sync key is, like a > small help icon that loads a screen with text similar to what we have on the > desktop: "You can get a copy a of your Sync Key by going to Sync Options on > your other device, and selecting “My Sync Key” under “Manage Account”. Show me > how." OK.
Two more suggestions I'm running into while implementing this: * The "Add a Device" wizard page where you enter the code should have a "Next" button. I don't think it's a good idea to just automatically connect once the user has typed in all 12 characters since they might have a typo on the last one (clumsy as I am I sometimes hit two characters at once, for instance). But we can automatically focus the Next button so that hitting "Enter" will start the transfer. We should then disable the textboxes and the Next button. We could even change the label of the Next button to something else, e.g. Transferring... That might even be an apt solution for the throbber problem I brought up in comment 38. * The wording on the "Device Connected" wizard page is very specific about the duration of the first sync (up to 10 minutes). I suggest changing the wording to "can take several minutes."
I like that the manual login screen on the desktop now combines account + password + Sync Key and looks similar to the other wizard pages where the sync key pops up. However, it does not include a field for a custom server. Is that an oversight, or should we move the custom server to Sync Options? (If we do that, we should also do it in the account signup flow.)
tracking-fennec: --- → 2.0b3+
(In reply to comment #41) > I like that the manual login screen on the desktop now combines account + > password + Sync Key and looks similar to the other wizard pages where the sync > key pops up. However, it does not include a field for a custom server. Is that > an oversight, or should we move the custom server to Sync Options? (If we do > that, we should also do it in the account signup flow.) I forgot to add one other issue: right now we also accommodate for login problems in the "existing account" flow: If you enter the wrong password or Sync Key, we allow you to reset or change it, respectively. Should the Sign In page handle that and if so, how?
WIP Part 1 (v0.1): Add easy-setup screen to setup wizard
Assignee: nobody → philipp
Comment on attachment 490692 [details] [diff] [review] Part 2 (v0.1): "Add a device" wizard WIP Part 2 (v0.1): "Add a device" wizard
Attachment #490692 - Attachment description: Part 2 (v0.1): → Part 2 (v0.1): "Add a device" wizard
Attachment #490692 - Attachment is patch: true
Attachment #490692 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 490691 [details] [diff] [review] Part 1 (v0.1): Add easy-setup screen to setup wizard +<!ENTITY addDevice.setup.description.label "To activate, go to &brandShortName; preferences on your other device and select &#x0022;Add a Device.&#x0022;"> Should this be really brandShortName? Like, do we want to advocate Minefield or it's code name if we get a branding for that?
(In reply to comment #46) > Should this be really brandShortName? Like, do we want to advocate Minefield or > it's code name if we get a branding for that? brandShortName refers to Sync. This is what the mockups say. I don't think it makes much sense to use the full branding here (which I believe even on Minefield will say "Firefox Sync").
Ignore me, I was thinking of syncBrand.shortName.label. Thanks for catching that, Axel! I'll fix it in the next patch.
Fennec has bug 602685 and bug 605740 can be used to track the backend
tracking-fennec: 2.0b3+ → ---
Philipp, can we have an ETA on this one? One of the few open real-strings patches we have for Firefox 4. Thanks.
(In reply to comment #51) > Philipp, can we have an ETA on this one? One of the few open real-strings > patches we have for Firefox 4. Thanks. I'm still waiting for further mockups from UX on a couple of issues: * Throbber * Flow and strings for failure modes (network/server error, wrong secret, timeout) * Placement of custom server option in manual setup. Once I've got those I'll need a day or two to complete. Note that the strings for failure modes will probably live in services/sync/
Have those needs/requests been clearly communicated to the UX team? Can we not continue work here with placeholders?
Somehow this missed a prioritization radar :( Fennec 2 Beta 3 requires the simple setup, which means that we need to ship this in a Firefox 4 beta that coincides. For now I'm marking that beta 8+.
blocking2.0: betaN+ → beta8+
(In reply to comment #52) > * Throbber ^ just use the standard throbber, resize it, and we'll get you a nicer one later. > * Flow and strings for failure modes (network/server error, wrong secret, > timeout) I think in all these cases we should just jump to the "I don't have the device with me" UI. It will appear awkward, but we can resolve that in a future release. > * Placement of custom server option in manual setup. File a follow-up bug, IMO. Nobody's using custom servers right now, so it shouldn't block forward motion.
Phil points out that there are indeed custom servers in use; my bad. We can just add it underneath an expander in the "don't have the device with me right now" UI until we figure out a better approach.
comment #39 >Well, OK. This style of android panel typically has an icon in that spot, but >we could use a generic alert icon instead. Madhava: Let's use a more generic icon, and hold the sync logo for successful completion (provides a more positive connotation, and doesn't wear out the brand by showing it at every step). >We standardized on "Account Name," I'd thought. Happy to change it if that >decision is changing, of course. yeah, I thought we had started to transition extension users over to email address. Account Name it is (which we need to be sure to use consistently).
>Have those needs/requests been clearly communicated to the UX team? yes, although I thought the existing mockups were enough that we weren't blocking the critical path yet. Fresh mockups in progress.
(In reply to comment #58) > >Have those needs/requests been clearly communicated to the UX team? > > yes, although I thought the existing mockups were enough that we weren't > blocking the critical path yet. Fresh mockups in progress. Great, thanks! I wasn't trying to imply that we were at a critical block, just that the lack of definite input had me prioritize other b3/b8 blockers in the meantime.
New version: http://people.mozilla.com/~faaborg/files/firefox4Mockups/jpakeFlow-i3/jpakeFlow-i3.htm This version includes: -feedback (finding jpake server, checking code) -error states (no jpake server, problem with code) -server field -a few small string changes (we assume windows and say "options") -annotated "Show me How" links to bugs for adding various support documents: Bug 613415 - For Firefox Sync add an article about finding "add a device" Bug 613416 - For Firefox Sync add an article about getting an activation code Bug 613417 - For Firefox Sync add and article about locating your Sync Key
Thanks, Alex, these look great. We need to account for the delay that users will experience while the manual login screen verifies their credentials as well as various error scenarios. Just spoke to Alex and he suggested to show a throbber underneath the Sync Key textbox. If there are errors, we show them underneath the relevant input box. This may induce scrollbars if there are too many errors since we can't dynamically resize the wizard window. Alex asked me to add a list of the *current* strings for reference: On the account + password page: * "Connecting…" when you hit Next * "Incorrect account name or password" underneath a wrong account/password * "Reset Password" link when you enter the wrong password (takes you to the website) On the sync key entering page: * "Verifying…" when you hit Next * "Wrong Sync Key" underneath a wrong Sync Key * "I have lost my Sync Key" when you enter the wrong Sync Key (opens up the My Sync Key dialog where you can set a new one)
Changes to the existing setup wizard to make easy setup possible. Now implements failure modes properly and has the right screens and widgets. As we still haven't addressed the styling of the setup wizard (bug 591122) I've cut some corners regarding the theming here and there. For instance we need various glyphs and some paddings, margins and font sizes should be adjusted.
Attachment #490691 - Attachment is obsolete: true
Attachment #492248 - Flags: review?(mconnor)
Attachment #492248 - Flags: feedback?(faaborg)
Add a Device wizard, now with throbber, automatic retry and proper strings.
Attachment #492250 - Flags: review?(mconnor)
Attachment #492250 - Flags: feedback?(faaborg)
Try builds for the v0.9 patches are available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/pweitershausen@mozilla.com-47c9dedbd54e/ This time I've tried to trick FreeBL into exposing the right symbols so our temporary implementation of J-PAKE works on non-OSX platforms. I haven't tested yet as the Win32 build isn't ready yet. When in doubt test on OSX.
Attachment #490692 - Attachment is obsolete: true
Comment on attachment 492248 [details] [diff] [review] Part 1 (v0.9): Add easy-setup screen to setup wizard Did the review on Philipp's machine, as usual everything was pretty meticulously implemented :)
Attachment #492248 - Flags: feedback?(faaborg) → feedback+
Attachment #492250 - Flags: feedback?(faaborg) → feedback+
tracking-fennec: --- → 2.0b3+
Comment on attachment 492248 [details] [diff] [review] Part 1 (v0.9): Add easy-setup screen to setup wizard >diff --git a/browser/base/content/syncSetup.xul b/browser/base/content/syncSetup.xul > <!-- New Account Page 3: Captcha --> >-<!ENTITY setup.captchaPage2.title.label "Please Confirm You're Not a Robot"> >+<!ENTITY setup.captchaPage2.title.label "Please Confirm You're Not >+ a Robot"> Why did you change this? Clearly not for line length, given below: >+<!ENTITY addDevice.setup.description.label "To activate, go to &syncBrand.shortName.label; Options on your other device and select &#x0022;Add a Device&#x0022;.">
Attachment #492248 - Flags: review?(mconnor) → review+
(In reply to comment #68) > Comment on attachment 492248 [details] [diff] [review] > Part 1 (v0.9): Add easy-setup screen to setup wizard > > > >diff --git a/browser/base/content/syncSetup.xul b/browser/base/content/syncSetup.xul > > <!-- New Account Page 3: Captcha --> > >-<!ENTITY setup.captchaPage2.title.label "Please Confirm You're Not a Robot"> > >+<!ENTITY setup.captchaPage2.title.label "Please Confirm You're Not > >+ a Robot"> > > Why did you change this? Clearly not for line length, given below: Argh, I hate sgml-mode. Thanks for catching this, will fix (= not make this change)
Address faaborg's and mconnor's review comments.
Attachment #492248 - Attachment is obsolete: true
Comment on attachment 492250 [details] [diff] [review] Part 2 (v0.9): "Add a device" wizard >diff --git a/browser/base/content/syncAddDevice.js b/browser/base/content/syncAddDevice.js >+ // Can't use this.pin1 because we might be called before init(). >+ document.getElementById("pin1").focus(); why not just make pin1/pin2/pin3 getters? >+ case SYNC_KEY_PAGE: >+ this.wizard.canAdvance = true; >+ this.wizard.canRewind = true; >+ this.wizard.getButton("back").hidden = false; >+ document.getElementById("weavePassphrase").value = Weave.Utils.hyphenatePassphrase(Weave.Service.passphrase); *cough* linebreaks are cheap. >+ onWizardCancel: function onWizardCancel() { >+ if (this._jpakeclient) { >+ this._jpakeclient.abort(); >+ delete self._jpakeclient; delete this._jpakeclient. >diff --git a/browser/base/content/syncAddDevice.xul b/browser/base/content/syncAddDevice.xul >+<wizard xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" >+ xmlns:html="http://www.w3.org/1999/xhtml" >+ id="addDeviceWizard" >+ title="Add a Device" needs-l10n >+ <vbox id="errorRow" align="center" hidden="true"> >+ <hbox> >+ <image class="statusIcon" status="error"/> >+ <label class="status" >+ value="&addDevice.dialog.tryAgain.label;"/> >+ </hbox> >+ </vbox> pretty sure this can just be an hbox, instead of hbox nested in vbox.. >+ <wizardpage id="deviceConnectedPage" >+ label="Device Connected" l10n-needed >+ <wizardpage id="syncKeyPage" >+ label=" " What's with the empty label? >+ <!-- TODO l10n --> >+ <label class="text-link" >+ onclick="gSyncPane.openAddDevice(); return false;" >+ value="Add a Device"/> Do or do not, there is no TODO. (Also, there is no do not, so really there's only do...)
Attachment #492250 - Flags: review?(mconnor) → review+
> >+ <vbox id="errorRow" align="center" hidden="true"> > >+ <hbox> > >+ <image class="statusIcon" status="error"/> > >+ <label class="status" > >+ value="&addDevice.dialog.tryAgain.label;"/> > >+ </hbox> > >+ </vbox> > > pretty sure this can just be an hbox, instead of hbox nested in vbox.. Actually not because we want to center-align horizontally and that's only provided on a <vbox>. Unless I'm missing something. > >+ <wizardpage id="syncKeyPage" > >+ label=" " > > What's with the empty label? Ah good point. It's needed because if the label is an empty string or not there, it prints "Introduction" which is the default title for a wizard page on Mac[1], whereas we really want no title at all (per mockups). I'll add a comment to explaining that. [1] http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/wizard.properties#3
Depends on: 614875
Address faaborg's and mconnor's review comments
Attachment #492250 - Attachment is obsolete: true
Identical to v1.0 but rebased on top of bug 612699. Simplified crypto will in all likelihood land earlier than the J-PAKE stuff.
Attachment #493141 - Attachment is obsolete: true
Whiteboard: [strings] → [strings][has patch][has reviews]
Note to self: small nit: do not import jpakeclient.js but access JPAKEClient through the 'Weave' namespace.
Blocks: 616251
Blocks: 618300
Depends on: 618435
Two remarks: 1. Why are text-link's used for actions that open a dialog? Text-link is only for going to an internet page. (e.g. 'Add a Device' opens a dialog box'). 2. The link 'Show me how' doesn't work yet (the page is not there yet).
Depends on: 618704
>1. Why are text-link's used for actions that open a dialog? Text-link is only >for going to an internet page. (e.g. 'Add a Device' opens a dialog box'). We are no longer following that guideline, however in the future we also won't be having any pop-up windows, and these links will be launching content area UI (like the add-ons manager). >2. The link 'Show me how' doesn't work yet (the page is not there yet). we have bugs filed for creating all of those pages.
Verified Fixed on: Mozilla/5.0(Android; Linux armv7l; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre Fennec/4.0b3pre
Status: RESOLVED → VERIFIED
(In reply to comment #79) > Verified Fixed on: > > Mozilla/5.0(Android; Linux armv7l; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre > Fennec/4.0b3pre Ayan, this bug tracks the fixes to Firefox Sync on trunk. Please verify the fixes there, and not android. bug 602685 is the Easy setup UI bug for fennec--you can verify for android and maemo.
Status: VERIFIED → RESOLVED
Closed: 14 years ago → 14 years ago
oops.. sorry, I pasted the build ID in the wrong bug. I twas supposed to go in bug 602685. Anyways, I did VERIFY this bug on Minefield (2010-12-10)
Status: RESOLVED → VERIFIED
No longer blocks: 618300
Blocks: 618300
Blocks: 610850
No longer blocks: 615950
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: