Can we use a score (0-100): average
  Installable from: WebGUI=100, TFPT=50, Serial=10
  Wifi: Works=100, Limited=50, Not working=0
  Ports (USB etc): Works=100, Limited=50, Not working=0
  Compability: Current/BB=100, AA=75, Older=50, Trunk=50, Other/Custom=25
  Stability: Stable=100, Questionable=50, Unstable=10
  Availability: For sale new=100, common used=50, rare/obsolete=10
  Bricked: Never/Rarely=100, Some users=50, Multiple reports=10
  Memory: 32MB+=100, 16MB=50, 8Mb=0

This would not need to be automatic, but more a guideline for calculating a score. It would be slightly subjectively calculated by the page maintainer, but the sub-scores could be presented in the hardware article (not the ToH-list). Also, the date when the score was last updated could be included.

Could it be meaningful to have such (or some kind of) semi-objective score based on components? Perhaps it would be more clear than todays status?

Oh please no. I get what you're trying to do, but such arbitrary values will only increase confusion.

Haha - then I drop it

I think it would be good to be very clear about if
- WiFi does not work (especially for routers marked supported)
- Installation can not be performed via WebGUI (or whatever is standard procedure for the model)

(this thing about figuring out that since it is a Broadcom chipset it is probably not working, despite listed as supported, is not so user friendly, methinks)

(Last edited by zo0ok on 14 Apr 2015, 20:28)

That looks *very* nice. A question though - would it be possible to 'clean up' the links? Ie, in the wiki, a 'nice' link would look like this:

[[http://actual_link.html|here comes your text]]

I have tested the URL fields, they seem to prefix another https:// and of course the wiki doesn't format that... It would look like https://[[http:...

That would make for a more compact view on the ToH .

(Last edited by Borromini on 14 Apr 2015, 20:37)

You're absolutely right.
I added URLs today and instantly thought: Looks like shit.

I don't have a solution for this yet.

Edit: Solution found, see http://wiki.openwrt.org/toh/d-link/dir-505 and http://wiki.openwrt.org/toh/toh2
Problem: This solution has performance isues. Serious issues. My demowiki with the 891 datasets is running on a RPi2. When the full toh gets built, it takes 23sec to load the page, while 1 core is at 100% load. We do not want this for a highly frequented public wiki (which sometimes seems to have some issues already now).

(Last edited by tmo26 on 15 Apr 2015, 00:03)

A couple thoughts:

1) The TOH2 page looks great. I like the shortened URLs.

2) A couple solutions to the performance problem come to mind. Most require pre-computing certain things:

• We could pre-compute the page and cache the results. Would need some kind of trigger to update it when there was a change.

• People rarely want to list all the routers, except for terminal curiosity. We could treat a click on a vendor's name in the TOC (on the right) as an indication to display only that router's info. Clicking "All" would take some time.

• We could have links for "Show all routers that support..."
     - Barrier Breaker (BB) - current/stable images (recommended)
     - Chaos Calmer (CC) - bleeding-edge trunk
     - Attitude Adjustment (AA) - Previous build, superceded by current BB builds
     - Old, crufty releases :-)

Whether we use it for the TOH page or not, I like the last item because it funnels newbies toward routers that support the current BB images, so their likelihood of success is highest.

If it's just a matter of replacing the URIs with a description, that can be done with just a few lines of CSS without any change to the markup.

(Last edited by metai on 15 Apr 2015, 02:28)

I already thought about CSS, but how would you do that?

Regarding the URLs to the firmware images: maybe it makes sense to use https://downloads.openwrt.org/latest/ - this is a symlink that will always point into the current stable release - this way you don't end up with outdated links whenever a new release comes out.

There are several ways to approach this. One of the simplest one would be:

.fw_factory a {
   display: inline-block;
   overflow: hidden;
   width: 6em;
   white-space: nowrap;
}
.fw_factory a:before {
   display: inline-block;
   content: 'Lorem Ipsum';
   width: 6em;
}

Most of this could be generalized into generic selectors so every field that needs replacement would only need one or two additional lines of CSS.

But there are other ways. As so often in CSS, it's getting what you want while choosing between the downsides of the different approaches.

Edit: If it's just a matter of shortening the field so it wouldn't go overboard:

.dataplugin_table .urlextern, .dataplugin_entry .urlextern {
    display: inline-block; overflow: hidden; max-width: 7em; white-space: nowrap; text-overflow: ellipses;
}

(Last edited by metai on 15 Apr 2015, 17:11)

Good proposal on one hand; on the other: This way, you don't see what version you are really downloading. Compare:

https://downloads.openwrt.org/latest/ar71xx/generic/
https://downloads.openwrt.org/barrier_b … x/generic/

