Not sure when it happened, but at some point, someone edit the Table of Hardware to make it less useful. In particular, one has to scroll too much to the right to get to hyperlinks for devices. Also, it would be a simple matter of having a columns with a single icons such as (?) for the other hyperlinks. There is no reason whatsoever for the current format. It is almost as if someone did this deliberately to frustrate the reader. The older format was much simpler. The entire point of hyper-linking is to hyper-link the test: Putting the hyper-links in separate columns so that one has to scroll makes no sense. One has to wonder what the motivation was behind this.
What older format are you talking about?
I am not sure. I cannot seem to find the original page. It was several years ago.
This format found by Google is closer to what it was.
What happened in my case was that I wanted to see list of all routers that had 802.11/AC. When I saw some, I noticed that I would have to scroll to the right to get to the information. But if I did that, the list of 802.11/AC would scroll of the page. It is better to have all of the information on a single page that does not have to be scrolled horizontally, IMO.
Here are a few ideas for improvement (IMO):
- Make sure all data fits on one page without horizontal scrolling.
- Eliminate "OEM Device HomePage" and just hyperlink "Brand"
- Eliminate column for "Device Page" and just hyperlink "Model"
- Use images to denote "Single Board Computer" /"WiFi Router" (nice to have, more compact)
Wow.. .No offense meant to you. I know that you do a lot of good work on the site, but even now, it is sooo annoying to scroll...I can see the veins popping out of my hand as I scroll back and forth in Chrome trying to get to the information.
First of all: The ToH contains a lot of data. Since it is too much to display in a single table, we have specialized versions of the ToH, focusing on specific topics, containing only what is needed for the job.
In your case, https://openwrt.org/toh/views/toh_available_864_ac-wifi might be a tiny bit better in terms of visibility of AC wifi (but not regarding devicepage / dataentry page).
Alternative views with better visibility:
You can see all the different "views" on the data on the overview page https://openwrt.org/toh/views/start
Maybe that was where you found what you are refering to as "older format".
Alternative solution proposals:
- Get a monitor with higher x-resolution
OK, not a real serious proposal I have 2560 pixels in x available and toh_available_864 fits comfortably into the fullscreen browser window.
There are 32:9 monitors out there, 5120 pixels wide, but I guess that's still not wide enough for all the data.
- Use your browsers zoom function to display more columns on the screen.
70% is the smallest fontsize acceptable for me. Compared with 100%, 4 more columns fit onto the screen.
- Use the CSV export of the ToH and view the full data in the spreadsheet application of your choice. Remove columns that are not of interest to you, pull ahead columns that are more important to you, zoom in/out and filter as you like etc.
Apart from that: Thanks for pointing me again on this subject!
I recognized that we have still columns in the table that are not used any longer (LEDE forum topic; datafield doesn't exist any more in the dataentries). I have removed this column now in 2 datatables and will check the others too. A little space gained again
You responded exactly in the manner that I thought you would. Seriously... your points #1-#3 are exactly what I thought you would say 45 minutes before I made my post. For that reason, I was not going to make the post, then I said to myself..."You are not being fair...write the post anyway... who knows..."
I disagree that there is "too much to display in a single table". I am looking at the table right now, and using icons and hyperlinking, I can make all the data fit into one table. For example, I could eliminate the last three columns completely using a hyperlinking and a single icon for View/Edit data.
And that is the point of being a web master, is it not? Think about it... what is better... that 1000's of people follow the suggested alternatives, or that the web master uses his/her skills to bring convenience to the viewer?
What is your disposition? Do you plan to make the table compact or not?
Seemingly unrelated question: Are you happy with the loading time of https://openwrt.org/packages/table/start? (Explanation will come after your reply)
Indeed, it takes 22 seconds on 30 megabit/s down-link Internet pipe on 3GHz Core-I5 8GB RAM. So yes, I am ecstatic with the loading time.
You can expect the same for the ToH when the links are shortened as per your proposal.
I find this loading time inacceptable for the ToH.
One page of what, exactly? Screen size varies greatly.
On, you weren't serious but I will answer seriously. Ideally if I was to design a web pahe I would try to make it look good on 1366 pixels monitor for the maximum compatibility for average users. But since the amount of data mandates here, and considering that the majority of OpenWrt users aren't the average compouter users and are likely to have bigger monitors, I think 1920 pixels should be fair enough.
I understand that there is lot of data, and that people have different requirente and look for different things, so I will bring a few ideas:
- Put the most required columns to the left and the least to the right. That way those who need them can scroll to find them.
- for things like the hyperlink to the device page on the Wiki, that column can be removed, and the name of the device can be the hyperlink (unless that could be a problem for people who use screen readers, if we have any). Similarly, the OEM device page can be lunked to the brand column (or kept in a separate column but with the text of the hyperlink being replaced with something shorter, while keeping the hyperlink as it's), or the column can just be at the end of the table so it doesn't "upset" anybody who doesn't need it.
- having some way of showing or hiding individual columns like checkboxes or something. That's going to require some big changes.
Speaking of that, and relating to my previous point, may I suggest that the pages for supported routers https://openwrt.org/toh/start and recommend routers https://openwrt.org/toh/views/toh_available_864 can be made as one page, giving the user the option to show or hide the supported but not recommended routers, and that filter can be part of the URL query like the rest of the fields. Than can hopefully be more convenient and less confusing for users, and despite being some work to do, it will make it easier to maintain.
Yes, I agree. That loading time is/would be unacceptable. The next question would we "Why?" I took a quick look at the HTML. There is nothing overly sophisticated about the page that you demonstrated.
At 22 seconds, something somewhere is broken.
wikirender the input as wikitext (use sparingly as this type impacts performance)
At this point, I must invoke the principle of the abstraction barrier, which we all know is very important in the field of computer science. The abstraction barrier says that, even if 4.3 GHz koalas are on the back-end, that is not really "our" (people who are not generating the table) problem. The generated page is simply not sufficiently complex enough for a 22-second load-time. Something is wrong, and whatever is wrong, that which is wrong is what needs to be fixed. We, the humans using the page, are not what should be fixed (by altering our behavior buying higher-resolution monitors, or downloading CSV files, etc.) What would be unacceptable would be, instead of addressing the root-cause of the problem, is to force 1000's of people down the "That's just the way it is.." rabbit hole. If the HTML generation tool is so broken that it cannot generate a simple table in a reasonable about of time, then that tool is broken.
Whatever happens henceforth, we should start with the premises that:
- The page should be compact.
- The page should render quickly.
Then we would work backward from that, not forward from something that is clearly broken.
My apologies for not seeing this question sooner.
I would make all data that is currently present fit horizontally. I did a quick mental walk-through of whether this would be feasible, and concluded that it would be using icons. The "Device TechData" column could be replaced by an Edit/View icon placed inline with (hyperlinked) device name.
The underlying Dokuwiki plugin managing and providing the tabular data is extremely inefficient. Any changes to the table layout (such as changing links for icons) are not possible without forking and altering the plugin code, which is not feasible for a multiple number of reasons.
"We" need to build a standalone application providing data entry and output functionality for the ToH data.
The status quo on the wiki is as good as it gets using Dokuwiki's own tools. So far "we" didn't step up to do the work.
I could probably help with that, not in the immidiate future though. I did some Web development in a previous life, but will need to be less busy to refresh.
If that is the proper direction, then yes. I cannot say one way or another, as I have no knowledge of DocuWiki, and I imagine that most users do not.
It seems to me that this should be a priority.
As SysAdmin, you know the perils of:
- Engineer visits site as newbie and potential contributor.
- Engineer discovers that Table of Hardware is atrocious to navigate.
- Engineer, perhaps unfairly, judges the rest of the site by experience with Table of Hardware.
- Engineer bolts and OpenWRT loses potential contributor.
Some will argue that any engineer who understands the Open Source model and gets turned-off by Table of Hardware does not "get it". On the contrary, all of us are generally busy with other things, and that is the reason that things like this are so important.
I think that someone, without actually doing the work, should:
- Acknowledge that the problem lies with the engineering of the site (You have done that. Thanks).
- Consider how it should be, without actually doing the work (...because you are busy too).
- Tell everyone else what #2 yield (Then, you will find people willing to do the work, because you have committed to getting it right).
Great, so it seems we can conclude this thread then.
- ToH is bad and needs to be better
- An application needs to be written to make it better
- A better ToH will lead to a huge influx of motiviated contributors
Now we just need to find someone to build it.
Before writing the first line of code, we should define the goal of this new ToH development.
There is way more than just
Sounds fine. I would be all ears regarding the other things to consider.