Re: client requirements for hardware-related inline elements

To check off my action item from 9/17, here are my thoughts on the “things you press” discussion.

For my clients, the question of whether everything is a <uicontrol> or not boils down to whether they have both hardware and software that must be interacted with in the same process. It is not always obvious to the user where they should be looking for a control, especially as more and more software controls are added to traditionally hardware based things, like cars and heavy equipment. In these cases, clients tend to take one of the following tactics:

1 – They are precise and careful with their verbs. You click, select, or touch software buttons, you press hardware buttons, for example. Physical locations are panels; software locations are screens. But often these are seen as subtle differences that they aren’t convinced users understand. In many cases, the software interface is designed to emulate hardware controls, so verbs like move, dial, slide are more difficult to define to one or the other. Of course, they can explicitly state “on the blah blah screen, slide”, or “on the blah blah panel, slide” to give the location. Clients in this category either just use <uicontrol> for everything or they don’t make any distinctions at all.

2 – Clients want a visual distinction in their instructions to either avoid awkward location phrasing in the instruction or to supplement the instruction. In this case, most right now use <uicontrol> for software and <uicontrol outputclass=”hw”> (or similar). In this case, they really see the tag only as a means to an end for formatting and they use the outputclass to put some kind of special font or brackets or the like around the name of the object (ie [Return] for the key; Return for a software button). In my opinion, if all they are tagging for is formatting. The outputclass solution is adequate. They may not like that the name <uicontrol> doesn’t sound exactly right for their hardware control, but they really aren’t about semantics anyway.

3 – Some clients want the semantic difference because the pieces parts are part of their overall taxonomy. The taxonomy includes whether something is a key, a button, a slider, a wheel, a dial, a lever, etc. In these cases the tagging most often has nothing to do with formatting (they don’t for example bold every control on their hardware. “Use the tuning dial to find your station”; not “use the tuning dial to find your station.”) But it is important to tag them to reflect the taxonomy. For example often these items are associated with parts and part of their distinction for tagging is that a part number might be associated with them in service manuals. So the same element in an operator manual would just say “rotate the dial”, while in a service manual the context is different and they “replace the dial (P/N 121324)”. Ie, the hardware element might have a part number attribute that is output in some contexts, but would be the same tag in both places so the taxonomy relationship exists even if the output is different. In some cases it’s not so important that it’s a dial as opposed to a lever, just that it’s a part with a part number. In others it is important to make the distinction – you turn a dial, you pull a lever. Honestly, there is a parallel issue with the software domain. I have hundreds of clients who object to <uicontrol> to mean field name, radio button, checkbox, button, etc. and who want more granular semantics, again, not to make a distinction visually, but to support their taxonomy.

If my client is exclusively a hardware company, they have less of an issue just using <uicontrol> as is for their needs, or they fall into group 3 above.

I see potentially a couple of simple solutions without opening a huge can of worms of where might the tagging stop.

Potentially a simple solution to address both problems would be to simpl add an optional @type attribute on <uicontrol> – what type of uicontrol is it; type= button, field, etc or even “hw_button”, “dial”, “lever”

Given the possible number of values for that type attribute and the objections that some have of whether a hardware control falls under the auspices of a user interface, perhaps we add a separate <hwcontrol> element that also has an optional type attribute and possibly an optional part number attribute.

A more complex solution of adding an entire a hardware domain would be to have a <hwcontrol> element certainly, but to also consider other possibilities such as partnumber. In fact, this might consider distinctions made in machinery task – is it a part, or a spare, or a supply, or equipment, or a tool, etc. My personal feeling here is that for the same reason we only offer <uicontrol>, <menucascade>, and <wintitle>, we should limit how deep we would go here.

Hopefully, my ramblings make sense and are useful to our discussion.

Best,

Dawn

dita message