Working interactive prototype here:
https://deploy-preview-1723–reporter-beaver-73821.netlify.com
Note: This prototype is visual and UX only, it does not actually change the Gaia hub.
Screens that were added to the onboarding flow:
3 Likes
Nice, I think this works well and is pretty straightforward. I think at somepoint it would make sense to include some kind of documentation links here to help people understand what gaia hubs are, and how to deploy them (eg when we have a one-click deploy ready)
Cool. Love that everyone is excited about this change. And love the rapid prototype.
Would like to explore variety of UX options, including one that add zero extra steps assuming the user goes with the default option.
We know that adding a step will decrease our throughput. And we know from perviously having this step in the flow that every users ever observed was confused by this step/option. We’ve put a ton of time and energy into reducing steps that users must take — seems like a poor trade-off to add steps we know 99% of new users won’t understand.
The heading should emphasize the option the user is configuring, a storage provider. As it stands, the language is geared to explaining Gaia. Changing the language will reinforce what the user sees later STORAGE PROVIDERS in the browser settings:
The underlying implementation is GAIA, there is no reason the user needs to understand that GAIA technology is the underlying tech is there? I mean, in the future couldn’t someone implement an entirely different storage system?
1 Like
If we’re going to add an on-boarding step, I see this step as a not only adding functionality but also of education. For it to be successful users - even ones that choose the default - should understand that in Blockstack apps, they tell apps where to store their data. Without an understanding of the context of the decision, users have no way to choose between the two options.
I share Jeff’s skepticism that we’re going to solve this in the context of the initial onboarding flow given our past experience.
–
Given a way to migrate data from one hub to another, one thing that could be done is to have steps for an on-boarded to complete to “take ownership of their data.”
Since we don’t have a way to migrate at the moment and are constrained by the requirement that we have to send an update transaction to set the gaia hub at name creation, another thing to consider is some sort of “advanced” mode that an educated user could opt in to.
@yukan This is fantastic! Thanks for pulling it together so quickly. Functionally this seems just right for collecting the custom hub URL for those who don’t want to opt for the default hub.
I agree with @jeffd that we ought to explore at least one option that doesn’t add another step. However, my intuition here is that adding an extra step is probably worth the possible step-conversion cost since we could get a boost in education and overall “trained user” conversion (per @larry’s point).
This is, of course, something we should be able to test, assuming our ultimate goal is the % of trained users that finish onboarding. Does a higher % result from the extra step even if the overall % of users (properly trained or otherwise) is lower?
As far as creating a variant that doesn’t create an extra step, the options for where to put a small, advanced “Set your own Gaia hub URL” option aren’t obvious since the previous screen to this one is for password collection and the next for email collection. Of course, I’d like to get rid of both of those screens 
I’m curious who may have ideas on where to shoehorn an option like this onto an existing screen / modal.
Per @moxiegirl’s point, I do suspect that hitting the user up with “Gaia hub” as a term right off the bat is going to generate confusion. But of course, if the functional goal is to collect a Gaia hub URL, we have to introduce that in the form at the very least.
Perhaps the initial header can be something non-object oriented (aka not about Gaia hubs nor storage providers) but rather “Choose where to store your data”. And the supporting text: “Blockstack empowers you to control your data by choosing the storage provider of your choice. All apps you use with your Blockstack ID will store your data 100% encrypted with that provider instead of their own servers.”
And the options could be three-fold:
- Use default storage provided by Blockstack (in purple)
- I want to learn about custom storage (linking to our new documentation about one-click deploys)
- I already have a Gaia hub URL (linking to the secondary form mode that says “Enter custom Gaia hub URL”)
That secondary form could then have a paragraph saying “A custom storage provider can be connected to your account using a Gaia hub URL. Learn more about Gaia hubs.” (with that last bit also linked to the documentation)
Finally, we should create a variation that addresses the case in which the app provider itself pre-sets a Gaia hub URL (such as will be the case with Graphite and its corporate customers).
Perhaps the simple change there is to list these three options on the main modal?
- Use default storage provided by Graphite (in purple)
- Use default storage provided by Blockstack
- I want to use different storage (linking to the secondary form mode that says “Enter custom Gaia hub URL” and also links to the documentation for those who need to learn)
In the future, we’re probably going to want to list storage providers on a modal like this straight up to make abundantly clear what we mean by “storage providers” (eg "Choose between Dropbox, Amazon S3, Azure, etc). But I don’t think we’re nearly there yet on several fronts of design and development.
1 Like
If I want to explain this to my grand father it sounds complicated.
Something more like: “Choose a place for all your data (Gaia Hub)”
Also, I like @markmhendrickson three options .
This makes the whole onboarding a 4 step wizard. It would be nice to see the progress bar with some icons for
- id
- security
- database
- backup
2 Likes
+1 to the onboarding progress indicator!
Everyone raises good points about UX, but it’s important to make sure that any decisions in favor of UX do not eliminate or mitigate the key value proposition of Blockstack. Better UX ≠ removal or limitation of decentralization features (not that I think anyone is proposing that, but I do think that’s part of why user-selected storage went away originally).
That said, I know there are ways to make the onboarding experience great without compromise. You guys have been proving that over the last 6 months.
1 Like
And we know from perviously having this step in the flow that every users ever observed was confused by this step/option.
Did we have this step in 2017? And did we have PBC storage as a default option then?
Want to make sure we have all have the same baseline knowledge on this. @larry and @yukan believe you worked on V1 of onboarding, please correct me.
- Browser was first shipped with a Gaia storage option in the onboarding in Oct 2017. It had the default option, and a link which displayed some information about setting up / using your own hub. Here it is:
-
When I joined in Feb, the first thing I did was user test onboarding. Three tech-savvy users. Three engineers. All 6 people expressed complete confusion towards this step. Didn’t understand the choice. Didn’t understand the implication. Didn’t understand the value. My conclusion from that was:
- 100% of users are confused by this choice.
- 100% of users didn’t get any value from this choice.
- 100% didn’t understand enough to take additional action or get additional value.
- We need better, easier storage options.
- Gaia storage selection should probably not be in the onboarding.
-
From Feb–May we worked on improving the onboarding designs and metrics. We decided to remove that step due to the findings above. The new onboarding shipped in May. To my knowledge:
- 0 users have complained or contacted support about the removal.
-
The only request we have is from app devs requesting this capability (not in boarding, just the capability to choose). I won’t go into specifics but the estimate is about ~1.5% of new IDs last month. We’ve only heard from a couple devs so maybe it could be more, it could also be much less. We don’t really know.
-
I’m open to any solution provided it stands up against basic logic and user testing. And I agree that this is a core value we need to deliver in Blockstack apps, but there are many paths to get there and we need to be flexible and thoughtful. Please keep the above in mind.
1 Like
Thanks for the context, super helpful. And I can understand that removing the step completely must have led to greater registration conversion. Did we measure the drop-off rate at this step before we removed it by chance? That might help to size up the downside risk at play here.
I think it is yet to be seen whether a variant of this screen can result in better usability testing results or live conversion rates (to simple or “educated” registration) than those in February. Perhaps I’m over-optimistic we can move the needle here, but I’m certainly a proponent of trying even if it just means throwing some new mockups in front of people in similar usability tests.
Also I’m not sure why we’d get complaints about its removal if only previously registered users could have noticed the change and they wouldn’t have reason to go through the flow again?
I presume few users sign up expecting this step, having been primed on Blockstack’s mission. So it seems more of a silent opportunity cost to education and value delivery to me (for those users who would potentially appreciate distributed storage and notice its presence here alongside the marketing language used by apps).
Is it possible to separate “user education” (which is imp) from this particular on-boarding step (where we have some data showing that it was confusing) i.e., the user education can happen in other ways.
At the very least, we’ll need to test and get more data before a live release with the new step. Great to see this discussion to evaluate options.
Upon further discussion with the team, it seems most prudent to release this new functionality as an option for developers, exercised upon sending users through the onboarding flow.
That way, developers can not only choose exactly what flavor of functionality they want to implement; we can also avoid any collateral damage from rolling this out on a platform-wide basis without having conducted usability tests, etc.
I’ve created the following Figma with that in mind: https://www.figma.com/file/LyKJOC39BnKZW0LcovWQW9/Blockstack-Browser-Onboarding-Copy?node-id=320%3A1666
The designs represent two new scenarios initiated by two new optional parameters for the redirectToSignIn method:
-
recommendedGaiaHubUrl(string) -
solicitGaiaHubUrl(bool)
1. Recommended Gaia Hub URL scenario
This scenario is for developers who want to recommend a single Gaia hub for all their users or create specific onboarding funnels / faucets for corporate or other special user groups that want to use specific Gaia hubs.
If a developer provides a string for the recommendedGaiaHubUrl parameter, the following screen gets injected into the flow right after the password screen:
The recommended URL value is shown on this screen, and the user can opt to apply it to their new account, use with Blockstack PBC’s provider / hub, or use a different one.
If they opt for a different one, they’re taken to this screen:
This screen is akin to Ken’s above in that it simply collects a Gaia hub URL and links to documentation about hubs.
2. Solicit Gaia Hub URL scenario
This scenario is for developers who don’t want to recommend a Gaia hub URL but do want their users to have the option to set their own.
If a developer sets solicitGaiaHubUrl to true, the following screen gets injected right after the password screen:
If the user selects a different provider, they’re taken to the same subsequent screen as in the first scenario to provide a Gaia hub URL. But otherwise they select Blockstack’s provider and keep moving through the funnel as normal.
We may find that these steps reduce conversion rates or fail to educate users about data storage effectively. But since they’d get enabled selectively by developers, we’d give developers a chance to dive in head-first while acknowledging those risks – sooner rather than later.
And we could learn as we go with them, by measuring conversion rates in the wild, gathering qualitative feedback from their customers, and performing our own usability tests.
Thoughts? Feedback?
2 Likes
I love this. Would this be available for configuration after initial onboarding as well, or is this first implementation targeted at initial onboarding only?
The idea is to implement for initial onboarding to start, then later add configuration for post-onboarding once we have a system in place for data migration (or at least plan for how to warn users that they’ll leave their data behind if they configure a new Gaia hub).
1 Like
Thanks for putting this together @markmhendrickson! Looks great! One slight tweak I’d recommend: it’s not guaranteed that your data will be 100% encrypted, since users can opt to share data publicly. We might need to iterate a bit on the wording, but other than that, I really like the concept!
True! I didn’t think about that. Would adding the word before data (e.g. “All apps you use with your Blockstack ID will store your private data 100% encrypted…”) address that sufficiently? Or best to further rework?
We could also drop the mention of encryption entirely, just thought that may be a bonus educational moment.
Directly from the gaia documentation on github:
“the authentication process gives the application the URL of a Gaia hub, which performs writes on behalf of that user. The Gaia hub authenticates writes to a location by requiring a valid authentication token, generated by a private key authorized to write at that location.”
" A gaia storage hub will store the written data exactly as given. This means that the storage hub does not provide many different kinds of guarantees about the data. It does not ensure that data is validly formatted, contains valid signatures, or is encrypted. Rather, the design philosophy is that these concerns are client-side concerns. Client libraries (such as blockstack.js ) are capable of providing these guarantees, and we use a liberal definition of the end-to-end principle to guide this design decision."
I think we need to be careful about wording that is not quoted from the technical specification in the gaia docs. We are promising that there will be a validation of data writes per the gaia auth scheme.
and specifically, that it “does not ensure that data is validly formatted, contains valid signatures, or is encrypted” from above. The data itself is not encrypted but stored “as is”.
A counter example is an encrypted harddrive, where if someone gained access to the physical harddrive and tried to read the contents of it it would be stored in an encrypted manner. gaia provides a protocol to access the data stored as is and some methods to recall and retrieve the data in certain ways.
The developers could provide a mechanism by which the data is encrypted when writing to the authenticated gaia hub as a separate but out of scope of the gaia tech spec (as current) spec.
How we present this information in static context in the onboarding flow is an interesting discussion and something I am paying attention to in the forum but not what I am working on right now. I am just doing the technical implementation right now.
When we have a first front end to technical implementation flow of usage, we can consider technical iterations based on any change we want to make in our default config but I think for the first iteration we just need to be clear about what we are not providing just as much as what we are providing.
This is alot of education for a first time user. I get Jeff’s concerns. Thinking from a blocker standpoint, it seems the issue here is the lack of a migration feature that would allow the average user to just sign on without more configuration options and thus education on those options.
Potentially migrations and an interactive tutorial on the users profile about what configuration options they have, one being to migrate their gaia hub (and why etc) would be a great future goal to have, but it is clearly far out from where we are right now.
This is a really good point.
Question on this for @jehunter5811. Your specific users who need/expect this feature – I assume they already have Blockstack IDs and dozens of documents in Graphite? Would you expect to manually migrate them or ask them to create new IDs?