deskthority

I'd get a very busy inbox:

Field SMSHRTNDNM_0x requires Click_durp_plikplonk in ISO Dodecadecimal format! Please try again. Idiot.

And I'll be trying in vain to figure out if I put the space in the wrong place in the thing I just did because any auto generated error is beyond me.

making a standalone app or a wiki index/search-tool is a pretty big difference. If we go with the wiki indexing system maybe it would be nice to simply have kbdb.deskthority.net. It is also true that building a db over scraping is never simple, also a standalone version has its advantages especially from a common-user standpoint.

choices choices

Error messages will be like this:

Internal bus error. Please use the tram.

matt3o wrote:choices choices

Multiple choices! So long as data entry is just those, everywhere possible, we have a winner. Gimme pull down menus and I'll be fine!

Take a deep breath. And say: OMMMMMMMMMMMMMMMMMMMM.

7bit wrote:Error messages wil be like this:

Internal bus error. Please use the tram.

That's exactly what I fear.

(We've been so long building a tram line in Edinburgh (3, 4 or is it 5 years now?) that it's being torn up and replaced for weather damage. Yet still no trams! Lots of rerouted buses though. Error!!!! Go back to the 1950s and we had dozens of routes running, of course. But they got torn up for the buses.)

[wiki]Filco Majestouch[/wiki] is another example: years of products condensed into a single infobox with very little information. One of the most prominent products on the market won't work in KBDB unless you also devise a way to parse tables and specify a required format, and someone writes up a table for the Majestouch range similar to how 002 did with Topre. Having one infobox per variant would be silly.

Switch mount matters because some switches accept either, including SMK second generation and Cherry MX (both offer fixing pins). Even switches without fixing pins are sometimes PCB mounted.

I think we have a runaway misunderstanding in this topic. Is everyone here in agreement that anyone wishing to contribute to this database is going to have to do so by way of editing the wiki, and manually complying with implicit data formatting rules that are not provided on-screen?

One thing that does annoy me with infoboxes is how much boilerplate garbage has to go into the values, which is the cost of allowing totally freeform values instead of drop-down entries. The only field I've fixed is image name for dkeyboard/dswitch, which requires only the raw filename, without namespace prefix, width or brackets.

ne0phyte: Please note that many pages, such as [wiki]SIIG MiniTouch[/wiki], have "<br>"-separated values. The Majestouch page also uses ";<br>".

Also, you'll need to check for the DISPLAYTITLE template, as in {{DISPLAYTITLE:μTRON}} on the MTRON page.

it feels so much easier to build a wiki page from a DB than the other way round. I never liked wikis for structured data... but we are here to discuss and I'd like to know your thoughts

Ideally, we would have MediaWiki extensions that provide form-based metadata entry. I've already explained what I believe is essential for image metadata. For article classes, infoboxes would be entered using forms, with dropdowns or pickers as suggested by Muirium. This metadata would live in its own set of database tables.

