Creation of new dataentry / devicepages via the corresponding templates made easy:

Templates:
http://wiki.openwrt.org/meta/templates
http://wiki.openwrt.org/meta/template_device
http://wiki.openwrt.org/meta/template_dataentry (admin editable only, since critical for this whole thing to work)

Moved template_device to _template_device_old, and implemented new template_device, that makes use of the data plugin.
Feel free to change and update the template_device, especially regarding use of the data provided by the data plugin / the dataentry pages.

Create new pages
http://wiki.openwrt.org/meta/create_new_device_page
http://wiki.openwrt.org/meta/create_new_dataentry_page

Have fun!

(Last edited by tmo26 on 24 Jul 2015, 19:58)

Our new starting point: http://wiki.openwrt.org/toh/toh_new_start

Shall we even reduce this new start page to http://wiki.openwrt.org/toh/tohmk2_shorter, with a link to "More datatables, filtered for different criteria"?

Feel free to comment / change!

Edit: Geeeez, that was nice, to simply copy&paste (&slightly mod) the pages from the demowiki and see it working at first try. It was well worth the effort! Yeah! :-D

(Last edited by tmo26 on 24 Jul 2015, 20:22)

@richb: Do we still need the example pages http://wiki.openwrt.org/playground/wndr3700v2 etc. and the dataentry on http://wiki.openwrt.org/toh/netgear/wndr3800?
The field naming is old (e.g. Version vs. Version(s)s) -> information 'Version' not shown in the new toh.

EDIT: Dataentries removed.

(Last edited by tmo26 on 1 Aug 2015, 10:32)

http://wiki.openwrt.org/toh/tp-link/archer-c9
http://wiki.openwrt.org/toh/tp-link/archer-d9
http://wiki.openwrt.org/toh/zyxel/p2812hnu-f1
http://wiki.openwrt.org/toh/zyxel/p2812hnu-f3

need to be cleaned up, i.e. dataentries removed, and datatables according template_device added instead. EDIT: Done.

Hmmm... thinking of it: Is there a need / whish to show the dataentry on the devicepage as in the c9/d9 above?
Not sure if that would be possible without getting double data in the database...
Edit: No, it wouldn't: https://github.com/splitbrain/dokuwiki- … issues/168
-> Dataentries on devicepages to be removed/replaced

Please also take a look at http://wiki.openwrt.org/meta/template_device and see if there can be something improved (more usage of the data we gathered?).

(Last edited by tmo26 on 1 Aug 2015, 10:31)

I tried the templates/create_new_page things... very nice
Based on: https://forum.openwrt.org/viewtopic.php?id=58633
I created first a data entry page, and from there I clicked create_new_device_page.

Result:
http://wiki.openwrt.org/toh/hwdata/asus/asus_dsl-n16u
http://wiki.openwrt.org/toh/asus/asus_dsl-n16u

A few minor comments:
1) The version filter ~~ something did not work right away (I left version empty). However, by removing the version filter entirely from the Device Page I got it to work.
2) It was great that the create_new_device_page existed directly on the data entry, but later I of course hade to update that field manually (ok, I have to do some actual work, I get it).

About the device page... I am reluctant to "all the information" in the template. It is a template, and it should all be there. But when I have just created a new page... perhaps I dont know much, but it is anyway good to create it... for the READER it is confusing with so much template text and so little actual content.

Under Hardware... that is not supposed to be there in the template but rather being fetched from the Dataentry (most of it at least)?

I don't really have a better option to the template... but could we be more clear about what is template instructions... make it italic? make it red? make it blink?

Yes... I think the table of hardware should show something like the above thing, very close to the top.
I can imagine...

Very short explaination: "This is the table of hardware"
To add new device: just a link (btw, it is made easier now with the create_-links than the text indicate?)
For details/explainations about fields: just a link.

Then I would suggest a horizontal menu of filters/columns, like:

Standard Supported, Standard All, Short All, Extended All
-----
THE ACTUAL TABLE (Standard Supported)

----

This "menu" could be copy-pasted to the top of all the ToH-pages.

