Wiki Q and A

[Daniel Beardsmore]

I don't think it is realistic to expect Webwit to set the rules here. The people who edit the wiki the most should, IMO.

My point is, I am not expecting anyone to set rules. It's not practical to expect everyone to be able to desolder or have superb manual dexterity, or set up a photography studio. It's a case of simply making a good effort and paying attention to what you are doing. Make sure your browser has a spelling checker and English dictionary enabled. Use existing pages as a guide for new pages.

If you were club members¹, you would be welcome to invite the club members to vote on granting permission for authoritative rules, but it's not my leaning.

As purdobol pointed out this is a sure way not to ever have a set of pictures with the same aspect ratio.

Considering that I provided the method by which I achieve consistent aspect ratio, I don't understand what either of you are doing wrong. You need to learn how to use whatever software you have chosen.

Just general rules. How the keyboard/switch variants are presented at wiki pages. Are they ordered alphabetically, by the model number? Ansi first Iso later and so on...

I tend to present switches in variants tables in the order basic → feature, light → heavy. e.g. standard weight momentary comes first, and feature versions like alternate action and illuminated come later. Keyboards, I may present in manufacture date order, or model number order if this differs.

Do I need to desolder whole switch and present every single part in "dissasembly" photo for example (including housings). Or just focus on "different" parts.

This is definitely something that I cannot set a rule on, because the feasibility varies by switch and manual dexterity level. With some switches, the second greatest time sink after photo retouching is trying to find parts that have gone missing. Full disassembly is always welcome but I could never require it.

Or in case of PCB's witch parts are preffered to take a closer look etc. Again some general guides.

That is one thing that I may one day document formally. Anything with a code or date, in essence. All the ICs, as they collectively help date the production run, and any codes. Some codes you instinctively know to ignore (such as flammability standards) but all other codes have potential clues as to age, origin or model.

Basic guide of good practices while photographing small parts and whole keyboards would be nice. How to improve lighting, best camera settigs and so on. Just basic tips, easy to follow or just common mistakes easy to avoid while doing this stuff.

Don't ask me, my photos are terrible :P

If we had one or two people who were committed to taking high-quality photo sets (macro shots, full disassembly), then it could be argued that all the switches should be donated them for this purpose. In practice, people make claims and never deliver, so it's up to each person to find their own way with whatever equipment they have in whatever living or working space they have available. The best person to offer advice is the person who's achieving what you want to achieve.

I feel that my photo aesthetics are excellent, but the pictures are low resolution, noisy and fuzzy and getting that aesthetic is so tedious that I've largely given up. I trawl through the photos I took and can't find enough that are good enough to save. Plus, with my current working area, I'm forever losing parts.


¹ Tactica is club member "-" while purdobol lacks this field.

[tactica]

All right, I see what you mean now. Never used IrfanView before actually... Yes, this would work to keep the same proportions every time, at most you would only need to tinker with the gallery height to adapt to whatever aspect ratio you are using.

¹ Tactica is club member "-" while purdobol lacks this field.

Nope, I'm not.

[codemonkeymike]

¹ Tactica is club member "-" while purdobol lacks this field.

Nope, I'm not.

I think what happened is the way new members are created, because most members who made their account over a year ago have "-" for the "club member" field while newer members don't have the "club member" field. odd.

[Daniel Beardsmore]

I imagine it works, since I've been doing it that way for several years ;-)

[Daniel Beardsmore]

With the change [[power keys]] → [[[wiki]power key[/wiki]]]s, does this make sense? I mean, none of the keyboards in question have a Macintosh power key, and I would be surprised to find a keyboard with three power keys on it.

While it's true that the article (in fact, called "Power button") does note "Keyboards designed for Windows sometimes feature a bank of keys for controlling power and sleep states." it is largely centred around the specific button previously found on Macintosh computers (hence power "button" as it was often not a normal key, although on some keyboards it was).

I'm not even sure whether a button called "Power" would still boot up a PC when it is shut down, and as there are several power buttons/keys, then "power keys" (or maybe "power control/management keys") should be a separate page specific to whatever it is that these keys do or did on a PC. (I had a keyboard with power keys on, once, and I seem to recall that none of them did anything — that was years ago.)

Or at least, if it the page is to cover all power control and management keys from all operating systems, then should it not be renamed back to "power key" instead of "power button"?

What's frustrating is that multimedia keyboards (which incidentally I only use as a category when they make more than a miserable token effort) never seem to come with documentation explaining what the keys do, and often you can't even tell by looking at the keys. For the power keys, it would be nice to be able to read this off from the manual, since I don't have a USB keyboard with those features.

[Findecanor]

