591533 - Sync UI: Style the physical Sync Key artifact

Status: RESOLVED INCOMPLETE

(Firefox :: Sync, defect)

Description

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

This bug is for designing the html file that is printed or saved containing the user's Sync Key.  Tasks include:

1) Determining final language explaining why the sync key exists (starts with how to use the key, and why you should save it, but then spins into a sort of a mini manifesto on our views on user control and privacy)

2) Visual/print design.  The goal is to make this look really cool, like a plane ticket to the f@#$%ing future :)  This printed page is going to be photographed in the press, and we want users to understand by glancing at it that it has value and should not be thrown away.  Additionally, since so many of these things are going to be created on this planet, we might as well give it a sleek modern design.

The text will be used for the email version, but obviously not the print design (unless we can reliably generate an html email using a mailto: link, which I believe is not possible)

Comment 1

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

Attachment: Draft of the text (not final)

Here is the current draft of the text, this is based on a few conversations already with engagement, but is not yet final.

The overall goal is to clearly position the reason we have decided to use a Sync Key.

Comment 2

[Philipp von Weitershausen [:philikon]]

Looks very nice. Some feedback:

* I advise against putting the username on this artifact, or even the user's real name. If found by somebody they would possibly have two (username, key) out of three necessary credentials (username, password, key) rather than just one (key).

* I suggest saying "You are NOT for sale" and crossing the $ sign out. Otherwise that heading might be misunderstood (and it will be if people just glance over it without reading the text underneath).

Comment 3

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

>* I advise against putting the username on this artifact

agreed, although I'm worried about people having more than one of these.  The text in the mockup is just the shortname.

>* I suggest saying "You are NOT for sale" and crossing the $ sign out.

Trying (perhaps desperately) to get them to read and understand, also I've been instructed to try to keep the text interesting enough to draw the user's attention.  So "wait, what?" is a feature :)

Comment 4

[Philipp von Weitershausen [:philikon]]

The intermediary outcome of this bug should be a single XHTML file with embedded CSS (print + screen) and embedded images (base64 encoded). This could then simply be dropped into the code base. I should say almost as we'd have to convert the text to l10n entity strings first.

Comment 5

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

I've reached out to the first designer we are considering for the print design (my mockup is a pretty rough approximation of what it might look like).  Most of that work will likely occur during the polish phase, in the meantime we can start to get a very simply page that has strings for localization, but no formatting.

Comment 6

[Ed Lee :Mardak]

Perhaps out of the scope of this particular printed artifact, but it might be useful to think about some printed QR code that might simplify setting up mobile sync clients or even other laptop/desktops that have cameras.

Comment 7

[Philipp von Weitershausen [:philikon]]

