search

cryptomator / hub

Cryptomator Hub helps you manage vaults in large teams
GNU Affero General Public License v3.0
36 stars 8 forks source link

Refactored Onboarding #223

Closed overheadhunter closed 8 months ago

overheadhunter commented 10 months ago

This updates the "setup" wizard, following feedback from usability tests. It is now a single stage wizard emphasizing the importance of the setup code.

Bildschirmfoto 2023-08-21 um 17 26 15

While it still allows changing the browser name, it applies a sensible default based on the user agent string:

https://github.com/cryptomator/hub/blob/e5812bc5b0b94669330f8fd46ef4df9e9b5c5b80/frontend/src/components/InitialSetup.vue#L181-L191

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
- [x] one can still open `/app/setup` despite the browser already being set up
- [x] remove unique constraint for device names
- [x] add "not you? change user" link
overheadhunter commented 10 months ago

German translation is mostly still missing, but we should agree on the English labels first.

overheadhunter commented 10 months ago

Cannot read properties of undefined

I guess we need some "create or load" logic here... Looking into it tomorrow!

infeo commented 10 months ago

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.

overheadhunter commented 10 months ago

I looked at it from UX side (no real code review). What came to my mind is:

  • Print button for 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?

  • If there is a warning sign, it should also be a warning color imho. Either

    • replace by info sign
    • change color

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 Chrome :pen:.

  • first paragraph should be shortened:

This is your first login to Hub. We created your personal Account key: [KEY] Bla bla store it safely...

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 ..."

  • Maybe underline the Browsername to let the users notice its clickable?

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.

Also, what do you think about a redirect to the user profile page after onboarding? That way the user also finds the account key.

Yes, probably a good idea.

overheadhunter commented 10 months ago

Next revision, breaking the text down in even smaller chunks of information:

Bildschirmfoto 2023-08-30 um 16 36 07
infeo commented 10 months ago

ilikeit

Looks good! My thoughts:

tobihagemann commented 10 months ago

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.

overheadhunter commented 10 months ago

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'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).

tobihagemann commented 10 months ago

Some questions on the open tasks:

one can still open /app/setup despite the browser already being set up

You added // TODO: move "already set up" case to setup component. Is there any reason why we shouldn't solve this like before, using a beforeEnter?

if we keep the unique constraint for device names, we need a proper error text

I'm inclined to remove the constraint. What do you think?

redirect to profile?

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.

overheadhunter commented 10 months ago

one can still open /app/setup despite the browser already being set up

You added // TODO: move "already set up" case to setup component. Is there any reason why we shouldn't solve this like before, using a beforeEnter?

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).

if we keep the unique constraint for device names, we need a proper error text

I'm inclined to remove the constraint. What do you think?

I agree. @infeo opposed, maybe he can add some arguments? 😉

redirect to profile?

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.

ack

infeo commented 10 months ago

I agree. @infeo opposed, maybe he can add some arguments? 😉

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.

tobihagemann commented 10 months ago

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.

SailReal commented 8 months ago

Before I adjust this, what do you think, but IMO the "register first device" screen and the "register another device" screen should look more similar?