Minor layout, styling and text improvements

[johanstokking]

Summary

Minor layout, style and text improvements for the Console.

Why do we need this?

To make it even more awesome than it already is.

What do you want to see?

• Rename "Connected Devices" to "Devices". We can't claim they are "connected" (Change device table title #888)
• Add "connected" indicator to gateway list by checking GS connection stats (Add "connected" indicator to gateway list #1155)
• Increase page size from 5 to 10 (device list in application overview, table can be a bit more condensed) or 20 (list views of applications, devices and gateways) (Increase page size of entity tables to 20 #907)
• Use consistent Title Case, i.e. "Message _T_ype" in webhook config (Make form field text consistent across the console #1273)
• We need alphabetic sorting in lists by default (Rewrite membership queries #1054 / Improve Membership Handling #1107)
• Move API key name to first column (Move API key name to first column #895)
• Make terms like "TTN Stack" configurable (currently used in things like "TTN Stack Console" and "TTN Stack Account"). We have the site names for this, right?

Can you do this yourself and submit a Pull Request?

Can review

[bafonins]

Increase page size from 5 to 10 (device list in application overview, table can be a bit more condensed) or 20 (list views of applications, devices and gateways)

There is the Devices entry in the side navigation with the list of devices (25 devices per page).

We need alphabetic sorting in lists by default

Shouldnt this be done by IS?

Use consistent Title Case, i.e. "Message _T_ype" in webhook config

Could you provide more context?

[bafonins]

Add "connected" indicator to gateway list by checking GS connection stats

and

Increase page size from 5 to 10 (device list in application overview, table can be a bit more condensed) or 20 (list views of applications, devices and gateways)

I can agree that showing the connection status for gateways is nice, however do we really want to make 5-20 calls to fetch the stats on every page change?

[johanstokking]

Increase page size from 5 to 10 (device list in application overview, table can be a bit more condensed) or 20 (list views of applications, devices and gateways)

There is the Devices entry in the side navigation with the list of devices (25 devices per page).

OK, but not the applications and gateways, see e.g.

We need alphabetic sorting in lists by default

Shouldnt this be done by IS?

Yeah it's the responsibility of where pagination happens, because we first need to sort before we can paginate. I don't think we should go as far as sorting by a selected column, but at least by one entity "primary" column (i.e. ID).

Add "connected" indicator to gateway list by checking GS connection stats

and

Increase page size from 5 to 10 (device list in application overview, table can be a bit more condensed) or 20 (list views of applications, devices and gateways)

I can agree that showing the connection status for gateways is nice, however do we really want to make 5-20 calls to fetch the stats on every page change?

Yeah I think so. These calls are cheap and we could optimize it later by grouping stats check per GS.

[bafonins]

OK, but not the applications and gateways, see e.g.

So, shall we increase page size for applications and gateways to 10? cc @kschiffer

[htdvisser]

I can look into sorting of those listings

[kschiffer]

OK, but not the applications and gateways, see e.g.

So, shall we increase page size for applications and gateways to 10? cc @kschiffer

Yes, I think 10 is a good default. Let's also use a unified constant for this.

[kschiffer]

Move API key name to first column

See my comment on improving the list display of api keys as a whole:

The ID value is very unhelpful IMO. I don't see any user scanning the table by a cryptic hash value. If we can, we should really sort by creation date or the name value. We might even consider making the name field mandatory, or setting default values like API Key 1, which I would recommend. We can then hide or at least abbreviate the ID field in the table view (that is, if there is no essential use of the ID value that I have missed).

If there's no objection I would like to solve it this way.

[htdvisser]

The ID is the middle part of the API key, so if a user has an API key, they can see the key's rights by finding that same ID in the list.

I would propose to leave things the way they are (so sort by ID) until we have #316 which allows us to sort by fields other than ID.

[johanstokking]

@kschiffer I think 10 is too little. The Console should be informative. If it doesn't fit, consider making the table more condense. I'd say at least 20 but maybe 25 or 30 items.

[kschiffer]

Please move this to #907.

[johanstokking]

Please address also replace hardcoded The Things Stack Account by {siteName} Account

[kschiffer]

Please address also replace hardcoded The Things Stack Account by {siteName} Account

via #1323

[kschiffer]

Closing in favor of actionable issues (see OP).