No worries, I was actually talking about how I had indicated the status on the device page .

Why not use colour? E.g. 14.07. At the top of the list we could add a short explanation of conventions used? In my native language we call it 'legenda' (from the Latin: 'to be read', often provided with maps etc.).

Because it requires you to look up what colours mean, memorize what colours mean, be able to see colours, and be able to distinguish colours. On the web, colours are a great way of supporting information, but not of providing it.

I don't like colour either. Doesn't look good in the source code of the pages.

Update complete (910 devices).

It would be interesting to start harvesting the image links from the device pages, and integrating that information into my list... some work though.

I have suggested (14.07) before, using parenthesis to indicate limited support. I think it would be rather clear and intuitive what it means. But perhaps rather (a/b/n) than (14.07).

I'm wondering if we should do this now, or later, when the dataentry pages are created, i.e. enter the image-urls into the single pages. But thinking of this... well... why not integrating it directly into your list?
And while we're at it: Add
- First supported release
- Supported since (trunk) revision
- Current supported stable release

see also http://wiki.openwrt.org/toh/dataentry_t … try_values
Comments welcome!

Thanks for reminding, I almost forgot... getting old

Proposal: "() around a value indicate, that there are some issues or it might not work at all. See device page and/or forum for details."

Where else should we place '()' around?