And... your last two comments... one was for @rich.... the other one I dont know about. But I had some fun!
I will not write more now... we need to keep the list of issues we work with short enough, and I think what we are currently discussing is enough.

(Last edited by zo0ok on 26 Jul 2015, 21:25)

Improvement for the create_new_devicepage link on the dataentry pages: Form can be prefilled by adding the contents in the link.

Example:

http://wiki.openwrt.org/meta/create_new … sion@=3.33

-> Form comes prefilled with values

Regarding the links destination after creation of the new devicepage: Maybe there's some way to automatically change that link to the new created devicepage. I'll look into this.

Shall I reimport the toh data now? Can you give me a link again?

Hi jow,

no need for a reimport right now. Maybe later, after some more experimenting.

ok

Hmpf... not as easy / nice as I thought.
Yes, We can prefill the devicepage link in the dataentry, but it will exactly look like shown above, i.e. full url i/o nice and small title or pagename respectively.

See how it looks in the dataentry: http://wiki.openwrt.org/toh/hwdata/d-li … l-039_3.39
See how it looks in the datatable: ... after checking this out, I have to say: No, this is not the way we want to go.

Reasons:
- Device Page_page sees all the parameters as content of a pagename, and since pagenames must not contain '@', the following pagename is created:
- In datatables, changing 'Device Page_page' to 'Device Page_url', leads to existing pagenames being treated as url, which of course leads to browser error (toh:4g.systems:access.cube doesn't exist as a http-url).
- OK, we could adapt the existing pagenames to full url style, but then instead of 'access.cube', you would see 'http://wiki.openwrt.org/toh/4g.systems/access.cube' in the datatables.
Naaaa, really not. We want to see 'access.cube', short and crisp.

This means: Until we find some other solution, we stay with the current 'create_new_device_page', no prefilling of the form.

I changed Version(s)~~ to Version(s)~, now it works when no version is given.
But: I think this will lead to problems with devices with >1 versions.
Anyway, we go the 'Version(s)~' way now, and we'll see what happens. Maybe it's no problem at all

Good with me! Do you need me to do anything?

The ToH:s, the templates, the instructions... I dont really have the complete overview (they way you and @richbhanover has), so I don't really now about (re)structuring/(re)naming. But I am not worried about it.

I think it would be good to get "everybodys" feedback. But if there are things we can fix/clearify now to avoid to confuse "everyone", then that is of course good.

Good point!
You left "Current Rel" on default '¿', which then still was shown on the table filtered for supported devices.
I added a new filter to the table... and changed the definition from "Since" to "Current":

filter     : Supported Current Rel!=¿
filter     : Supported Current Rel!=WIP
filter     : Supported Current Rel!=''
filter     : Supported Current Rel!=-
filter     : Supported Current Rel!~*trunk
filter     : Supported Current Rel!~*-rc*
filter     : Supported Current Rel!=unsupportable
filter     : Supported Current Rel!=not supported

Comments on this definition, please.

Comment from my side: The definition of "supported" in the datatables should be somewhat consistent to the valid values of the _release Type Alias.
Or in other words: The dropdowns allow "CC trunk" as valid value for Supported [Since|Current] release, whereas in the datatables, everything with "trunk" is considered as not supported. -> datatable filters and Type Aliases need to be in sync.

With "all the information" you are refering to the descriptive text already present, not the datatables, right?

Again, good point.
In the past, I stumbled over some devices, where I was not sure if the information given there was simply a "didn't edit the template values" or actual data.

Hmmm... the 'folded' plugin comes to my mind.
"Template example" > click on it, and an example unfolds.
Drawback of this method: Difficult to make clear to the editor, to add his edits BELOW the folded section.
The markup consists of '++++', which after a long section, you might overlook, and add your content within the folded markup (within the '++++').

Alternative:
Create template instructions on a separate page, and in the template, simply add includes to these pages {{page....}} or sections. This way, in the wikisource, only a single line appears for the template instructions, and there's no doubt where to add new content.
Something to pay attention to: folded and include plugin do not mix very well. See folded/include plugin on dokuwiki.org for details and troubleshooting, if the combination of those two doesn't work as expected.

Yes, this information should come out of the dataentries, and should be presented in datatables.
However, datatables do not provide this vertical layout, but rather a horizontal one. I left this in the template to show how it was, and we now have to adapt it to the new environment.

On the definition... I'd prefer a positive match: that it should match 10.03, 12.09, 14.07... but I understand the disadvantage. So I think your filter looks good. Hopefully, in the future, we will have less garbage in that column and we can remove some of the negative conditions. Ideally, it should contain a supported version, or be empty, right? (now that we have the Unsupported field for unsupported status)

Yes, with "all the information", I meant everything that do not come from the dataentry. There were some section, like the "switch", that I think was particularly tricky. You (or @richbahnover) already did a quite good job with adding "FILL-IN" most everywhere. Perhaps with a second review it is good enough. From another perspective, the wiki should not contain plenty of irrelevant text (thinking about search engines and stuff). So, perhaps the template page should be very minimalistic, but with a link to a rich template page to copy sections from. @richbhanover - have we already talked about this and agreed? I feel I am stepping into your domain here

First rough implementation, please have a look at http://wiki.openwrt.org/toh/toh_new_start

BTW: What do you think of the lastmod date in http://wiki.openwrt.org/toh/tohmk2_shor … lastmod%25

?

Updated http://wiki.openwrt.org/doc/howto/adding_to_toh

Now it is PERFECT!

(the More Datatables "menu" could be present on the other datatables to, to simplify navigation, but that is a minor thing that perhaps you waited with until you know we are on the right track).

Correct!

I appreciate all the work that you are doing on this important topic.  I would like to offer a few comments.

Please be aware, if you are not, that "Techtarget" pages are showing up in wiki searches.  To the uninformed they look like duplicate pages for a device that already exists. 

The detail in this post is not relevant to most people and too long for most to read.  There is some important info that I think is relevant to the general reader, and worthy of a sticky.  I suggest this include a list of links, a short status report with goals and target dates, overview of the add process for hardware, feedback process (if any, you may not want to be buried with notes like this), and how this fits into the bigger wiki redo.  The note should be updated as relevant links or process changes.

Regarding the "Add Hardware" process, I think it is important enough that it should have a reviewer.  I am more concerned about the device as opposed to the device content, which can be edited (I think).  If it's forever, and open to all subscribers, there is too much opportunity for duplication.  I have experience with large databases and know (painfully) how the level of control on key fields impacts the data quality and usability.

Please see the following page, which has grown from a single device to a family of devices.  I am not sure how this fits into the intent of your new design (meets it or breaks it).  http://wiki.openwrt.org/toh/hootoo/tripmate-nano

No. These are no longer needed.

1) Change pagetitle
Current: Pagetitle = DSL-584T A1 (EU)
Proposal: Pagetitle = Techdata DSL-584T A1 (EU)

