deskthority

I created the following site in part to solve a dispute between the unproven assertions of jacobolus and MouseFan over the history of Alps switches. The debate became one of trust, since there was no actual data on offer anywhere for my own assessment and I had to decide who was right and who was wrong based on which individual I felt was more competent. This was a ridiculous way to debate the subject, so I needed a way to store and present genuine raw data on actual keyboards.

Keycombo

There are no hard timelines: each date point is shown independently, with no assumptions being taken about where the timeline for any switch begins or ends. With enough date points present, the data should speak for itself.

An interesting example is Cherry MY. With the first examples entered, there was a very clear progression from type 1, through type 2, to type 3. As I encountered and recorded more examples, the picture became more and more confused:

http://telcontar.net/KBK/Keycombo/switc ... .php?id=49

It's clear that the amount of data points is still far too low.

This project is defunct. I built it in part to allow Sandy to record data on Omron switches, but the back end UI is simply too awful for anyone to use. Combined with the horrible SQL schema required to deal with the tangled nature of business practice, it would take a lot of work to make this site a fully-functioning service, and this isn't something I have any plans for.

At the moment, it stands simply as an example. All of rzwv's collection is there, as well as everything usable from nuibio's collection. I didn't include much if anything from Sandy as he was preparing a new website, but I've not heard from Sandy now in a long time. It's not a huge amount of data, but it is enough for demonstration purposes.

One difficulty I've found with gathering production data is that the data based on common date stamps for Alps switches - controller dates and case date wheels - are rather inaccurate, and can sometimes be off by several years.

That said, I think it's an admirable initiative to document the Alps timeline - particularly for documenting changes to individual switches over time. For example, with people's posted picture, you can already gather a reasonable timeframe for most of Alps SKCM Blue's developmental timeline, seeing which part got changed at what year, or at least roughly.

Although I'm on holiday at the moment and don't have the data with me, I'll happily make the dates of my (Alps) keyboards available if it might be useful.

As I said, it's defunct. Also, the data must exist in the form of permanently available disassembly photos for each keyboard, so that every date point can be fact-checked via a reference URL to the page containing the photos. (This is already true of all the entries, but even now a load of references are dead due to goings on with niubio's site, and I don't know what the latest is with that.)

There is provision though to record the controller, case, IC, label and PCB dates separately as well as internal and external serial numbers, so there is no need to worry about date accuracy. This is raw data only. In reality, the dates tend to be accurate, with Cherry being a notable exception. Date accuracy will be proportional to sales volume: the more you sell, the less you stockpile. (The RAFI RS 76 C Hall sensor ICs in the samples I got are HFO branded, and HFO—Halbleiterwerk Frankfurt (Oder)—is a Berlin Wall–era manufacturer!)

wait a second... "Daniel Beardsmore"?!?! Am I reading that right?! does it mean that... he... is... back?!

I checked your post history and you are back since 25 Dec! It's a Christmas miracle! Welcome back, mate! (oh and nice project btw!)

We have quite a few disassembly photos of Alps SKCL / SKCM based keyboards already, with the sheer volume of varaitions this data collection project is a longterm ongoing one.

Yes matt3o, I was "slightly suprised" also to say the least!

OK, this is what I had in mind. I don't imagine that anyone could ever face working with me on anything, let alone this, but this is what I think the roadmap would look like.

1. Location

Decide if this should have its own domain (e.g. keycombo.info), remain at its current URL, be a subdomain of Deskthority (inconsistent with the wiki), or a subdirectory of Deskthority (consistent with the wiki and should allow single-sign on, but can this privilege be justified and would it lead to a flood of “me too” requests?)

2. Name

Decide if a better name can be chosen! The name is kind of stupid, but my naming scheme is, otherwise, just write it in German, and that's not sufficiently catchy or imaginative.

3. Who and what?

Select a suitable front-end developer and back-end developer (could be the same person), and thence suitable frameworks with which to develop the software. My own website is only a 13-year-old template system which is why Keycombo in its present form is untenable.

The choice of both back-end and front-end will be determined in no small part by the nature of the SQL schema required as well as the complexity of object creation during the data entry wizard: one entry may require simultaneous creation of a new brand, new OEM, new OEM keyboard family, new customer keyboard family, new switch manufacturer, new switch series and multiple new switch types in addition to the keyboard itself.

Switch series can be nested (SKCL/SKCM → SKCL + SKCM) and anonymous (maybe we only know of one unidentifiable switch from that entire brand), and keyboards can attach to the OEM by way of a series or directly. It gets worse when you realise that a keyboard model can have multiple OEMs and multiple customers. If manufacturer A makes model A:1 for brand Z, they may also sell that to brand Y, while brand Z might have manufacturer B brand a similar model under their name. For the situation of one brand, one model, two OEMs, I've used the products table—originally designed for computers, terminals, typewriters etc—to hold the keyboards with more than one OEM.

Switch groups are for Alps clones, Cherry MX clones etc.

User logins will of course be required so that it can be self-serve, with a revision process to accept and reject entries, as well as security groups (administrators, moderators, users)

4. SQL

Vet the SQL schema. This is the current schema, with all the data types removed as Inkscape is being particularly fussy and obstinate tonight:
5. Getting back

Decide on a URL schema for objects; something friendly-looking instead of horrible heaps of random letters and numbers (/keyboard/5 or /brand/80 is nice, but I have a real distaste for gaps in auto numbering!) I've used autonumber IDs and those break every time I reshuffle them to fill in gaps. Stuff like ID=%(three hours of cat walking on keyboard) is vomit-inducing.

6. Scope

Is there any scope for this to be merged in with matt3o’s keyboard database (the name of which I can’t find any more), covering pricing and availability?

7. Stuff

Address the currently unaddressed concerns, such as:

1. brand history and ownership
2. whether image upload should be supported:
   1. of keyboards
   2. of switches
   3. of brand logos
3. keyboard taxonomy, for recognition purposes (see images, above)
4. additional properties (where do we draw the line with this; the ease with which these could be integrated into the UI and database, and by whom):
   1. layout
      1. physical layout
      2. logical layout
      3. number of keys (if non-standard)
   2. country of manufacture
   3. connector
   4. protocol
   5. colour(s)
   6. additional model number(s), especially with Cherry
5. Batch updating of references using regular expressions (already required for at least one site)
6. Dead reference detector
7. What we do about Topre
8. What we do about IBM
9. Batch reclassification wizard for splitting one switch type into multiple (e.g. if we ever agree on a consistent way to classify space invaders)

8. Moar

Address additional concerns and queries raised in relation to this post

9. Data migration

There's only 291 entries to be migrated in.