Personally, I prefer "Power button". Many keyboards give the button a different shape to differentiate it from regular keys. Only relatively recently have it become common on laptops to use a chiclet key in the top/right corner of the keyboard instead ... but then chiclet laptop keyboards seldom show good example of good human interface design.

Microsoft's "Keyboard Scan Code Specification" for Windows (scancode.doc) lists two "power management buttons": "POWER" and "SLEEP".
When the host is awake they should send "System Power Down" and "System Sleep" respectively, but when the host is asleep they should both send "System Wake Up". There are both USB HID "usage codes" and PS/2 "scancodes" for these three.
In the USB HID spec, the "usage codes" are supposed to be wrapped in a "collection" (i.e. section) in the protocol called "System Control".

I had listed the codes in the Media key article and called them "System control keys" even though they do not really belong there and they are two keys instead of three ...

[Daniel Beardsmore]

Many PC keyboards have them as regular keys like any other, though, which makes it more awkward. Normally it's three keys on older keyboards. The Focus FK-2001 has Power, Sleep and Wake in the 108-key version, as does the Tai-Hao F21-HQ.

I would argue that "power keys" makes more sense, in that keyboards with little flat buttons for the power functions no more make this concept "power buttons" than keyboards with similarly-sized function keys give you "function buttons". However, with the Macintosh, the power button was a single, distinct button, but even then, you had keyboards where it was a normal key. In the case of the Apple (Standard) Keyboard, it was a regular Alps switch under the button.

[tactica]

Multimedia keys largely depend on support from the OS or 3rd party utilities. This IBM KB-7993 I'm typing on (don't ask) is meant for Windows 95/98, and the single power key it has does nothing on Windows 7 or Linux. Most of the other keys are programmable, and either do nothing or they do something they shouldn't because the relevant driver is missing. I researched the matter a long time ago, turns out someone worked on a driver to use the extra functionality but the code won't work on anything more recent than Win98 anyway. Certainly not on a 64 bit OS. Mind you, the active PS/2 to USB converter in the middle doesn't exactly improve matters, either. I'm absolutely unable to enter Alt key codes for example.

chiclet laptop keyboards seldom show good example of good human interface design.

Methinks you're giving chiclet too much credit if you think there's a single unit worth using out there.

[Myoth]

I find that the beamspring keyboard wiki page is too complicated to identify the beamspring keyboards, I'm thinking of making a simple list of the beamspring keyboard for easier identification. The wiki will have a very simple list of all of the beamspring keyboards and one with all the details about them and their original Terminal they came with (or the contrary ?).

What do you guys think of this ?

[Myoth]

So I was working on the page I talked about in the earlier post, now the problem is why is there not a mix of [gallery]x.jpg[/gallery] and Embedding a simple file, I wanted to get text in the frame but embedding a file does not respect the other syntax, while gallery does. Is it possible to mix both and have embedding respect the other syntax and have a framed text ?

there is a fix to this as it is, by simply loads of space between the embedding and the other text, but I feel like that's not the best way to fix this.

[seebart]

So I was working on the page I talked about in the earlier post, now the problem is why is there not a mix of [gallery]x.jpg[/gallery] and Embedding a simple file, I wanted to get text in the frame but embedding a file does not respect the other syntax, while gallery does. Is it possible to mix both and have embedding respect the other syntax and have a framed text ?

there is a fix to this as it is, by simply loads of space between the embedding and the other text, but I feel like that's not the best way to fix this.

Am I understanding you correct that you mean text "floating" around the pictures like this?

Spoiler:

wrapp_all_arround.png (216.54 KiB) Viewed 20347 times

[Myoth]

yes, embedding a file make the text float around like that, whereas gallery makes it go to the bottom of the picture, and I would like to combine the both of them to have a framed description and the text at the bottom of it.

[seebart]

yes, embedding a file make the text float around like that, whereas gallery makes it go to the bottom of the picture, and I would like to combine the both of them to have a framed description and the text at the bottom of it.

No I dont think thats possible but I really dont know.

[Myoth]

yes, embedding a file make the text float around like that, whereas gallery makes it go to the bottom of the picture, and I would like to combine the both of them to have a framed description and the text at the bottom of it.

No I dont think thats possible but I really dont know.

The fix looks like this



This is definitely not pretty, but at least it works

[seebart]

This is definitely not pretty, but at least it works

Interesting! Im sure tactica will enjoy it when I use this.

[Daniel Beardsmore]

I assume you want the section break:

{{-}}

I tend to remove it as people use it unnecessarily creating strange gaps in the page, but it might help here. However, I would use <gallery> in this case, as I generally do everywhere else when I want images in-line within a page section.