(In reply to comment #6)
> Perhaps out of the scope of this particular printed artifact, but it might be
> useful to think about some printed QR code that might simplify setting up
> mobile sync clients or even other laptop/desktops that have cameras.

That would certainly be awesome, and this artifact is definitely a good place for this, but definitely post Firefox 4 at this point.

Comment 8

[Philipp von Weitershausen [:philikon]]

(In reply to comment #5)
> in the meantime we can start to get a very simply page that has strings for
> localization, but no formatting.

Good idea. Since the string freeze is imminent, we should get this wrapped up soon. I can work on the patch, I just need to know the final strings.

Comment 9

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

I'll hopefully have those for you tomorrow.

Comment 10

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

Attachment: Sync Key physical artifact, i2

Second iteration of the design of the physical artifact.  The text is now less dramatic and hopefully more empowering.  It might still read a little strong, but that's an attempt to remain interesting to a mainstream audience while talking about the wondrous powers of data encryption.

I've also created three little hieroglyphics to help reinforce the story of why this key exists and what it does.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

I like the hieroglyphs, but there are still too many words in the artifact. The entire text feels defensive, and oddly secondary to the key itself, which is the thing we want users to focus on.

Tomorrow morning I'll take a pass at shorter wording that tries to hit on the same points. I agree that the goal should be to inform and empower, but I do not believe that many people will take the time to read through all the information provided here.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

(Sorry for delay - Rags apparently wants to "sync" with me before I post here, so waiting for that)

Comment 13

[Philipp von Weitershausen [:philikon]]

Any updates on the strings? The string freeze is tomorrow...

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Design:
 - increase the size of the "John's Firefox Sync Key" header a titch
 - increase the size of the sync key itself a titch
 - drop the hieroglyphs across the bottom
 - only two sections beneath the info block: "Keep it secret" | "Keep it safe"
 - add a reference to the privacy policy across the bottom (small)

The emphasis should be on the key itself, which should be easy to read (for older users) and visible at a glance so someone can find it in the stack of crap on their desk.

Strings:

 - &userName's Firefox Sync Key

 - This key is used to decode the data in your Firefox Sync account. You will need to enter the key each time you configure Firefox Sync on a new computer or device.

 - Keep it secret

 - Your Firefox Sync account is encrypted to protect your privacy. Without this key, it would take years for anyone to decode your personal information. You are the only person who holds this key. This means you're the only one who can access your Firefox Sync data.

 - Keep it safe

 - _Do not lose this key._ We don't keep a copy of your key (that wouldn't be keeping it secret!) so _we can't help you recover it_ if it's lost. You'll need to use this key any time you connect a new computer or device to Firefox Sync.

 - Find out more about the Firefox Sync and your privacy at http://services.mozilla.com

(Many, many thanks to Alex for his work on this to date; I am truly iterating on the shoulders of giants while mixing metaphors like rhymes.)

Comment 15

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

This is a bit of a boundary case, but if the user entered their own key, should we modify the text "it could take _years_" with the new time estimate for a brute force attack?

or alternatively, can we just make sure that the user enters something with enough entropy that the years assertion happens to always be true, regardless of if we generated the key or they did?

Comment 16

[Philipp von Weitershausen [:philikon]]

(In reply to comment #14)
> Design:
>  - increase the size of the "John's Firefox Sync Key" header a titch
>  - increase the size of the sync key itself a titch
>  - drop the hieroglyphs across the bottom

Thanks Mike! These will be valuable input when the artifact is being styled. Focusing on the strings for now (bug 596565 for add-on UI, bug 596566 for Firefox UI).

> Strings:
> 
>  - &userName's Firefox Sync Key

I'm not sure that putting the Sync account name on the artifact is such a good idea, especially if it ends up being printed. It would mean two out of three credentials are on that piece of paper. For now I think we should stick with "Your Sync Key".

(In reply to comment #15)
> This is a bit of a boundary case, but if the user entered their own key, should
> we modify the text "it could take _years_" with the new time estimate for a
> brute force attack?

I don't think we should. With our entirely random Sync Key it's very easy to predict the entropy. With user generated stuff it's much less so. Let's keep the wording as general as possible.

> or alternatively, can we just make sure that the user enters something with
> enough entropy that the years assertion happens to always be true, regardless
> of if we generated the key or they did?

This is really something we should discuss in bug 592465.

Comment 17

[Mike Connor [:mconnor]]

Strings are blocking b7 in bug 596566, this just needs to be done by last beta.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

OK, I'll continue the conversation about strings in that bug; sorry, thought this was the one!

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Removing [strings] as those are being applied in other bugs.

Comment 20

[Mike Connor [:mconnor]]

Faaborg, what else do we need to do here?

Comment 21

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

>Faaborg, what else do we need to do here?

We de-prioritized this when we removed the key from the initial sign up process.  But we should still put some work into the design.  No string changes, just HTML+base64 encoded images.

Comment 22

[Axel Hecht [:Pike]]

Is the HTML work affiliated with what we'd need to do for bug 612584? Specifying an encoding the html artifact?

Comment 23

[Philipp von Weitershausen [:philikon]]

(In reply to comment #22)
> Is the HTML work affiliated with what we'd need to do for bug 612584?
> Specifying an encoding the html artifact?

No, they're separate issues. This bug is about the HTML and CSS design of the file whereas bug 612584 is about ensuring that we write the file with the right encoding (utf-8) and specify that in the file as well.

Comment 24

[Mike Connor [:mconnor]]

As the Sync Key has been de-emphasized, this is not a blocker.  Marking wanted instead.

Comment 25

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

We'll be working with Sean on this, bug 626710 covers the design work.  We had a chance to go over all of the goals for the design at the last all hands.

Comment 26

[Gregory Szorc [:gps]]

Is this bug still valid given the recent UI changes around the Sync Key?

Comment 27

[Richard Newman [:rnewman]]

We can reopen if it becomes a focus area.