I had a look at the proposal and I like the compactness, but fear errors when data is entered. Unless you can validate input, I would personally go for separate fields for different port speeds to reduce errors and to keep is well-structured. Compact fields could then be computed/filled from the structured data to generate better views for users.
Outdoor devices
From looking at your device type list I think you would need to add an outdoor suffix to multiple categories: WiFi AP, Camera, Switch, Powerline Adapter
Outdoor often means that they are rated for harsh conditions e.g. sub-zero temperatures, some outdoor components still need to be put in an outdoor enclosure.
However, while there are specialized outdoor devices in those categories available, it does not mean that OpenWRT would ever support them.
I think it would be best to just add it via a separate data field “Outdoor” [yes|no]
IP Rating
Some devices can withstand water, others are just sealed off against dust. So depending on the location of the device you would require different ratings. The list of outdoor devices might however not be that long, so probably an IP rating field is not that important.
PoE
I just missed that one. Thanks for pointing it out!
I am in agreement with Noki that a separate Outdoor Y/N would be preferable. The IP Rating would be a bonus, but perhaps we should determine how many actual outdoor devices are supported first.
Red = additional fields, replacing the blue field; can be implemented quickly (just like I did today with the Outdoor field)
Yellow = SFP field needs to be added anyways; can be implemented quickly (just like I did today with the Outdoor field)
I like the compactness of the blue one: One column, easily searchable for e.g. 1G, 2.5G etc.
Needs more time to implement though (script needed to fill the field with the existing 100m + Gbit ports).
I'd be inclined to go the quick and dirty route for now and implement red and yellow, just to get thing going.
("Lieber mit Fehlern gestartet als perfekt gewartet.")
From a human-parseable standpoint: yes. But if you want to programmatically parse it into a device matrix/selector, it's very much the worst case.
Over the last few weeks, I've been (off and on) working on an easy-to-handle multi-dimensional filter matrix (akin to what geizhals does), and it's making good progress, possibly towards a christmas holiday release. But I'm still pulling my hair on how to parse the ant hill that is currently the "power supply" field without going insane:
I'd really hate the network interface field to become the same unordered, unsorted, unmaintainable freeform mess. I'd very much prefer lots of distinct fields with well-defined data, they can easily be consolidated for output later, the opposite is a lot of work at best, impossible at worst.
I guess what I'm saying is: If you have half a dozen fields for different port speeds, who cares really? They don't weigh down the database that much and one can make it into a human-readable string later. I would even advocate having "SFP ports" and "SFP+ ports" two separate fields, with purely numeric data. Basically avoid freeform entries where the data is quantifiable.
The new mock with fields for each port speed for ethernet and different SPF ports is perfect. Let's go with that one and try to autofill the compact format from that data.
Ancillary thought: Earlier this year I was looking for a supported 3x3 or 4x4 device, and it would have been damn handy to have it as a selection criterium. Should we/could we/do we want to have a field for the antenna configuration (i.e., 2x2, 3x3, 4x4) and if so, would we need a single one, or two, one for each of the Wifi bands?
I'm of same opinion. Have separate fields for the values. Once its in a table you can pull it and display it anyway you want. However if you have to pull a table and parse it, its harder to manage.
That's just semantics, they are equivalent. But there's also an "extended" format, "TxR:S" (because apparantly there's devices out there that do "3x3:2", i.e. 3 antennas but only 2 streams, or such nonsense). And I'm pretty sure we would be entering bikeshedding territory if we enumerate all possible TxR:S variants, especially since TxR can already go up to 8x8.
(Edit) It would probably make sense to have separate "2.4GHz MIMO" and "5GHz MIMO" fields, even if they usually do not differ. The Unifi AC LR for example does 3x3 MIMO on 2.4GHz, but 2x2 MIMO on 5GHz.
As for the name of the field, I don't really care. "Antenna configuration" sounds sensible since "MIMO" implies, well, MIMO (and "1x1" is not MIMO ). But "MIMO" is shorter and sweeter. Again, more input from someone who is not me please.
I'm inclined to simply follow what's out there on wikidevi and techinfodepot.
Name of datafield: MIMO (even if 1x1 technically isn't)
Options for datafield type -> to be decided
a) textbox (free text, TxR:S notation possible; easy copy&paste from wikidevi)
Downside: We will get mixed results, i.e. 2T2R, 2x2, 2x2:2
b) select (dropdown, predefined values, TxR notation)
Really nice, that we now have multi gigabit ports in tech data , but you renamed the column fĂĽr 1gbit ports from
"Ethernet Gbit ports_" to "Ethernet 1Gbit ports_"
All device pages now display an empty column for gigabit ports. Even the template is probably still using the old column name. How do we fix this? Search and replace over all device pages and adjusting the template?
Also I believe multi gigabit ports don't show up on device pages, yet.
Would it be possible to limit the template somehow so it only shows columns that have values in them instead of all columns from 100mbit/s ports to10gbit/s ports (or sfp) even when there are none?
Thanks for pointing it out!
, but you renamed the column fĂĽr 1gbit ports from