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:
- Keycombo schema.png (199.82 KiB) Viewed 1838 times
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:
- brand history and ownership
- whether image upload should be supported:
- of keyboards
- of switches
- of brand logos
- keyboard taxonomy, for recognition purposes (see images, above)
- 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):
- layout
- physical layout
- logical layout
- number of keys (if non-standard)
- country of manufacture
- connector
- protocol
- colour(s)
- additional model number(s), especially with Cherry
- Batch updating of references using regular expressions (already required for at least one site)
- Dead reference detector
- What we do about Topre
- What we do about IBM
- 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.
