-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored Onboarding #223
Conversation
single-stage wizard with more focus on the setup code
German translation is mostly still missing, but we should agree on the English labels first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would love to test this, but I can't get past the following error with a fresh installation:
Fetching data failed
Cannot read properties of undefined (reading 'publicKey')
The error occurs here:
Console log:
Retrieving setup information failed. TypeError: Cannot read properties of undefined (reading 'publicKey')
at BrowserKeys.id (crypto.ts:491:89)
at fetchData (InitialSetup.vue:221:41)
I guess we need some "create or load" logic here... Looking into it tomorrow! |
[build image]
I looked at it from UX side (no real code review). What came to my mind is:
Also, what do you think about a redirect to the user profile page after onboarding? That way the user also finds the account key. |
Can be a follow-up PR. Keep in mind that other than a recovery key, the account key can be changed any time. Not sure if a print-out is the best storage option. Instead it would be nice to optimize the page for password managers to pick up the password and offer to store it?
I'm still looking for a completely different iconography here. Ideally, we should put the focus on "what the setup code is used for". Maybe we can add some illustration of various devices and change the text to something like: You need your Account Key to authorize access to your account from other browsers, apps or devices. You can see a list of authorized devices on your profile page. This browser will appear under the name
Experience tells me that there is a maximum amount of text that users can handle before they switch to a "just click next" behaviour. In order to split up all relevant information into digestible chunks, I decided to use the space above the setup code to explain WHAT it is and the part below to explain its PURPOSE. "Hi, this is a Plumbus. [picture] It can be used for ..."
Since we want to put the focus purely on the account key (as per feedback from usability tests with the old form), it was my intention to find a balance between completely hiding this feature and still offering users looking for it a way to easily recognize it. I tried underline before but imo it was too much. So I deemed monospace + pen icon sufficient. But this calls for another round of usability testing, specifically asking users to rename their browser during initial setup.
Yes, probably a good idea. |
Looks good! My thoughts:
|
Is this intentional that you're moving away from the "device" wording? It has somehow been replaced with "app" (e.g., other apps or authorized apps). On the profile page, the heading is "Authorized Devices and Browsers". Do you think that "Authorized Apps and Browsers" makes more sense? I actually like the first sentence with "every user gets a unique ...". It's short and gives you a broader context that you're not the only one. |
I'm still experimenting with the wording. "Device" was great when it was reasonable to assume there will only ever be one app (namely the Cryptomator app) per device. When we added browsers, this concept crumbles. Let's assume we stick with "device", a user might name their browser "MacBook". Later, when attempting to add the desktop app, they may run into naming conflicts. And yes, if we agree on a good name, we should rename it in all places (but maybe keep the device-based name presets in the Cryptomator apps). |
…diting, maintained layout consistency
Some questions on the open tasks:
You added
I'm inclined to remove the constraint. What do you think?
I'm against this. Users should be redirected to the "main" page after setup so that they can get familiar with managing vaults. If we find out that users are still confused by the account key after this refactoring, we can discuss this further. |
iirc, the beforeEnter caused overhead on every single routing event. But there is lots of potential for improvement here (i.e. keeping certain user-related state in-memory).
I agree. @infeo opposed, maybe he can add some arguments? 😉
ack |
Not technically. It is just the feeling, as a user looking at my devices, i could see several entries named "Browser XY". But we have for distinction the creation date, right? If so, we can drop it imho. |
In my opinion, we need more device metadata for better distinction (e.g., last access date, last IP address, operating system). But yeah, then let's remove the name constraint and think about this later. |
# Conflicts: # frontend/src/common/crypto.ts # frontend/src/i18n/de-DE.json
# Conflicts: # frontend/src/components/SetupUserKey.vue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't merge yet, found some bugs I'm currently fixing, see e.g.
Screencast.from.2023-10-30.14-48-35.webm
* we need to load the user with it's devices * recovering the key must always be done if the device id is not known to Hub
This updates the "setup" wizard, following feedback from usability tests. It is now a single stage wizard emphasizing the importance of the setup code.
While it still allows changing the browser name, it applies a sensible default based on the user agent string:
hub/frontend/src/components/InitialSetup.vue
Lines 181 to 191 in e5812bc
Furthermore it introduces a checkbox to raise more awareness of the significance of the setup code.
All labels are still WiP, most notably the
setupCode = 'Account Key'
. We're still looking for a good phrase which satisfies these requirements:This also fixes an "invalid state" where the browser still has a key pair but got deleted from the user's profile. Re-authorizing the same browser does now work again.
Tasks
/app/setup
despite the browser already being set up