search

TheThingsNetwork / lorawan-stack

The Things Stack, an Open Source LoRaWAN Network Server
https://www.thethingsindustries.com/stack/
Apache License 2.0
983 stars 309 forks source link

Remove irrelevant fields in entity creation forms #2806

Closed kschiffer closed 3 years ago

kschiffer commented 4 years ago

Summary

Our entity creation forms (specifically Application, End Device, Gateway) are currently organized in a way to mirror all the options that can be set in their respective "General settings" forms. This strategy is not sustainable since we will increasingly overwhelm users options that are barely relevant at the point of the entity creation. Instead, we should focus on required and important fields, based on user stories, while leaving all advanced settings for the respective "General settings" forms.

Why do we need this?

There is consistent feedback now that creation forms confuse users since it displays a lot of options that are only relevant for advanced use cases but appear important since they are demanded during entity creation.

What is already there? What do you see now?

We already employ strategies like progressive disclosure and the wizard pattern for end device creation, which produces valuable results. This issue is about decreasing the cognitive load of our forms even more by avoiding some settings altogether since they are not important during entity creation.

What is missing? What do you want to see?

A carefully considered set of primary input fields that we use for entity creation, while moving the rest to the "General settings" form exclusively.

This is particularly relevant for the Gateway creation form. I suspect that things like "Schedule downlink late" or "Schedule any time delay" are not things that users typically care about setting during gateway creation. (I might be wrong though)

Environment

v3.8.4

How do you propose to implement this?

First, we need @laurensslats to go through the creation forms and take note about all input fields that are not important enough to be part of the creation form. Then, we should remove these fields from the forms.

How do you propose to test this?

Trivial.

Can you do this yourself and submit a Pull Request?

I can but need @laurensslats help first to determine the fields.

cc @bafonins

kschiffer commented 4 years ago

I want to make an initial proposal about which fields I deem to be superfluous in our entity creation forms:

Gateways

Applications

No changes required, however, we should hide Linking and Network Server Address behind a "Advanced settings" section

End devices

Organizations

No changes required.

I chose to be quite greedy with what to throw out in this proposal just as grounds for discussion. I think in the case of end devices, we don't need to be too greedy since the wizard already helps to make the process less overwhelming. Still, I want to make sure that we don't just add anything to the creation form just because we can.

When deciding what to throw out we should think of the common user story when creating an entity; meaning: What is really necessary to decide at the point of creating the entity and what can reasonably be decided later.

@laurensslats @htdvisser @johanstokking @bafonins would be great to have some feedback about this.

htdvisser commented 4 years ago

If we're talking about the bare minimum one-size-fits-80-percent settings, I think we can indeed leave out the fields you've mentioned.

For gateways, I think the default gateway server address is also fine for most use-cases.

For end devices, I think Class C support is nice to have.

The Home NetID, AS-ID and KEK labels are required when using an external join server, but can be omitted for cluster-local join servers. The "skip payload crypto" only makes sense with an external join server, but is not required.

I think the checkboxes for indicating that an end device resets nonces/counters should probably be hidden somewhere, we shouldn't be encouraging insecure behavior.

laurensslats commented 4 years ago

Gateways Adding 1 issues, which is the IMO the main issue

I would suggest to put all the below issues under Advanced settings

End devices

Suggesting to add all of this under Advanced settings

Skip payload crypto can be used when customers don't want TTI to decode the payload. Skip payload crypto in combination with our global join server, or with External Join Server is a good security enhancement.

kschiffer commented 4 years ago

@laurensslats this issue is not about which fields are clear or unclear, or what should be put into "Advanced settings". This issue is specifically about which fields can be stripped from the creation forms ("Add end device", "Add Applicaiton", "Add gateway"), because they are not relevant enough in the process of creating the entity.

Please let me know if you agree with the proposal from my other comment.

For other issues regarding the form UX, see #2813 and specifically #2664 for documentation strategy within the form.

kschiffer commented 3 years ago

Closing this in favor of upcoming actionable issues on individual forms.