Update user interfaces to match designs

[devinreams]

Fonts, styles, spacing, labels, colors, etc.

To be provided...

[devinreams]

@jimporter the updated editor designs have been provided by @changecourse in Invision:
https://mozilla.invisionapp.com/share/5JDP20NYB#/screens/256782990

• assuming still inheriting browser styles as much as possible (buttons don't need to change to be pixel perfect or anything)
• also assuming we "borrow" the Firefox Accounts markup/styles for the first run experience (just for now, not long term, just to help visually bridge the user jumping from Lockbox tab to FxA Popup back to Lockbox)

Let me know if/how you want to split this up, I'm happy to help where I can.

[pdehaan]

I'm a bit curious about those icons.
I assume they're just a black&white version of the site's favicon (which should be "easy" enough to [de]colorize w/ CSS). But what do we do about sites without favicons, or how would it look with non-transparent favicons?

We have https://github.com/mozilla/tippy-top-sites, which we used for Activity Stream's favicons. Not sure if it'd be useful here. It's still just a random mix of "top sites" on the internet, so wouldn't work for lots of non en_US sites (or even Canadian versions of popular US sites).

Also, would we need to build some sort of image proxy service, so we aren't loading site favicons directly and exposing any referer information?

[jimporter]

I think it's black and white as a way of indicating that it's a mockup. My plan is to store favicons in the datastore itself (but not anytime especially soon); this runs the risk of people having outdated icons, but it would also let people customize their icons, which I think would be pretty useful as a way of quickly disambiguating multiple accounts on one site

[devinreams]

Now that #154 is in place (thanks @jimporter) I will quickly walk @sandysage and @changecourse through where things are at and what, if anything, we should address before Alpha (versus after). 🚢

[jimporter]

My guess would be that we want 1) strings, and 2) a little more polish on first-run. I don't think we'd have time to get first-run pixel-perfect, but I think we could make it look a little snazzier and get rid of the "Done!" page.

I'll also write up a little thing with some more detail about why I think lock/unlock is the right language to use.

[devinreams]

My guess would be that we want 1) strings, and 2) a little more polish on first-run. I don't think we'd have time to get first-run pixel-perfect

Agreed! To help connect those dots...

• strings updated: Update UX strings #163
• drop the "done" page: Condense the first run to one verify (no finished) page #155 (not started/added to milestone)
• lock/unlock: Allow user to "Lock" editor via "Sign Out" to prevent unwanted access to Lockbox data #149 (not started/added to milestone)

I'll check in and see if we should flag anything including/beyond those two for release.

[devinreams]

I just met briefly with @sandysage and @changecourse and the plan is:

Before Alpha

• @changecourse confirm the strings are good ✅ Update UX strings #163
• @devinreams quick CSS changes to:
  • stack label/input on views
  • change buttons vs links (save vs delete)
  • update the header bar weight/style to get more breathing room and visibility
• @jimporter if able, take a look at the effort to remove the extra "Done" screen Condense the first run to one verify (no finished) page #155

After Alpha

(to be prioritized)

• address an "empty state" (add copy to instruct adding an new item) Add "empty state" strings in sidebar #165
• address the sign out/lock experience, including what the editor itself does Allow user to "Lock" editor via "Sign Out" to prevent unwanted access to Lockbox data #149
• get closer to pixel-perfect (Photon) UI Plan UI changes to match mockups #166

[devinreams]

@devinreams quick CSS changes to...

PR started at #168. Depending on how much I can get through this may need some extra assistance.