deskthority

Oh and sorry webwit. I generated around 600 requests during testing and you will find about 100 weird requests in the log that returned "Bad request".

I used a for-each on a jQuery object which resulted in requests for all jQuery functions

Muirium wrote:I'd go with kbdb.it (information technology as well as Italia) if you want a name and domain suggestion. Short, memorable and straight to the point.

there's also kbdb.io which is pretty nice. Also hiddb.com/org is nice (who knows we could expand to mice...) and disambiguates from the musical instrument.

ne0phyte wrote:The parsing of metrics, keyboard price and production year is also hard as it is ("$200-300", :"$6000 (for the whole notebook)", etc).
I guess a fuzzy search should still work on that data.

Price is something that we can't simply hold up with. I believe that the best would be to simply categorize the keyboards in 3-4 tiers like:
$: cheap, up to $100
$$: expensive, $100-300
$$$: insane, $300+

ne0phyte wrote:But apart from that problem here is the first full list of keyboards as JSON: http://pastebin.com/FUBYej4U

That is a great start ne0phyte!

Prcies: I find it more interesting to know what they cost back in their days.

Prices for used ones depend on condition and on layout, so it would be better to have a separate slaes price database with the date of the sale, which should not be part of the wiki.

I suggest to first replace , by $MYCOMMA within ( ) and then split the line by , and then replace $MYCOMMA by , again.

7bit wrote:Prices for used ones depend on condition and on layout, so it would be better to have a separate slaes price database with the date of the sale, which should not be part of the wiki.

price of used would be really hard to follow, I agree that we should only concentrate on price at EOL (ie: the last price before it was retired)

I'd make a clear separation between keyboards in current production vs. retired products. As much as I love old IBMs, they're irrelevant to the common newb's implied question: best (new) keyboard given X+Y+Z (that I can actually buy from a store, with standard warranty).

So price matters more for current keyboards (and is easier to define, discover and update) and less so for the classics.

But HIDDB? You've had too much coffee this morning! Mice, tablets, trackballs and pedals can wait; and get a sub domain if necessary. KBDB has a neat ring to it

Oops. The list I posted isn't complete. It only contains articles that are linked on http://deskthority.net/wiki/Category:Li ... _keyboards and contain at least 1 infobox.

Does it even make sense to include keyboards with 0 parsable information? It would be just the name and some linked Articles aren't for single keyboards anyway.

For example there is the http://deskthority.net/wiki/Unicomp_Keyboards article which contains several keyboards but none of htem has an infobox.

ne0phyte wrote:For example there is the http://deskthority.net/wiki/Unicomp_Keyboards article which contains several keyboards but none of htem has an infobox.

This is also a problem for the Realforce (and Topre OEM) keyboards. Most of the Realforce keyboards are not really interesting enough to warrant their own article.

In any case, I like this idea and I would be happy to contribute where I can.

what are the minimum required fields we need to accept a new entry? And what are the optional values? Based on that we can choose what to include/exclude from the import.

Mandatory
Retired (false=still produced OR year of retirement, 1970/01/01 if unknown)
Name
Branding
Year (first seen)
Picture
Interface (?)
Switches (?)
Size (?)
...

Optional
Switch mount
Manufacturer
Part number
Weight
NKRO
More pictures
PDF Manuals
Manufacturer's URL
WIKI page
Review URLs
...

Should we handle different versions of the same keyboard as new keyboards or just a subset? For example, Poker with red/blue/black/brown switches is 1 keyboard with 4 variants or 4 keyboards connected with each other.

matt3o wrote:Should we handle different versions of the same keyboard as new keyboards or just a subset? For example, Poker with red/blue/black/brown switches is 1 keyboard with 4 variants or 4 keyboards connected with each other.

Imo that should be one article and the "Switches" field should be an enumeration
'Cherry MX Red,\n Cherry MX Blue,\n ...'

I'd be going with less mandatory fields than that. Probably just start with 'Name', 'Switches' and maybe 'Branding'. The rest could be simply set as 'Unknown' until someone comes along and populates the value?