Also, I assume you plan to use {{main|…}} to link to each article?

[tactica]

So I was working on the page I talked about in the earlier post, now the problem is why is there not a mix of [gallery]x.jpg[/gallery] and Embedding a simple file, I wanted to get text in the frame but embedding a file does not respect the other syntax, while gallery does. Is it possible to mix both and have embedding respect the other syntax and have a framed text ?

The fact that directly embedding a picture forces an embedded caption is probably intended, because otherwise floating text around the picture would make the layout confusing if the caption is also floating, at least if the floating text reaches the bottom of the picture.

[Myoth]

I didn't say that it was intended or not, I said that I would have like to know if there was a mix of them both. Which there is not.

Now onto the next topic, the Beamspring Simplified list :

You're right, I will simply just edit the main one, though I'll be revamping it all up because there is quite a bit of non-sense, like why is it that in the "3277 and related", there is no mention of the 3278 ? I'll take the simplified list and add the text from the main one. It'll be much easier to scroll through.

[Daniel Beardsmore]

It's just good to see lots of wiki activity — very promising!

[Myoth]

Wikifying is actually and incredibly satisfying to do , will defintely keep wikifying things !

[Myoth]

I think this would be quite cool, to picture IBM timelines, Alps timelines, MX timelines, etc

https://en.wikipedia.org/wiki/Wikipedia ... ine_Tracer


EDIT : I say that because we can't at the moment but I think it would be a cool addition to the wiki.

[Daniel Beardsmore]

Are you sure that the add-on does what you think? You seem to have this in mind:

https://www.mediawiki.org/wiki/Extension:EasyTimeline

My feeling on switch timelines using graph bars is that they hide the level of uncertainty in the data. For example, if you look at the data point graphs for Cherry MY you'll find it's full of gaps, and the level of data points at present is far too low to offer any kind of certainty that the limits of the graph are accurate:

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

I realise that in some cases—per [wiki]Keyswitch timeline[/wiki]—we have definitive dates, but often we only have one end of the graph, so we are still limited to showing data points.

I feel that we are still in the data gathering phase for most switch types, and that this is where the focus should be. Integrating this into MediaWiki though would be very difficult.

[Myoth]

Are you sure that the add-on does what you think? You seem to have this in mind:

https://www.mediawiki.org/wiki/Extension:EasyTimeline

I was thinking about this : https://fr.wikipedia.org/wiki/Blue_%C3% ... #Evolution

My feeling on switch timelines using graph bars is that they hide the level of uncertainty in the data. For example, if you look at the data point graphs for Cherry MY you'll find it's full of gaps, and the level of data points at present is far too low to offer any kind of certainty that the limits of the graph are accurate:

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

While this is true, it's not really relevant for this since as you can see on the graph I linked up there, Allen Lanier had a period where he hasn't done anything, so that way it could still work, you can put spaces in the bars whenever we don't know if they were available.

I realise that in some cases—per [wiki]Keyswitch timeline[/wiki]—we have definitive dates, but often we only have one end of the graph, so we are still limited to showing data points.

I feel that we are still in the data gathering phase for most switch types, and that this is where the focus should be. Integrating this into MediaWiki though would be very difficult.

Yes, we sure are, I really need to help you on that.

[Daniel Beardsmore]

While this is true, it's not really relevant for this since as you can see on the graph I linked up there, Allen Lanier had a period where he hasn't done anything, so that way it could still work, you can put spaces in the bars whenever we don't know if they were available.

I am also showing the count of data points per time interval, so that you can view readily the amount of data gathered and how that itself is distributed.

[twinrotor]

I looked around and didn't see anything on the forums or the wiki for literature that would have came with keyboards. Am I missing it?

[Daniel Beardsmore]

See under [wiki]Category:Deskthority media[/wiki].

[twinrotor]

See under [wiki]Category:Deskthority media[/wiki].

Thank you sir.

[webwit]

Hmm, am I looking at the wrong Alps series in the wiki (SKCP), or are these on this 5576-002 different?

[Daniel Beardsmore]

The identifying shot for SKCP is here:

photos-f62/canon-typewriter-keyboards-t4242.html

Yours above look the same.

It seems that there are versions without the plate retention clip bars, as shown in the photos on the SKCP wiki page. Maybe those are another series (like SKCO or SKCQ), or maybe they are just a variant model. It's highly unlikely that we will find out!

[ScottPaladin]

What's the correct protocol for making references off ecommerce sites? I've spotted a couple of versions of a keyboard with diferent switches from the wiki and I'd like to document, but I know when somebody buys these things, the relevant pages will go up in smoke.