New end device registration flow (Console)

[kschiffer]

Summary

The plan of adding the device repository (#3433) and the progressive insight from our current device registration flow in the Console, as well as insights from user interviews, give us the means to rethink device registration as a whole.

(See all annotated wireframes here)

Why do we need this?

• Current end device registration flow is problematic
  • We use a staged disclosure (wizard pattern) which;
    • does not follow the users mental model of device registration
    • does not allow for quick review/verification of input from earlier stages
  • We overwhelm users with too many options, some of which are not relevant during device registration
  • We don't provide enough context and background on the form fields, making it hard for new users to do simple onboarding tasks
• We will add a new mode of device registration which is powered by the device repository (Integrate Device Repository #3433)
• We will however also keep supporting manual device registration, to allow for registration of devices which are not part of the DR

What is already there? What do you see now?

• Current device registration flow
• The new device repository and WIP on integrating it with TTS
• UX research findings around end device registration
• Specification of the new flow (wireframes)

What is missing? What do you want to see?

• Implementation of necessary API to retrieve device repository info (currently WIP via Integrate Device Repository #3433)
• Implementation of the new end device registration flow in the console, which entails two parts
  • Implementation of the new DR flow
  • Implementation of the new manual device registration flow

How do you propose to implement this?

Please see the wireframes here:
201124_end_device_creation_update.pdf

These should give a detailed plan on how the new flow is going to work. As you might have noticed, there are some overarching changes on how forms work, namely:

• We will retire the horizontal form layout and use the vertical layout throughout (label above field)
• We will remove most field descriptions and placeholders
• We will add tooltip toggles for all LoRaWAN fields and many other fields that need explanation for novice users
• We will move action buttons for fields outside the field and use a text label instead of icons

As such, these wireframes also reflect an overall change in our UX around forms, which I will also translate into actionable issues. However, none of these issues should block the implementation of this issue. E.g. the tooltips and new action button style can be added in parallel or afterward in separate PRs.

Since integrating the device repository has high priority, I suggest to implement this in two stages:

1. Implement the new flow using the device repository while keeping the current wizard flow as manual creation
2. Replace the wizard flow with the new manual creation flow

How do you propose to test this?

Once implemented, we should make sure that the flow is thoroughly tested by integration and smoke tests.

Can you do this yourself and submit a Pull Request?

The exact assignments need to be discussed still.

[bafonins]

Some comments on manual device creation:

What does auto text-select mean?

What exactly is happening here? As far as I understand the Add frequency button behaves the same way it does now?

>= LW 1.0.4

So this unblocks #2694 ?

[kschiffer]

What does auto text-select mean?

What I mean is that when the form has automatically generated a value, and the input gains focus, it will automatically select the input value, so the user can go right ahead and enter something different if he/she whishes to.

What exactly is happening here? As far as I understand the Add frequency button behaves the same way it does now?

Yes, the arrow is a bit misleading here. An entry is generated as shown in the wireframe when the user clicks + Add frequency. When clicking Add frequency plan frequencies, the form will add a range of entries corresponding to the frequencies of the currently selected frequency plan. When a frequency plan was not yet selected, the button should be disabled (but not hidden).

>= LW 1.0.4

Indeed.

So this unblocks #2694 ?

This issue encompasses solving #2694 for end devices too, yes. I will design an update for the gateway registration form as well which will include the same mechanic, but this is still in planning. Also, note that we will provide external component functionality only for the manual device creation (except for external join server configuration).

Another thing to note is that this issue does not encompass end device general settings. We will tackle this in different issues and it does not block each other. Generally, the plan is to keep what we have there right now structurally but introduce some UX improvements for individual fields to 1) streamline matching fields with the ones in the new registration form, and 2) introduce some general polish for some field mechanics.

[johanstokking]

@bafonins what is the status here?

[bafonins]

@johanstokking

I implemented the main features from this issue regarding end device creation from the lorawan device repository. ATM, the users are able to register end devices based on device repository templates and current UI matches the one provided in wireframes.
What is left:

1. Join server selection

This is manily because there is no functionality in the stack to specify the global join server as well as 3rd party join servers, see #2777 and #3770
2. refactoring the manual creation form according to mocks provided by @kschiffer. However, I do not consider this to be prio/medium since creation via the wizard allows the users to register custom end devices that are not in the device repository. I will come back to this issue to streamline the manual creation UI.

Please add the priority label if necessary.

[kschiffer]

The firmware and hardware version hints have been added via https://github.com/lorawan-schema/draft-devices/commit/4028c0a44da3a0276850f41275558c77275cf9c7 (see also TheThingsNetwork/lorawan-devices#74). So the hints can now be displayed in the Console as defined in the wireframes.

[kschiffer]

Closing this, since most functionality is now implemented. Tracking JS functionality in #3770