(This is where things get fun, as correct use of relational databases means that you'd need to grant full DDL permissions to the software, which would create and alter tables on the fly, to have real columns for each infobox field.)

In terms of switches, I created a category called "production switches" to mark anything still made and sold. This for me is clearer than "vintage keyboards", where "vintage" has no clearly defined meaning, but implies a product much older than something that has just gone out of production this year; as such, keyboards that were sold until recently have no formal marker of any kind to suggest whether they're on sale or not. There are (redundant, no less) infobox fields for years of production, but these don't help you as, most often, the values are not known. A known introduction date, but no given date of termination, doesn't imply that the product is still sold, only that the field has been left NULL (unknown).

My suggestion is that, if you do go down the scraping route, that you include category parsing too, as there's a lot of information present in the categories that is missing from infoboxes.

Daniel Beardsmore wrote:Ideally, we would have MediaWiki extensions that provide form-based metadata entry.

I don't have control over that. It would involve work from the site/wiki admins and I don't know if they are willing to do something like that (or have time for). Of course if they can implement a structured data system it would be ideal, but since we do not live in an ideal world I was proposing to build a new service

As is obvious by now, I'm all for a new service. Just to see how it goes. Better something than lots of talk over nothing.

I guess my question is: is Deskthority going to work on a structured wiki? if so, I'm not going to waste time on a new project.

I gather it has been discussed. And put on the back burner. Then eventually kind of forgotten about until the kitchen began to smell bad.

already buying webspace and domain

Oooh. Ping is seeing something. Looking forward to seeing this.

Yes

So, just to add to the discussion (I support some sort of searchable database but I don't care how it's done). *Sorry this post got long *

Anyways, for my own keyboards I maintain a very large spreadsheet (about 28 columns or so of data per keyboard). My old website (my old webhost was crap so I let the subscription expire, but I still hold my domain) used a cache of this spreadsheet and then aggregated all the keyboard images from my Picasa account. I do have a proper replacement website in the works (design is done, just need to write the backend).
Unfortunately, my spreadsheet contains a lot of outdated information (especially in terms of switch names, since I usually have to make up the name when I see something I've never seen before ). Ideally, I want to link my website to the deskthority wiki for detailed information (as my descriptions are usually fairly terse) for things like switches, keycaps, layout, etc.

While I fully support Daniel, who kept pestering me to add my keyboards to the wiki, I just don't have that much time... (I'm moving to the Bay Area soon, anyone want to help out? I'd provide beers and keyboard discussions ).
Adding a line to my spreadsheet takes about 5 minutes max, but making a proper wiki for a new keyboard takes at least 45 minutes to an hour (most of this is doing pics properly). And depending on the keyboard, it can take an hour or two to take all the pics I want with dismantling and putting it back together. Yes some keyboards are fast, but some are painstakingly slow.

To me, the most important thing is to get the information about the switches (and the mechanism) into the open, and then documenting each keyboard separately.



Now, just a little thing in my wishlist (this is a bit of work, and while I'm a programmer and understand web stuff, I'm hardly a web dev).
I'd *really* like to transition my spreadsheet into a sort of database like kbdb (manually doing it doesn't bother me, as there are a couple fields I don't make public).
So, doing scraper that pulls from the wiki is probably the easiest. I think a more ideal solution is to have the wiki pages generated and linked to the database. This way if a new keyboard is added to the database without a wiki page, a new wiki page is added with the proper template for whichever field was added (company, brand, switch, connector, etc.). Or, if a wiki title is changed, the name is automatically changed in the keyboard database (obviously merging/removing fields will be necessary too).
This way, when I have a new keyboard to document I just enter all the fields in the database, and it's automatically added to the wiki. And if I have additional information about the keyboard (I usually do), I can just enter it on the keyboard specific wiki page.
(It would even be possible to have per user list of keyboards, which to me is exactly what I want my website to have, so I'd really like an SQL dump option for this ).

I can maintain my own sort of webpage, but tbh, I'm lazy, really lazy. I prefer auto-updating, crowd sourced alternatives, even if it takes more work initially.

thanks for your feedback, my purpose is to fight laziness with the easiest/funniest/fastest data entry tool. I'm building the core system now, I hope we can find a way to interact with the wiki at some point.

ps: domain ready

That's the stuff!

So the idea is to have a DB with an easy interface and changes/additions will be updated in the wiki by generating an article with the wiki markup and everything [and possibly updating the wiki programmatically]?

ne0phyte wrote:changes/additions will be updated in the wiki by generating an article with the wiki markup and everything

if there's interest by the site/wiki admins and the wiki has decent API that would be feasible. I'm working on the db right now and that should be more or less the same whatever route we choose.

There is the export and import.
http://deskthority.net/wiki/Special:Export
http://deskthority.net/wiki/Special:Import

The KBDB wiki user would need access to the import. Maybe it is possible to import a single Article/Category page.

EDIT: But we would have to update the by category pages (kbd by switch, kbd by manufacturer, etc) for additions as well.

HaaTa has some great points.

Laziness is what keeps me from editing the Wiki, too. I could learn, but it's something I've tried here and there with Wikis and always run out of steam well before the realm of instafail has been passed. Too much freedom. Too many options, to choose from and learn. Gimme a text field for name, and a bunch of drop down choices for everything else! (Wherever possible.) I just wanna see my keyboards in place and play with searches without even the thought that I could be breaking something in doing so.

Using the db for sharing our own collections of keyboards: check! Not a day 1 necessity but the perfect incentive to populate the db so we can refer to it with our stash queries.

HaaTa wrote: so I'd really like an SQL dump option for this )

Yes, that'd be nice.

Muirium wrote:

HaaTa wrote: so I'd really like an SQL dump option for this )

Yes, that'd be nice.

I'm such a supporter of open source and free information that that would not really be a problem. You'll be able to export even in morsecode and klingon if you want.

Muirium wrote:Laziness is what keeps me from editing the Wiki, too. I could learn, but it's something I've tried here and there with Wikis and always run out of steam well before the realm of instafail has been passed. Too much freedom. Too many options, to choose from and learn.

Basic MediaWiki syntax really isn't hard, especially considering how many people here are programmers or know electronics; it's not like this is the frigging My Little Pony Forum (and most communities do have a wiki, usually over at Wikia — it's only us lazy luddites that can't manage it).

There's a handy-dandy toolbar for point-and-drool usage (which admittedly I always use to begin a table, as table syntax is a pig to remember), but in most cases, it's either dead easy (* for bullet, # for numbered list, ''…'' for italics, '''…''' for bold, [[…]] for link etc), or in the case of syntax for infoboxes, galleries, tables, etc, just copy and paste from another page.

References are a bit fiddly, I grant you, but nobody bothers with them anyway. (Leading to lots of articles with unsourced, unverifiable claims that could be true or could be nonsense.)

In fact, in general, just find a page that looks like what you want, click Edit at the top to see the source, then Select All, Copy, switch tab, Paste, and amend as required. I often do just that: just fill in the new content into the markup of a similar page.

Freedom of expression is such that you can never robotically create articles from a database, unless all the database is is just a terrible rip-off of MediaWiki, and then you're in a deeper hole than when you started.

However, I do feel that categorisation could use a UI, images need a complete top-to-bottom reinvention, and infoboxes should be (optionally?) GUI-driven and the fields and data stored in a database for aggregation and searching.

There's no rule that says that everyone needs to write entire articles or add photos — for example, the Cherry MX Red page was left saying that MX Red was a one-off that was all over, long after they went into mainstream production. Updating the page with newer information doesn't require much effort! Keyboard terms … I'm sure there are still plenty that I've missed, and they don't require illustration. And those people who do take great photos, only need to come along and add a picture. If all they know is how to upload, describe and link photos, that's fine. They don't need to care about anything else, they can be proud to have simply provided quality illustration.

Nobody needs to do *everything*, it's just that we're not even at the stage where everyone just does *something*, and in that situation, no-one would have a huge burden. Just learn a little bit of markup, copy and paste etc.

My feeling is that a structured database and a very easy to use frontend might be the key to the success of the keyboard categorization. I might be wrong.

All the info will be open source or creative commons so perfectly compatible with the wiki, if the wiki can take advantage of the db (and vice versa) I hope we can find a way to exchange data.

We're comparing technical solutions to a human problem. Contributing a new entry to a Wiki has a different "feel" to it than adding an entry to a database; even if the total work is the same. It's the blank slate problem. When "writing" on an empty page, you're making choices about what not to do as well as what you actually write. When filling fields in a database, meanwhile, the structure is explicit and contained.

Database editing keeps you on track by giving you nowhere to wander. A fear all too prevalent in newbs (like me) which only fades with Wiki writing experience. The tightly limited database UI is a hack around natural human doubt. Well, when its logic is right.

True enough, the best way to add to a Wiki is to copy and alter an existing page as your template. But it's still a different kind of work. The computer doesn't know. This is all about the touchy feely stuff between our ears.

I have this bad feeling people will keep ignoring everything that was said and embrace and extend anyway.

Embrace extend … and extinguish, only works in closed source. No one's trying to take the Wiki away. The more organised data we have the better, surely.

Two key points:

1) If you simply went around existing articles and reviewed the prose and corrected spelling and grammar (inevitably required given how many of us don't have English as a first language, or come from England where nobody can spell …)—a task which requires next to no understanding of the markup—you'd soon absorb how the markup works from simply seeing how pages look on the inside.

2) The wiki is based on prose and encyclopaedic content. You need paragraphs, tables of data, inline links to other articles, sidebar images with custom captions, inline references, image galleries within other page sections and more. How exactly would you generate this from a database? The best that you could ever achieve, without a mammoth undertaking (completely custom UI for every page type and every combination of page parts), is WYSIWYG article editing, and MediaWiki already has that anyway (it's been available on Wikipedia for a few weeks or more).

Even if you do generate the relationships and metadata from a database, you'd still want a TEXT column in the database where you can write the article proper, and then you'd need a markup language (and a parser/lexer) together with conversion to HTML with all the correct escaping etc (to avoid XSS), an image uploader and scaler, SVG to PNG renderer, revision tracking, and by the time you'd written all that, you'd wonder why you didn't simply write an extension to MediaWiki to just add the specific functionality that you wanted in the first place and let the MediaWiki team take care of what they already know how to do, and have done all along!