luci
luci copied to clipboard
luci-app-dawn: Discussion on optimal table for presentation
The new implementation of luci-app-dawn in JavaScript in #6656 resulted is a discussion on what the best (table) format is to present the information. This issue is opened to discuss the various options.
In the current implementation, there are two table: network overview and hearing map.
Network overview The network overview starts from the perspective of a access-point-channel, list attributes of this, and lists the clients connected. The current implementation might not be ideal because it has a table inside a table. As a result the outer table is not sortable.
Access Point | Interface | MAC | Utilization | Frequency | HT | VHT | Clients | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ap1 | phy0-ap0 | 00:01:02:03:04:05 | 25.49% | 5.200 GHz (Channel: 40) | Available | Available |
|
||||||||||||
ap2 | phy0-ap0 | FF:09:08:07:06:AA | 2.83% | 5.200 GHz (Channel: 40) | Available | Available | No clients connected |
Hearing map The hearing map starts from the client perspective, and lists all the clients that are seen by the SSID, regardless which access points they are connected to. This also lists the access points, like the network overview. But if an access point doesn't hear any clients, it is not listed in the hearing map, unlike the network overview.
Client | Access Point | Frequency | HT | VHT | Signal | RCPI | RSNI | Connected to Network | Score |
---|---|---|---|---|---|---|---|---|---|
Laptop | ap1 | 5.200 GHz (Channel: 40) | Available | Available | -74 | -1 | -1 | Yes | 68 |
Phone | ap1 | 5.200 GHz (Channel: 40) | Available | Not available | -53 | -1 | -1 | Yes | 125 |
AB:99:88:77:00:AE | ap1 | 5.200 GHz (Channel: 40) | Available | Available | -86 | -1 | -1 | No | 116 |
Proposal 1: network overview The proposal from @micw for the network overview is to flatten the table and add a column for SSID. This would result in:
SSID | Access Point | Interface | MAC | Utilization | Frequency | HT | VHT | Client | HT | VHT | Signal |
---|---|---|---|---|---|---|---|---|---|---|---|
MyWiFi | ap1 | phy0-ap0 | 00:01:02:03:04:05 | 25.49% | 5.200 GHz (Channel: 40) | Available | Available | Laptop | Available | Available | -74 |
MyWiFi | ap1 | phy0-ap0 | 00:01:02:03:04:05 | 25.49% | 5.200 GHz (Channel: 40) | Available | Available | Phone | Available | Not available | -53 |
MyWiFi | ap2 | phy0-ap0 | FF:09:08:07:06:AA | 2.83% | 5.200 GHz (Channel: 40) | Available | Available | No clients connected |
There might be several problems with such a table:
- The first 8 columns are repeated many time, especially when there are many client connected to an AP. This might make things harder to read.
- Some columns refer to AP properties, while other refer to client properties. This might be difficult to communicate.
- Aggregate properties, like number of clients connected don't really make that much sense.
- The network overview and hearing map become quite alike, and only present the information from a different starting point (AP vs client)
If possible, it would be really good to be able to better convey the page when on a mobile device/small screen.
Just a thought: Although not quite responsive design, I feel like the below suggestion might make both desktop and mobile experience better:
If we can use accordion style columns with a toggle on not often required column, it would be fantastic. Looking at my own use of this app over the last couple of years, I think the information people would use most often that should always be shown would be "Access Point", "Frequency", and "Client" columns of the main table, as well as the "Client" and "Signal" columns of the nested table.
With all other columns defaulting to collapsed, this would significantly move the page's info "to the left" and reduce dead-space.
A secondary item which again may or may not be tied to above depending on implementation approach would be to "flip" the above to make the / a page from a client view. e.g. a single table (likely with accordion columns), which lists each client on the left side of the table, and the metrics side of the table shows info for the AP that the Client is connected to.
I know that I often in my testing of roaming try to see if the client is moving across APs, and it can be difficult (again on a mobile device) to easily see changes. This would significantly help with that, which is actually a major use case for people; Both on initial setup, but especially as they play with the DAWN and AP signal settings to get optimal roaming.
I think this can be done either as a toggle on the single page, or as a new page.
Presenting all information might be overwhelming, but it's never wrong.
luci would be nice to acquire the capability of configurable columns (ability to choose which columns display).
Table inside table indicates normalization was not done properly. Please avoid if possible.
We're in 2023, and we've had a generation to adapt to using icons and emoji. Use icons in place of words. They generally don't need translation.
SSID | Access Point | Interface | MAC | Utilization | Frequency | HT | VHT | Client | HT | VHT | Signal (dBm) |
---|---|---|---|---|---|---|---|---|---|---|---|
MyWiFi | ap1 | phy0-ap0 | 00:01:02:03:04:05 | 25.49% | 5.200 GHz (Channel: 40) | ✅ | ✅ | Laptop | ✅ | ✅ | -74 |
MyWiFi | ap1 | phy0-ap0 | 00:01:02:03:04:05 | 25.49% | 5.200 GHz (Channel: 40) | ✅ | ✅ | Phone | ✅ | ❌ | -53 |
MyWiFi | ap2 | phy0-ap0 | FF:09:08:07:06:AA | 2.83% | 5.200 GHz (Channel: 40) | ✅ | ✅ | - |
I question the wisdom of having multiple V/HT columns. They will require differentiating.
I also experimented a bit with the representation and ended up with 2 views.
One with an overview of all AP's for each SSID. I added the info about connected clients and 'heard' clients as a popup when hovering over the amount
For all connected clients and 'heard' clients on each SSID I opted for a different view. An icon indicates if they are connected or not, hovering the client name will popup more info (IP and MAC) You can not hide columns, but you can sort on each of them.
In my use-case this representation works fine.