lockbox-extension

lockbox-extension copied to clipboard

Part of product initiative #528 - Provide onboarding support for new users to the Lockbox extension

Goal

We want to provide Lockbox users the ability to import saved logins from their Fx browser, so they don't have to endure the pain of manually entering all entries; we need to give users an efficient bridge to Lockbox from Fx, especially because we are disabling the login manager when Lockbox is installed. [Note: this import will only be available for Firefox logins at this time, though we'll want to consider other methods of import in future stories]

The primary import method will be part of a user's first run experience, during an onboarding tour, though it will be optional. The secondary import method will be made available as part of the account dropdown, as a way for users to access if they've skipped initially, or if they wish to add additional logins to their lockbox in the future.

Visual Design

InVision https://mozilla.invisionapp.com/share/CTEFRXMZ7#/279643449_0-2_Onboarding_-_Import

Zeplin https://zpl.io/agGzo4Q

Design Acceptance Criteria

• [x] Provide visibility into all available logins within the Fx login manager as part of the import process
• [x] Allow someone to quickly import all Fx logins into Lockbox as a sensible default
• [x] Support batch selection (select all/deselect all) for import
• [x] Support the ability to skip the import process
• [x] Allow someone to choose which logins to omit individually from import
• [x] Allow someone to sort the logins by Site (alphabetically) and Last Used (recency)
• [x] Explore how this integrates into a more comprehensive onboarding experience for first-run
• [x] Allow someone to revisit importing saved logins if they skip the experience as part of first-run

Content Tasks

• [ ] Content for import, step 2

We'll need to break out the import stories for dev into at least two parts, accounting for import within the first run vs. import as part of the account dropdown (if skipped as part of first-run)

We'll need to discuss what happens when a user wants to import outside of the first-run experience... I've currently added it to the menu under the avatar, but as for what happens... TBD.

@changecourse This is great. I have a couple of questions:

1. does this design scale in the future if we want to allow users to import from other locations?
2. what does the sort functionality provide the user in the import process?
   • I think it's to better support someone in finding logins from which to choose what to omit/include individually from import. But I want to better understand the intent here and how that impacts other areas of the app where we don't (yet) provide sorting options. And if that starts to favor the use case of managing logins (eg picking and choosing logins to omit/include) over importing and completing the onboarding flow.
3. is this a scrolling list?
4. are we providing indication that import is happening assuming it takes a bit of time?
5. what happens if the import fails for some reason?

Next up:

• [x] @changecourse to follow up on questions
• [ ] content review of the page that launches you into the FxA flow
• [x] engineering review to determine feasibility & scoping (engineering stories)
• [ ] user research review to make sure there is alignment to the provided recommendations
• [ ] product sign off on the acceptance criteria

I'd like to see this include sorting by username to see if that's something that would help users sort through sensitive/non-sensitive accounts.

@changecourse @sandysage see https://github.com/mozilla-lockbox/lockbox-extension/issues/534#issuecomment-367502065 for questions/concerns that need resolution before engineering can scope.

Addressing your questions @sandysage...

Does this design scale in the future if we want to allow users to import from other locations?

Yes, I believe so... If in the future we support additional import streams, there will need to be a selection made prior to seeing the login table... but this can still be handled within the existing import flow during onboarding as it is currently envisioned... it'll just add one additional step.

What does the sort functionality provide the user in the import process?

There's an inherent value in allowing sort for this potentially long set of data so that the user can choose what to include based on time (last used) so they bring in entries that represent logins they actually use... Whether or not we allow someone the functionality of sorting these columns or not is probably not the most important... I'm just posing that we display this list with a default sort of most recently used first... Then we can decide later if someone needs more functionality available as part of deciding what to import...

is this a scrolling list?

Yes.

are we providing indication that import is happening assuming it takes a bit of time?

If needed.... also a consideration for the "security theater" issue, and to be covered in the final step of the onboarding flow, if time is required for this import. (or if we wish to fake that time is required in order to elicit trust)

What happens if the import fails for some reason?

I'd need to understand from @linuxwolf how and what would be possible to fail here in order to address this better.

Why are we providing the ability to selectively import logins? That's going to be a lot of extra effort for something I'm not sure people are going to need, at least not for an initial version.

@jimporter That's a fair point. The quick discussion with @changecourse today suggested we'd like to think about this as the various chunks to get towards this ideal state. ie: first is import ability, second is make it per-item selectable, third would be make it re-usable (can someone come back and access this after they started?) and what those rough efforts would require so we and @sandysage can make a final decision on what's must-have.