(b/g/n) = wireless has performance/stability issues
(1x 2.0) = e.g. USB not working / not as stable as expected
(#LEDs) = e.g. not all LEDs are working as expected
(#Buttons) =  e.g. not all buttons are working as expected

Thoughts?

Looking mighty good. I certainly have no complaints.

Minor quibble: I'm not sure about the relevancy of the "Amount of LEDs" data entry, especially since there are models with lots of LEDs out there (9 is certainly not enough, a WD N750 for example has 16 including the individually adressable switch LEDs). Their number alone carries almost no bearing on anything.

Similarly about the buttons: The router hardware varies wildly, from simple switches to on/off switches to multi-GPIO sliders. I would even say that, if anything, this should be a freeform entry to carry any meaning: "Buttons: WPS, Reset, Mode Slider" would allow you to compare your model to the one described, "Buttons: 2" does not.

But both are certainly not showstoppers. I would just think they rather belong in the details section of the device pages, including ways of usage. Especially since

there are many of these cases which almost certainly require clarification.

I cleaned up the Flash column. Hope you like it better now. I tried to consistently use "512NAND" for NAND memory and "16" for NOR. But there are obviously cases where it is NAND but it does not say so.

How about this one: http://wiki.openwrt.org/toh/zyxel/zyxel_nbg6716
Listed under "Possible". Should it be "Supported"? Or some problems that are not clear?

tmo26... those () seems to be a good start.
I will think about the images some other time.

Just updated: https://dl.dropboxusercontent.com/u/906 … index.html

(Last edited by zo0ok on 6 May 2015, 21:09)

@admin: Wiki improvement suggestion

- Adjust width of wiki page editing window to allow fullscreen editing on 1920px wide monitors
The current restrictive setting and the resulting line breaks do not exactly help in editing.
Full width only neccessary in editing mode. Can there be done $something with CSS?

- Install dokuwiki plugin prettytables https://www.dokuwiki.org/plugin:prettytables
Note: Can be a great help in making tables readable in the source code. However, it has it's limits: Editing extremely wide tables does not lead to the desired effect. I use it myself to keep tables source code readable and easily editable.

Yeah! Looking much cleaner now. Good work!

On the formatting:
- 2,4,8 -> should we use spaces between (2, 4, 8)? I'm thinking of the data-plugins capability to allow for single/multiple entries. I'm not sure whether this requires spaces or not.

- 512NAND -> Should we put spaces between or put NAND in brackets? 512 (NAND)
-8+128NAND -> 8 + 128 (NAND) -> hmm.. what is this anyway? (8+128)NAND?
Yes, I know what it means, however... hm... thinking about it.
- 8192NAND+microSD -> 8192 (NAND) + microSD

Reason for spaces: Long cell content in tables with many columns leads to wiiiide tables, due to no possible linebreak.
Take a look at http://wiki.openwrt.org/toh/toh2 and imagine "AtherosAR1311" instead of "Atheros AR1311".
IMHO we should allow for some linebreaking possibilities.

Some minor issues with Wifi (mac must be entered in wifi config) and sysupgrade not implemented, but otherwise seems to function. Should be supported IMO.

Regarding "+" / "," / " " / "x" / "()" usage: take a look at the Wired Ports column:

4+1 GBit = (4+1) Gbit
1+4x Gbit
4x100+1xADSL
1 + 4x 100M
4+1 DSL
4+ADSL
4, 1 x ADSL
1x Gbit (ADSL/VDSL2) + 4x Gbit
1x Gbit (PoE)
1x Gbit PoE
10 (5x 100M, 5x Gbit)

Hmpf... quite a mixture.
I already tried to commonize where possible to "4x 100M" or "5x Gbit" (usage of 'x' and space).
Need to think about that. Tomorrow

@metai: Good points!

Updated: http://wiki.openwrt.org/toh/dataentry_t … try_values

Introduced also more sections for better structuring the information.

I don't have anything against spaces, even though I deleted them all. I believe the best would be to (consistently) use spaces around the + and after ,:
16 + microSD
8,16

Btw, I have consistently replaced / with , when it comes to meaning OR.

When it comes to the NAND thing... As I understand it NOR storage very rarely has errors and allow for some simple Flash filesystems, typically used with OpenWrt. NAND on the other hand usually has errors and (therefor?) works better with normal filesystems, like ext4. NOR are usually small (<32MB) while NAND are usually big (>32MB). I understand that anyone who wants to build support for a device, or someone who builds a custom image needs to know if it is NOR or NAND. But for the rest of us, who anyway mostly install prebuilt images from Stable (or trunk), we just focus on getting the right image. Of course, where I am going with this: should we eliminate NAND from the Flash column and make sure it is available in the device detail pages? NAND has anyway not been used consistently before, and there are definitely NAND devices that do not say NAND today.

(Last edited by zo0ok on 6 May 2015, 23:10)

My understanding is that in practice, for the user, it rarely matters. However, because NAND support in OpenWrt is quite recent, it mainly matters to developers going for support for a new device, but that is probably also irrelevant once support has been established. CMIIW.

I agree with this. If I were to count buttons on my router, I think it has a power button and a button to enable/disable wifi. Do these include in the count? Why? I suppose the original idea was to indicate if there were programmable buttons that could be scripted to do anything. I think there is such a button on the WRT54G. And the problem here is, if I dont know how to count buttons and what buttons that dont count, how are we going to get data quality in a "Buttons#" columns.

Regarding NAND: Is there a reason not to chose devices with NAND flash?

I'd vote for including it into the device page.

http://wiki.openwrt.org/meta/template_device#info -> Flash Size

Example:
Flash size / type (NAND/NOR): 8192kB NOR

Today instead on cleaning up, I played around a bit with the DIR-505 device page.
I implemented some usages of the information collected in the dataentry.

For a comparison of the full dataset vs. the original datatable vs. the new created datatable (only selected columns), see
http://wiki.openwrt.org/meta/playground … highlights

Installation makes use of the URLs provided in the dataentry:
http://wiki.openwrt.org/meta/playground … stallation

Or start directly at the beginning, under the page title:
http://wiki.openwrt.org/meta/playground

I like it, that you can re-use information multiple times in different places, even on different wikipages, with different formatting and all that stuff - once it is collected and entered into the dataentry.

Thoughts on this example?

(Last edited by tmo26 on 7 May 2015, 23:31)

Good! You have deserved it!

I think it seems good (your playground page), and the dataentry features look nice.
A template for device pages, with 1st things 1st is clearly important.
I have not decided what I, for myself, would like to find on top. I will think about it and get back.

A wacky thought:

I have always wanted the ToH to keep the header of a particular model's router visible at the top of the page while scrolling (until you get to the bottom of that table). This would make it easier to keep track of what's in each of the many, many columns in the ToH. See for example, http://borgboyone.github.io/jquery-ui-table/

I am *not* asking that we do this now. It's hardly vital to our quest to make excellent info available through the ToH. Nor am I recommending that we use that particular jquery-ui-table gizmo - I simply provide it as an example of what I want to see.

But since we're tweaking the form of the underlying <table> ... <thead> ... <tbody> structure, I want to ask if we have encoded enough information/tagging/etc into the automatically generated HTML to make the "fixed header/scrolling table body" possible in the future.

I agree, that's very handy, and it does not claim that much screen space.

I'd think it's easier for maintenance if the data entry stanza is included in the device page.

I moved this Zyxel to Supported, and I moved a few other Zyxels away from Supported.
List is now updated: https://dl.dropboxusercontent.com/u/906 … index.html

It seems, in the ToH, that I can scroll sideways. It has not always been like that for me. Well done, in case someone fixed it.

A terminology question: As I write about the improvements we are making, I am struggling with what to call the various important bits. It will help new people be more comfortable if we always use a single name for each concept going forward. I wonder about:

1. Table of Hardware vs Supported Devices vs ? We have been calling it the Table of Hardware, yet the wiki home page has a link to "Supported Devices".

2. Device Page vs Device Details vs Router Page vs ? The individual page that gives information specific to each router/model/etc.

3. Hardware Highlights vs dataset vs dataentry vs datatable vs Hardware Table vs Table created with data plugin By this, I mean the chunk of structured text where people who maintain the "Device Page" fill in the specific details. This item will be scanned to fill in the "ToH" automatically. 

4. Other names... Do we also need to come up with (separate) names for the various tables generated from that structured data? (@tmo26 has many examples at https://forum.openwrt.org/viewtopic.php … 20#p275620)

5. Anything else... ?

I have these preferences:

1. I like "Table of Hardware" as the public name.

2. I slightly prefer "Router Page" as the public name.

3. During development, I think we have called it the "dataentry", but that's exceedingly generic. I would prefer a more specific name, perhaps "routerdata" since it is relatively unique/searchable. It would also double as the public name - "Router Data" in the heading of the block

4. ?

5. ?

1) I like toh too. (and I also don't have a better proposal)
2) "Device page", since not all devices are routers.
3) "dataentry", since this creates a direct relation to how this is shown in the sourcecode. Easily recognizeable for the one who edits it. Not all devices are routers, hence "routerdata" doesn't always fit.

Reminder regarding placement of the dataentry: While it is absolutely possible to put the dataentry on the device page (top, bottom, somwhere inbetween: doesn't matter), I'd advise to put it on a separate page, possibly in a separate namespace (e.g. http://wiki.openwrt.org/hwdata).

Reasons:
3.1) Device pages sometimes describe several HW versions of a device, but only one dataentry section is allowed per page. You can add more than one, but only the last one will be the active one.
=> Different HW versions of a device need different pages with dataentries
=> Put dataentry on separate page, not on the device page
3.2) For tryouts and also final implementation, it's way easier to plug in a whole directory with dataentry pages (and maybe after tryout simply remove the complete directory again), instead of editing each device page and adding the dataentry block there.

4) The device template http://wiki.openwrt.org/meta/template_device calls this section "Hardware highlights"
It's good to name things. Makes finding things easier.
Another reason for naming those datatables: With "named" datatables, you can easily apply customized styling via CSS, see https://www.dokuwiki.org/plugin:data#cu … he_styling

Topic: Pictures of devices (general views of the outside of devices)

Where from do we get legally allowed and reliably (i.e. long term availability) pictures of devices?
Manufactures websites tend to change, poor long term availability.

Uh oh. I just realized that I have not been paying enough attention to be able to explain (to someone else) how this is all going to work.

1) What is the source of the original 'dataentry' (to use tmo26's terminology) for a particular device? Is it on the Device Page? Is it in the separate HTML page that zo0ok is maintaining?

2) Related question: If ManufacturerX releases their new WRT12345 router, who will create the dataentry? Will it be one of our team? Or will the person who ports OpenWrt to the WRT12345 router then be responsible for creating the Device Page, and thus the dataentry?

(Last edited by richbhanover on 11 May 2015, 03:09)