RE: Dividing identical model/different switch keyboards, as long as you could still get a search result for the switch type, I don't think there'd be a problem with combining them.

also... should we include *cough*membranes*cough*? (logitech, trust, microsoft, ...)

matt3o wrote: Should we handle different versions of the same keyboard as new keyboards or just a subset? For example, Poker with red/blue/black/brown switches is 1 keyboard with 4 variants or 4 keyboards connected with each other.

The former: one board with many (child?) variants. Which then allows…

Mandatory fields for:

• Staggering. (Minila, I'm looking at you.)
• Case colour (Multiple choice between a few general options like: black, white, beige, grey, bare metal). Newbs ask about this a lot.
• Caps colours too. (Two pull down multi choice entries: one for alphas one for mods. Allow an exception case for crazy multi colour keyboards. Perhaps a field to specify whether mods are lighter or darker than alpha, which sometimes matters more than their specific categories.)

Optional extras:

• Legends colours. Could get complex, see above and then some…
• Font!
• Caps material: PBT, ABS, POM, metal, other? (Naturally this is for most keys. Could have a whole separate field for spacebars!)
• Legends are double shot, dyesub, lasered, or whatever?
• Case material. Plastic, metal, or what?

Got lots of ideas for this stuff. Could be a neat project! Especially if adding children (like the red, camo and beige Filcos) is as easy as clicking add and simply changing the respective pre-populated fields.

matt3o wrote:also... should we include *cough*membranes*cough*? (logitech, trust, microsoft, ...)

Haha why not!? This is the kbdb not some elitist Mechanical Only database (emodb)

Exactly! Interest in contributing is self regulating.

Here is a list of detail fields sorted by occurrences. (out of 164 keyboards/infoboxes)

In my opinion, it does not make sense to add to all keyboards things like
Switch mount
Actuation force
Contact mechanism
Switch type

These are things which belong to the switch article. In the keyboard article it should say switch = "[[MX black]]" and then you can click to see what an MX black is.

002 wrote:I'd be going with less mandatory fields than that. Probably just start with 'Name', 'Switches' and maybe 'Branding'. The rest could be simply set as 'Unknown' until someone comes along and populates the value

I agree to keep it with very little mandatory fields, but we also need a way to highlight those KBs that miss most of their data.

Muirium wrote:

• Case colour (Multiple choice between a few general options like: black, white, beige, grey, bare metal). Newbs ask about this a lot.
• Caps colours too. (Two pull down multi choice entries: one for alphas one for mods. Allow an exception case for crazy multi colour keyboards. Perhaps a field to specify whether mods are lighter or darker than alpa, which sometimes matters more than their specific categories.)

case color might be feasible... caps color is quite insane

Muirium wrote:

• Legends colours. Could get complex, see above and then some…
• Caps material: PBT, ABS, POM, metal, other? (Naturally this is for most keys. Could have a whole separate field for spacebars!)
• Legends are double shot, dyesub, lasered, or whatever?
• Case material. Plastic, metal, or what?

Caps material is important as well as legend printing technique. We have to find a solution about colors.

002 wrote:Haha why not!? This is the kbdb not some elitist Mechanical Only database (emodb)

LOL!

I agree we should include Logicrap.

7bit wrote:In my opinion, it does not make sense to add to all keyboards things like
Switch mount
Actuation force
Contact mechanism
Switch type

These are things which belong to the switch article. In the keyboard article it should say switch = "[[MX black]]" and then you can click to see what an MX black is.

Switch mount (plate/pcb) and type (MX black, ALPS Green, ...) are pretty important when you make a search. Actuation force, contact mechanism and other more tech stats I agree are pretty useless in the db.

Each switch (so Cherry MX black, blue, clear etc. are a distinct type each, and so is 45 vs. 55 g Topre) can be an entity in the database so that every keyboard can reference them. A simple multiple choice system would suffice at first, but a relational database allows classes of entity like that, right? (I honestly do not know.) Because if so, we build in encapsulation and so can do query sorts by actuation force across all keyboards later without messing up the data entry phase at all.

I do recommend multiple choice data over people's inconsistent typing: 55g 55 g 55 cn 55 c.n. 55 c. N. etc.

And it's also a good way to flag entries for follow up or feature requests. Always have separate options for "unknown" and "none of the above". Also allow manual flagging of entries for further work, and a comments field: "this one breaks the ergo categories", "the Apple II+ keyboard has been seen with both spherical and cylindrical profile caps".

Speaking of which: I say let in integrated keyboards like microcomputers, laptops and integrated terminals. They can be weighed and given the same dimensions as the whole machine if necessary! I'm yet to be swayed over typewriters though.

I think you skipped over the part that it is a scraper to make data accessible, not editable, to avoid data anomalies.

Muirium wrote:I do recommend multiple choice data over people's inconsistent typing: 55g 55 g 55 cn 55 c.n. 55 c. N. etc.

yeah I'd use dropbox or multiple choices whenever possible.

what do you think about customs, such as phantom, GH60, qhack or duckmini? should we cover them too?

webwit wrote:I think you skipped over the part that it is a scraper to make data accessible, not editable, to avoid data anomalies.

so your suggestion would be to make the wiki the parent/main site and build just a scraper for the DB?

Hmm. Seems a lot of foundations to build for a house we don't know the size of yet. Whatswrong with a one way scrape imported quick and dirty db << at first >> to see if this idea has got legs?

A regular structured data store like this could he a great source for the wiki in time. But it'll be bugger all if we don't actually start.

The pro of scraping the wiki is, like webwit said, the fact that there is no redundancy. The DB would import the wiki data every now and then and could make the already existing data accessible without the risk of creating anomalies between db<->wiki.

Customs deserve a place! (Like we are biased!) They can get a fuzzy load of "none of the above" fields for starters, but can be worked in later as the structure becomes clear. I would classify them as unavailable at retail, because whenever people suggest them to a newb's "best unicorn 60%?" question, they're shot down unless available fully built and preferably with warranty!

Perhaps have these options for the availablity field:

available new at retail
available in kit form
discontinued
custom made

okay, let me build the core structure and some UI. Eventually the project will grow on its own, otherwise I'll simply close it in the oblivion.

At the beginning I can easily sustain it myself but such a db will need backups and a dedicated space. Sorry to bring this up but it will come the day that I'll need a financial support

Muirium wrote:Perhaps have these options for the availablity field:

available new at retail
available in kit form
discontinued
custom made

yeah a flag like "limited series" or "custom made" or "group buy" should work

Muirium wrote:...
And it's also a good way to flag entries for follow up or feature requests. Always have separate options for "unknown" and "none of the above". ...
...

What about just use your database for finding keyboards where fields are missing, rather than having the "unknown" or "enter text here" fields in the wiki?

matt3o wrote:...
so your suggestion would be to make the wiki the parent/main site and build just a scraper for the DB?

The other way round will be unlikely work.

7bit wrote:

Muirium wrote:...
And it's also a good way to flag entries for follow up or feature requests. Always have separate options for "unknown" and "none of the above". ...
...

What about just use your database for finding keyboard where fields are missing, rather than having the "unknown" or "enter text here" fields in the wiki?

+1

With the JSON file of my script you could also easily fetch and filter for missing mandatory fields.

Knowing where the missing fields are is a different thing from knowing what to put into them.

I rarely contribute to Wikis because I fear stepping on other people's structure, oblivious to their implicit rules. I'd contribute much easier to a database where there's an automatic barrier between me and screwing things up.

Good thing about making the wiki the master is also the built-in version control.

Maybe a little wiki web form extension that helps editing the infoboxes in a valid way would make sense.

What about auto-generating an e-mail and sending it to the author of the last change.

Content:
error messages about the wrong infobox content and and advice how to do it right.