Add starting point for the console overview page

[kschiffer]

Summary

The console needs a simple page for the overview route. We can make a start by showing the application and gateway tables there.

Why do we need this?

Basic functionality.

What is already there? What do you see now?

• Quite outdated screen design, that however shows the general idea of what the overview page could offer
• Application and Gateway table components

What is missing? What do you want to see?

An overview page that shows both the application and gateway table (with less columns) next to each other.

Environment

Console.

How do you propose to implement this?

Trivial.

Can you do this yourself and submit a Pull Request?

Yes. Thoughts also welcome.

[kschiffer]

After discussions with @wienke and @htdvisser this morning, it became apparent that we might want to try a little different approach for the overview page. Basically, we want to work more with visuals, icons, and whitespace, to generate more of a delightful, welcoming experience.

I've built a rough wireframe of what @wienke and I agreed on following up the discussion.

(Please disregard the outdated navbar)

@johanstokking @htdvisser, would you have any issue with building the overview page like this? I think it makes sense to do like this already for the initial overview page, as technically it would be pretty straightforward to build it this way (mostly an html/css job).

[kschiffer]

As a second step, we could apply a small chart that will show the number of received packages over time (fetched via the event stream) for all the apps/gateways that the users have. This chart would be displayed in place of the first section, as soon as the user has more than one app/gateway.
This would give the user an immediate insight into the activity of his/her entities.

[htdvisser]

I like it.

• Not sure about "Register a XXX", maybe "Manage XXXs"
• Perhaps the "Status" section fits better above the "Learn" section
• For the IS/GS/NS/AS/JS (we usually have them in that order) I'd also show the address (host). I think that in the future it would be nice to have a connection status (health check) in addition to the "enabled".

---

Live activity charts can be nice, but those could become pretty expensive (both on the server side and the clients side) if it means subscribing to event streams that could potentially receive hundreds of events per second if you have a dozen of gateways and a couple hundred devices.

[johanstokking]

First impression;

• People are not registering gateways and creating applications every day; I would just put names there as links to the pages. Or is this only when there are no gateways and applications respectively?

• As for the documentation; that's good to have, but this should be the TTN Stack documentation and not what's on www.thethingsnetwork.org/docs. We will reorganize those docs to be more tailored about The Things Network in general and provide links to the Stack documentation. The Console is Stack only. In fact, in offline scenarios, the Stack will self-host the docs so that's all we have then

• Component statuses; how are you going to do that? Do we need health check endpoints?

• So the version shown is the current version? I think that's good. Version check is going to be a bit more complicated as we discussed offline

• Activity we don't have in open source and we should not have unscalable alternatives there

[kschiffer]

Perhaps the "Status" section fits better above the "Learn" section

Sort of agree, but it's tricky. First time users will be more interested in docs; power users in the status section… @wienke suggested focussing more on first-time users in the overview page.

For the IS/GS/NS/AS/JS (we usually have them in that order)

👍

I'd also show the address (host)

Would likely break the lean layout shown in the WF. Will take another look at that.

I think that in the future it would be nice to have a connection status (health check) in addition to the "enabled".

👍

---

Or is this only when there are no gateways and applications respectively?

Yeah, forgot to explain that. The top section is meant as Blank Slate, so it is what is shown when no apps or gateways have been created yet. If that is not the case, we can, for now, simply change the label to "My Gateways" / "My Applications" and link to /applications / /gateways instead and later on provide a table/list with bookmarked entities.

As for the documentation; that's good to have, but this should be the TTN Stack documentation

So what to do here for now? The new docs are not online anywhere yet, are they?

Component statuses; how are you going to do that? Do we need health check endpoints?

For now only echoing whether the component is enabled, which the backend already passes to the console. Health checks would definitely nice, but that's goldplating atm.

So the version shown is the current version? I think that's good. […] Version check is going to be a bit more complicated as we discussed offline

Yes, will make an issue for that. ⟶ https://github.com/TheThingsIndustries/lorawan-stack/issues/1681

Activity we don't have in open source and we should not have unscalable alternatives there

I see. It was really meant as a small widget, basically similar to the event widget, but plotting the package events on a chart.

[johanstokking]

So what to do here for now? The new docs are not online anywhere yet, are they?

On the next release they should be. Let's not spend time on an intermediary solution as that is too short-lived.

I see. It was really meant as a small widget, basically similar to the event widget, but plotting the package events on a chart.

Yeah I don't think it's safe to subscribe to all traffic events from all gateways and all applications.

---

Rest is OK!