2) Add notes
Proposal:
    Searching for pure technical facts? See table below.
    Searching for installation instructions, bootlogs, other info? See the devicepage: [link to devicepage]

See example http://wiki.openwrt.org/toh/hwdata/d-li … k_dsl-584t

Comments? Other proposals?

There will certainly be a thread outside this one for announcing and requesting user feedback.

You can not create duplicate pages for the exact same device (Brand/Model/Version).
Reviever: That would be perfect. Any volunteers?-)

Can you give some examples? I'm not experienced with databases, hence I'm having problems understanding your saying in the greater context and in the context of the new toh.

3 devices on one devicepage. Reading family I expected something like http://wiki.openwrt.org/toh/netgear/wndr3700.
No effect on the toh.

Edit: And no effect on the devicepages, too. They can host multiple versions. Datatables can show multiple versions or Models, too, depending on filtering.

(Last edited by tmo26 on 28 Jul 2015, 21:10)

@zo0ok: Did I already request these changes?

- Page include at the top of the dataentry page: change dataentry_permanote -> dataentry_topnote
For copy&paste: {{page>meta:infobox:dataentry_topnote&noheader&nofooter&noeditbtn}}

- Page include at the bottom of the dataentry page: add :meta
For copy&paste: {{page>:meta:template_dataentry_background#conventions_for_dataentry_values&nofooter&noeditbtn}}

- Device Page_page                      : .toh:d-link:dsl-584t
-> We don't need the '.' in front of the toh
-> change to 'toh:d-link:dsl-584t"

In case I didn't: Could you please update the datapages accordingly?

Regarding the dataentry:

Unsupported           :                 # Describe what is not supported or status

What answers do we want to have here, and what answers will the users give most likely?

"Nothing is supported"
"Wifi not working"
"Status unknown"
"Wifi failure ever 23h 22min, and only after I had Crunchypops for breakfast and at fullmoon in november."
"Constant reboots whith mightytorrent enableld"
"All crap, doent work a bitt!!1"
"Everything working except wifi, ssh, ..."
"OK"

Can we give our users a bit more guidance here, what we expect / what to enter here?

I would prefer to see
Techdata: [Brand] - [Model] - [Version(s)]

I think you are suggesting adding this to the /toh_new_start which is fine, but was not my real point.  My real point was from outside of the hardware project realm, just searching the wiki, new pages are presented.  Having this in the /toh_new_start does not address that, though the new Pagetitle format does help clarify this. 

As for suggestions, to be consistent, the device pages could be similarly named. 
Device Page: [Brand] - [Model] - [Version(s)]

I realize that this may not be possible unless the content of the pages is created dynamically.  There are also a lot of pages that are not single device pages (like the HooToo), and this would not work.  It seems that device pages should match the toh entries, but this again may not be feasible to correct.  I assume you have been down this road, otherwise the Techdata would probably be the header on the device page.  The real problem with the HooToo page is the content, and that is outside the scope of the project.  Techdata is the solution for extended searchable data for devices and the current result works.

I would like to see the /toh_new_start "More Databases" have links to the Pending(?) and Unsupported Table Of Hardware. 
http://wiki.openwrt.org/toh/unsupported
The ability to get a view of all of this in one table would be nice.

Brand
Model
Version
Status (Approved, Unsupported, Pending)
Techdata
Device Page

I think the Page Name should be "Supported Table Of Hardware"

Well, computers are finicky by nature, all it will take for a duplicate entry is a space or a dot.  I had a client who imported data from their Engineering system with no oversight.  The part numbers were long, close to 26 chrs (another issue) and they also used spaces, which sometimes were two spaces or no spaces.  Each of these ends up as a new records "key" field, as it is technically unique.  Maybe it was a poorly documented policy, maybe it was sloppy work, the result is the same.  The point is they had multiple key fields that were off by a character and created a unique record that lives on.  These were purchased items, so identical inventory could be in stock under different item numbers.  Very, very bad.

A note on spaces.  If the data will be used to construct a URL, there can be no spaces in the content, or the URL can break. 

D-Link DSL-584T A1
D-Link DSL584T A1
D-Link DSL584T A.1

We can enforce brand in a drop down, but only so far.  (BTW, How do we add a new Brand?)  The other 2 fields are unstructured.  It is not possible to predefine these, hence they are free form.  If you look carefully at manufacturers product pages you may find inconsistencies between model number nomenclature on the product and support pages.  I do not know if we need to be concerned about case sensitivity (like in Linux commands).  A strong policy is helpful, but you will not get everyone to read it, or if you do, interpret it the same way.  Even a large administrative group may not be consistent. 

One tool I frequently use is an Excel Template for data collection.  Assuming the current process, we are asking a user to fill in a page of information they may or may not have.  Creating a downloadable template that a user can fill in off line will allow them to collect data prior to reaching the form page (where they discover they do not know the answers and submit bad or null values).  They can then cut and paste from the spreadsheet.

I am trying to find a new job, and easily distracted (as you can see).  I am not sure I can help, but I think an acceptable practice would need to be defined first.  My next post is a framework that addresses this.  I think it may need to be internal, but I do not know what "internal" is in this environment.  Some of this would be easy with workflow tools.

Regarding the Techdata content:
How does the Device Page differ from the WikiDevi URL. 
It may be easier to maintain OEM support Page than a OEM firmware link.
Please also consider adding a link to the FCC Info for the device. (does this differ by country?)