If we refer to "the latest" URL (which would point to bb/14.07 at this time) while the dataentry shows support for 12.09 (only 12.09, not the FW URL), the user thinks he has downloaded 12.09 while it is 14.07 in reality. He can not see this error by simply looking at the filename, since that does not contain any version info. Only after successfull installation you can easily find out what version you have. -> Make it transparent to the user, what exactly he is downloading.

For the dataentry page, I'd prefer the full URL. This way, $user knows that it's BB and that it's 14.07, which could be helpful when asking questions here in this forum if the user knows halfway what he has downloaded).

After some thinking about the URLs in the toh: Why should we put them there anyway? Dear user, if you want to download firmware, please see the device page or the dataentry page.

-> Full URL incl. version on the dataentry page
-> No URL in the toh
-> No problem any more with too long URLs

Updates:
- http://wiki.openwrt.org/toh/toh1 -> FW download URLs removed; Usage note added.
- http://wiki.openwrt.org/toh/toh2 -> Shows table(s) with all 3 options: full url + short link in the upper table, no FW download url in the lower table.
- http://wiki.openwrt.org/toh/d-link/dir-505
  -> long urls -> size of dataentry box needs to be enlarged -> CSS
  -> CSS -> https://www.dokuwiki.org/plugin:data#cu … he_styling
- http://wiki.openwrt.org/toh/tp-link/tl-mr3020 -> no update, only for comparison (short links)

@all: Let me know what you think of the updates..

(Last edited by tmo26 on 15 Apr 2015, 20:37)

Thanks metai for that css proposal!

I don't feel good enough in css to make css work according your proposal while considering the styling as described here: https://www.dokuwiki.org/plugin:data#cu … e_styling.

But it's good to know, that you can easily style
- the general appearance of the datatables and dataentries by css
- the appearance of links / urls in particular (short ( long / whatever)

So we only need someone who is able to edit <dokuwiki>/conf/userstyle.css

If we can ensure that the device specific pages have consistently easy to find links to the recently supported version I would also advocate taking the URLs off the ToH. In my mind the ToH should be used to drive people to the device specific pages which almost always have some useful/important information on them so we should encourage visiting the device pages before downloading the firmware. The device pages are a bit of a mess too so I suppose after cleaning up the ToH the next thing would be to do a standardized template for device pages which makes some of the important information easy to find and consistent from device to device.

Full ack!

I absolutely agree. But there's also something to be said about jow's approach that would not require all detail pages to be changed when a new release happens. A problem to chew on ...

I agree with the "let the user download from the details page" sentiment. This way, there's at least a chance that warnings or special procedures can be observed. So, "no FW download" gets my vote, in both tables.

I vote for the first one.
http://wiki.openwrt.org/toh/toh1
Nice and simple!
Then wen you get to the page of your router then you get all the info about the complicated stuff.

(Last edited by tapper on 15 Apr 2015, 23:00)

One minor nitpick: please spell it "OpenWrt" not "OpenWRT" it would be good if the own wiki used the proper form

Agree. The first is better. The details page is the right place to get the specialized info.

Funny to learn the correct spelling only after 2 years working with it
I'll keep that in mind!

+1

I thought we will have a simple and detailed table with the simple being the default.

Also I'd suggest baking the link to the device page into the router name in the table. Having it in a separate column verbatim seems odd.

Oh, I vote to keep both tables. The first "simple" one and the second "extended" one (the version without firmware download links). Both have their use, but people should be led to the first one first.

Yes, I would agree that both tables have their uses. If you already have a router and want to check it out then the simple table is fine. If you're looking to purchase a router which is supported by OpenWrt and you want certain features the second is better. That said it's still a little limited, it would be super nice if you could do more advanced querying... For example if I'm looking for a router that is supported by the current version of OpenWrt, has at least a 650MHz CPU, USB ports, 802.11n, gigabit switch, and 32 or more MB flash. I'm not sure that's really possible in the wiki though.

I think... the second one, minus "Platform" and "WLAN Hardware". Who cares about this information, apart from the developers?
And it needs to say if WiFi works or not. I would be good with
a/b/g/n  = works
(a/b/g/n) = does not work

WLAN Hardware may not be so important for that table as long as it is on the detail page. The target (not present currently) and platform may be valuable to know to gain cues about specific quirks and compatibility in certain regards. Personally I'd keep these for the detailed TOH.

That's exactly the intention behind having two tables and exactly the reasons why I wrote the questions at the top of the page.

I asked myself: What usescases /  users do we have?
1) Hardware already present, only information required for one router, only basic info as not to confuse the user with information overflow -> toh1
2) Hardware not present, user wants to buy and needs to filter multiple characteristics -> toh2

3) If someone thinks that he needs a third table with different columns -> can be done in the blink of an eye (so to say). We're not limited here.

Regarding advanced filtering (<,>): Yes, can be done: see table with comparators here https://www.dokuwiki.org/plugin:data#data_table_output, but I don't know yet how this can be done in conjunction with the dynfilters (the First line of the table where you enter your search). I'd like to have that <,> filter-feature too.