![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
"Like me, Phil [...] is often called upon to deliver spousal tech support. From his wife's perspective, Phil said, it looks like he knows how to do everything. But his own subjective experience is very different. He doesn't really have detailed procedural knowledge of most tasks. He's just very good at discovering that knowledge.
"'What I'm actually doing is figuring things out on the fly,' Phil said. That's what all IT adepts do, all the time. We do it in such a rapid, fluid, and automatic way that we don't seem to be constantly learning or relearning. [...]
"The clash of these cognitive styles -- knowing how to do things versus knowing how to find out how to do things -- is a source of friction between IT folk and our clientele. From our perspective, it's annoying to be asked constantly to write down detailed step-by-step procedures. If we don't rely on them, why should anyone else need to?
"From the prespective of the folks we support, on the other hand, it's equally annoying to have to figure things out. Why aren't things like turning off Smart Quotes just obvious? [...]"
-- Jon Udell, "Tacit Tech Support" ("Strategic Developer" column), InfoWorld, vol. 27, no. 25 (2005-06-20), p. 26
So true.
(no subject)
(no subject)
Just because I do not understand insertappnamehere, if it is
like asimmilarapp (even remotely) I could apply that knowledge.
Which is why I cringe every time I see a job description that
includes 'must know version xyz of abcdef'. I could care less if
someone knows the keystrokes to do a certain thing over and over, I
want them to be able to figure it out _without_ knowing the right
version of the right package. Or maybe even tell me there is a better
way of doing what I want to do with another application.
(no subject)
IT experts are also often not as good at remembering how to do specific procedures as this quote makes them sound. Smart IT folk DO document, for those times it's 3AM and they really need to remember how to do X instead of figuring it out again or relying on memory. When they don't, they email people like me. :P
I'm good at figuring things out on the fly. And I approach this from the dev side--I'm designing a server application from the ground up (not just the UI) now. But it's my job to make the app easy to use so that the admin can get on with their job as quickly as possible.
(no subject)
(no subject)
Because you have a limited amount of screen space. Seriously.
This is tangential to the main thrust of the quote, which is just demonstrating the duality of perceptions that are out there. But it came to me while reading that last sentence. Turning off Smart Quotes can't be obvious, because it might mean that creating a subscript or superscript would not be obvious, or changing font size, or style, or paragraph grouping, or... Just speaking for Word, I think they do put most of the options under as few layers of obscurity as possible (however, don't ask me what I think about their image placement handling if you don't want to hear a loud rant [1]). But it's supposed to be an incredibly functional program, with options crammed tight everywhere. There has to be some organization, and thus there has to be some layering.
I seriously think that any UI designer for programs like that has reached the bottleneck of screen space some time ago.
...You know, I think you just inspired an entry.
[1] Although it'll mostly concern their choices of default values in that case.
*cough* *ahem*
Speaking as a technical writer, you know, one of those people who makes an avocation -- and, perchance, a living -- at discovering all the metacognitive awareness of software and then writing it down logically and sequentially, it certainly improves the user experience to have good documentation. Unfortunately, due to most programmers' lack of craft in the art of writing words (instead of code), and most PHB's lack of understanding that well-crafted documentation isn't just a loss-leader (why, it actually cuts down on tech support calls and makes users happy -- can't have that!), there's perishin' little good documentation out there.
The funny thing is, not only do technical writers have to have that intuitive grasp of new software (I've had clients give me completely undocumented late-alpha applications -- no notes, no rudimentary help, no source), but we also have to have the kind of skills that can take that gleaned knowledge and turn it into something useful without confusing or condescending to the reader, and/or falling into the dreaded "Comprehensible Only If Known" problem (the phenomenon whereby if and only if you already know how to do everything with the software, the documentation makes perfect sense).
Granted, a good help file, online tutorial, and quick-start help sheet laminated and stuck to the desk still won't solve the habitual "'RTFM' stands for 'Ring The Family Maven'" problem, but it's a start.