Also, it sounds like "meta" contains not just last used but a few other dimensions to sort on, in case its useful (first used, last used, number of times used).

To expand on @devinreams note, we took the approach of designing the ideal state knowing that there would be coordination with engineering to scope the feasibility. The goal here was to start looking at things holistically - where in the flow do users get to the feature, how do they leverage it and realize value, and where does the user go next.

The product initiative #455 has the acceptance criteria more explicitly defined with:

• Import method should be part of a user's first run experience
• There should be a single clear call to action for import
• Import should be optional
• Users should have visibility into all available logins being imported

It is worth noting that the revised, streamlined (all or nothing) import method accounts for the first 3 bullet points, but not the fourth (unless we want to have a callout that presents available logins via Preferences > Privacy & Security > Saved Logins)

Are we able to provide an internal hyperlink to this from within our onboarding experience?

Original Design:

Revised Design:

@changecourse if addressing the fourth bullet point–and an additional point which perhaps in implied by the fourth, which is some level of user control over what gets imported–have you considered an import flow that uses progressive disclosure?

I have... an 'option 3' could essentially provide 4 choices in the form of radio buttons to the user for import options:

What would you like to import?

• ALL saved logins (selected by default)
• Saved logins from the past 30 days (hypothesizing that this grabs the most frequently used accounts)
• Let me choose (invokes more control via the table shown in option 1 above)
• Do not import any logins

Some of the options require more visibility into both the logins available for import, as well as the control of which logins to specifically import... We also need to decide whether or not we only support Import as part of first run onboarding, in order to mitigate the potential for duplicitive entries being added to Lockbox (which would require more robust support for things like batch delete, etc.)

Are we able to provide an internal hyperlink to this from within our onboarding experience?

@changecourse In an effort not to remove users from the import process at this stage, let's just capture that the product needs to provide visibility into all available logins being imported. But we'll circle back to that when we find that becomes critical to success (eg all our users are dropping off at import)

if addressing the fourth bullet point–and an additional point which perhaps in implied by the fourth, which is some level of user control over what gets imported

@hmcgaw That's really interesting. I was looking at this requirement from the overwhelming password problem where people maybe don't realize how many online accounts they have, and have saved in the browser. My hypothesis being that providing visibility into that unseen problem = more value in login management.

That said, I realize that's opening pandora's box at this stage: switching login management to be the focus and not getting into and using the product.

What would you like to import?

I like this idea, but let's try it first as a survey, versus building all these capabilities. Let's discuss it when we discover that import is the highest barrier to adoption.

@jimporter @devinreams @linuxwolf What, if any, open questions do you have from a feasibility standpoint? Are we able to take this, with the feasibility discussion last week, and determine the engineering scope of work (ie the GitHub issues we would create from this to build import) with relative sizes?

@sandysage asking the question “what do you want to import” is a survey isn’t going to get back useful data, but there are things we can do in research that can inform that question. As a rule of thumb in research asking people directly what they want or if they would or wouldn’t use a product is avoided; there’s a lot of research that shows that people aren’t accurately able to predict their future behavior.

There are some stages approaches that you could consider for exploring the import experience. For example if you’re implementing the revised design I recommend you run a qualitative study to understand what the users needs and here and where the experience is and isn’t supporting that.

Here's how I plan on dividing this up. The following is intentionally brief, but I'll add more details when we settle on things and file issues for each bit:

1. Dummy UI (anyone can work on this)
   • All we need here is the most-basic possible UI that lets users optionally import their logins from Firefox
   • At this point, there's no need for anything fancy, like detecting if the user even has logins saved in Firefox
2. Simple import (run in parallel with (1))
   • Most of this is just setting up the appropriate message passing to get the passwords out of XPCOM
   • We should have some discussion about what metadata we care about here (e.g. should we log that an item was imported? should the creation/modification dates be the date of the import? etc)
3. (If needed) Better UI
   • This could be rolled into (1) depending on how much work it'll be to make a fancy new first-run wizard

Most of this is just setting up the appropriate message passing to get the passwords out of XPCOM

Have we talked recently with the WebExtensions team on what state the (formerly?) defunct Logins API is at?

We should have some discussion about what metadata we care about here (e.g. should we log that an item was imported? should the creation/modification dates be the date of the import? etc)

See "From Firefox Logins" for what has been previously discussed.

Further, what changes may be necessary/beneficial from other components (e.g., datastore)?