Went to Armuchee (BTW, pronounced Ar-mur-chee) for a Memorial Day Bluegrass festival. Camped and jammed for two nights. I packed up tired and a little down, thinking about how good I should be playing--compared to the folks I jammed with. Got home and let the Dobro sit a day. Opened it up yesterday and felt all excited about how good I could be playing if I keep at it.
Bluegrass just keeps teaching me about a lot more than music. We shackle ourselves with expectations and drag them around with us like Jacob Marley's chains. It's good to aspire to be better, just don't forget to enjoy where you are in the moment.
Tuesday, May 31, 2011
Monday, May 23, 2011
Focus, Focus, Focus
If you want to get someone's attention, you have to get their focus. There are two ways to do this:
I love my email client and I am loathe to use them as a negative example, but they really blow it on method 1 when it comes to adding new contacts. Although I remember each time I go to do it that it does something weird, every time I'm left helpless and frustrated for two minutes until I relearn it. See if you can figure it out:
There is a New contact button way over in the left-hand navigation section. As Norm McDonald would say, "Wait..what??!!" Why is it in a navigation section and why is it out of my field of focus? I would have put it with the other buttons at the top of the Contacts working panel.
Speaking of focus, I once did an illustration where I showed a user focusing on a screen--it looked something like this:
Everyone told me I had the arrow going the wrong way. Interesting that we think of vision and focus as something we project outward into the environment, as opposed to a filtered taking in of stimuli from the environment.
Addendum: After giving it some thought, I thought this might be the more accurate illustration:
- Figure out what they are currently focusing on and step in front.
- Wave your hands and holler until they shift their focus to you.
I love my email client and I am loathe to use them as a negative example, but they really blow it on method 1 when it comes to adding new contacts. Although I remember each time I go to do it that it does something weird, every time I'm left helpless and frustrated for two minutes until I relearn it. See if you can figure it out:
There is a New contact button way over in the left-hand navigation section. As Norm McDonald would say, "Wait..what??!!" Why is it in a navigation section and why is it out of my field of focus? I would have put it with the other buttons at the top of the Contacts working panel.
Speaking of focus, I once did an illustration where I showed a user focusing on a screen--it looked something like this:
Addendum: After giving it some thought, I thought this might be the more accurate illustration:
Friday, May 20, 2011
Birthday Resolutions
I turn 62 tomorrow, and I feel that's a good occasion to set some self improvement goals:
- Play slower
- Play softer
- Play more precisely
- Play more artistically
Thursday, May 19, 2011
Musical dimensions
I am a hopeless Aristotelian; I love to create classifications and taxonomies that make neat little boxes and then I put hopelessly messy realities into them. On my ride into work today, I created a way to classify all musicians (or more accurately the ways we are musicians) along two axes--thus creating four quadrants within which I can box myself or others.
The two axes are
There is nothing judgmental about this system, nor is one's position in a quadrant fixed. I, for one, can be found in quadrants I, II, or IV depending on when you snap the picture.
I do think, however, that your dominant quadrant can shape how you play. For example, I spent most of my life in quadrant I, playing folk songs on the guitar by ear and writing my own music. When I started learning Dobro, I stayed in that mode pretty much exclusively. As such, I have a tendency to want to maintain a full picking pattern as "background" and pick the melody line out as I lay down a carpet of notes around it.
I have a buddy who is primarily quadrant II. He's quite literate on piano, and although he learns guitar songs by ear, he can play a very literal rendering of the source he learned the song from. I don't do so well at learning by ear because I have a dyslexic ear. 1. 3. 5 and 1, 5, 3 sound alike to me. Or if I get 5 out of 7 notes, well that's as good as all 7. Unfortunately, playing by ear has been my learning style most of my life.
I've started operating in quadrant IV a lot--participating regularly in bluegrass jams, and this has driven me to quadrant II. I try to learn a song from a jam, but I can tell I'm not quite "getting it." So I have started to read music so that I can get the melody line correct. Then I arrange it for the Dobro. But my quadrant IV perspective has made it so I am not as compelled to lay down the carpet of notes any more. I'm getting used to having others establish the full body of a song, and I am learning to add grace licks or transitions. And since the Dobro does not play certain chords very well (open tuned to a G-major), I'm learning to pick through those awkward chords with delicate melody or harmony lines rather than playing robust multi-string chords.
I'll probably never get to quadrant III, although I envy those folks. That's where most session musicians operate, you know, folks who get paid to play. It's OK, just moving into II and IV has rejuvenated my appreciation of music and my enjoyment.
Be careful about quadrant IV, though, that's a real addictive neighborhood.
The two axes are
- Social--essentially a binary axis of "plays alone" and "plays with others"
- Literal--"free style or creative" on one end and "plays it like it's written" on the other
There is nothing judgmental about this system, nor is one's position in a quadrant fixed. I, for one, can be found in quadrants I, II, or IV depending on when you snap the picture.
I do think, however, that your dominant quadrant can shape how you play. For example, I spent most of my life in quadrant I, playing folk songs on the guitar by ear and writing my own music. When I started learning Dobro, I stayed in that mode pretty much exclusively. As such, I have a tendency to want to maintain a full picking pattern as "background" and pick the melody line out as I lay down a carpet of notes around it.
I have a buddy who is primarily quadrant II. He's quite literate on piano, and although he learns guitar songs by ear, he can play a very literal rendering of the source he learned the song from. I don't do so well at learning by ear because I have a dyslexic ear. 1. 3. 5 and 1, 5, 3 sound alike to me. Or if I get 5 out of 7 notes, well that's as good as all 7. Unfortunately, playing by ear has been my learning style most of my life.
I've started operating in quadrant IV a lot--participating regularly in bluegrass jams, and this has driven me to quadrant II. I try to learn a song from a jam, but I can tell I'm not quite "getting it." So I have started to read music so that I can get the melody line correct. Then I arrange it for the Dobro. But my quadrant IV perspective has made it so I am not as compelled to lay down the carpet of notes any more. I'm getting used to having others establish the full body of a song, and I am learning to add grace licks or transitions. And since the Dobro does not play certain chords very well (open tuned to a G-major), I'm learning to pick through those awkward chords with delicate melody or harmony lines rather than playing robust multi-string chords.
I'll probably never get to quadrant III, although I envy those folks. That's where most session musicians operate, you know, folks who get paid to play. It's OK, just moving into II and IV has rejuvenated my appreciation of music and my enjoyment.
Be careful about quadrant IV, though, that's a real addictive neighborhood.
Wednesday, May 18, 2011
The Cost of Lost Productivity--Myth?
In a very ironic twist, while working today, I took a Twitter link to a web article that discussed the distractions that keep us from working. It was like one of those dream inside a dream things in Inception. The article showed statistics for the things that distract us (like social networks and reading Internet articles). It did some quick math and concluded "That hour per day translates into $10,375 of wasted productivity per person per year, assuming an average salary of $30/hour."
I see this reasoning a lot, especially in ROIs and such. "By reducing the support desk's search time by 15% we would save $375,000 a year, justifying the addition of three positions to overhaul and maintain the new knowledgebase files."
The flaw is this: If given that hour back, most people would not get an hour's more work done. Especially the kinds of workers who are in a situation where they can get distracted by email and Internet related things.
I was at an STC conference once where a panel was discussing trends and the topic came up of how technical communicators could show their value. One person made an argument similar to the one above, "By making the support group more efficient we can save $x.xx per year in support costs." I pointed out that in my company (not IBM at the time, BTW) such a claim would have to be supported by the Help Desk manager committing to reducing the head count by that equivalent amount. Otherwise, the money will not have been saved. Jeez, you would have thought I was advocating euthanasia.
But it pointed out the fallacy of the argument. If you really were making folks 15% more efficient, then you should be able to get by with 15% less people. The unwillingness to advocate the headcount reduction shows a lack of faith in the assumption.
We all need to be a little bit skeptical of these "productivity" arguments that assume more output automatically follows more bandwidth. ROIs are bogus unless the customers are writing bigger checks or the company is writing smaller checks.
Now, I need to get back to work.
I see this reasoning a lot, especially in ROIs and such. "By reducing the support desk's search time by 15% we would save $375,000 a year, justifying the addition of three positions to overhaul and maintain the new knowledgebase files."
The flaw is this: If given that hour back, most people would not get an hour's more work done. Especially the kinds of workers who are in a situation where they can get distracted by email and Internet related things.
I was at an STC conference once where a panel was discussing trends and the topic came up of how technical communicators could show their value. One person made an argument similar to the one above, "By making the support group more efficient we can save $x.xx per year in support costs." I pointed out that in my company (not IBM at the time, BTW) such a claim would have to be supported by the Help Desk manager committing to reducing the head count by that equivalent amount. Otherwise, the money will not have been saved. Jeez, you would have thought I was advocating euthanasia.
But it pointed out the fallacy of the argument. If you really were making folks 15% more efficient, then you should be able to get by with 15% less people. The unwillingness to advocate the headcount reduction shows a lack of faith in the assumption.
We all need to be a little bit skeptical of these "productivity" arguments that assume more output automatically follows more bandwidth. ROIs are bogus unless the customers are writing bigger checks or the company is writing smaller checks.
Now, I need to get back to work.
Tuesday, May 17, 2011
A turn in the road
Ta da! A new brand for my blog. I turn 62 this month--three score and twain--and I feel like it's time to shift my life focus a bit. I'm not changing it entirely, more like broadening it. My tag line still mentions technology, but it now encompasses music and social interaction. And my professional associations and credentials have given way to other associations by which I am defining myself more and more.
In spite of my opening this blog with a mention of my age, I don't see this as a maturing process, not even a moving on (which is a lot like "moving away from"). It's more of a "staying in motion" thing.
As my buddy, Miranda, has wisely told me, "Your gear is your fear." I've dropped some of the credentials that said "I'm smart," but I have replaced them with mentions of clubs that say "I belong." Maybe there is a Maslow's hierarchy of fears theme here.
As my mentor, Carol Barnum, has often said, "Writing is thinking." I'm going to write about different things, or at least write more about things I care about outside of technical communication and software design. I'm afraid of thinking the same old thoughts over and over again. My brain wants to think new thoughts.
Please stay tuned and think some of these new thoughts with me.
In spite of my opening this blog with a mention of my age, I don't see this as a maturing process, not even a moving on (which is a lot like "moving away from"). It's more of a "staying in motion" thing.
As my buddy, Miranda, has wisely told me, "Your gear is your fear." I've dropped some of the credentials that said "I'm smart," but I have replaced them with mentions of clubs that say "I belong." Maybe there is a Maslow's hierarchy of fears theme here.
As my mentor, Carol Barnum, has often said, "Writing is thinking." I'm going to write about different things, or at least write more about things I care about outside of technical communication and software design. I'm afraid of thinking the same old thoughts over and over again. My brain wants to think new thoughts.
Please stay tuned and think some of these new thoughts with me.
Thursday, May 12, 2011
Click of Recognition
For every wise adage, there is an opposite and equally wise counterpart. "Fools rush in where wise men fear to tread" can be countered by "He who hesitates is lost." I bring this up because I am going to talk about the acceptability of acting on data from a scant sample, as in n=1. Big disclaimer up front: Don't do it all the time without careful consideration of the context. That having been said...
In qualitative research there is a phenomenon known as the "click of recognition" that the researcher can experience. In UX terms this means that sometimes we hear a user say something or see her do something and a light goes on. We have a clarifying moment or epiphany if you will. That is because in user research, the user is often a lens through which we see the application with our own preconceptions and biases filtered out. Something that seemed so crystal clear to us suddenly becomes vague or ambiguous when we see that same widget or paragraph through someone else's frame of reference.
How can you make decisions based on the input of just one user? Let me give some examples from a writing perspective. In doing so, I'm going to go through my "hierarchy of clicks."
Let's say I have written something, and I give it to my wife to look at. She sees a misspelled word and points it out. Do I say, "Thanks, but let me have twelve other people look at it too." No. It's wrong, I know it's wrong, I was just too close to it and didn't catch it. Little miss fresh eyes did, and I make the change based on an n of 1. The UI equivalent is a bug, or where I failed to apply a known and widely accepted best practice. It takes one user stumbling on it to trigger a click of recognition.
Now my wife keeps reading and comes across the sentence "Tom told Dick to fire Harry, and it made him mad." She makes the following observation, "I'm a bit confused about which of these characters you mean by 'him.' Was Tom mad because he had to tell Dick how to do his supervisor's job, was Dick mad because Tom was making him do the dirty work, or was Harry mad because he was getting fired?" Hmmm. Crystal clear to me when I wrote it because I knew whom I was referring to. Now that I have her lens, I can see how ambiguous (or triguous) the referent is. Do I need to get another opinion? Politics of marriage not withstanding, no. Now that I see someone else's reasonable take on it, I have a click of recognition.
But then she says, "Times New Roman is so boring, I think you ought to use Verdana." "Thanks," I reply while making a mental note to get twelve other opinions.
In qualitative research there is a phenomenon known as the "click of recognition" that the researcher can experience. In UX terms this means that sometimes we hear a user say something or see her do something and a light goes on. We have a clarifying moment or epiphany if you will. That is because in user research, the user is often a lens through which we see the application with our own preconceptions and biases filtered out. Something that seemed so crystal clear to us suddenly becomes vague or ambiguous when we see that same widget or paragraph through someone else's frame of reference.
How can you make decisions based on the input of just one user? Let me give some examples from a writing perspective. In doing so, I'm going to go through my "hierarchy of clicks."
Let's say I have written something, and I give it to my wife to look at. She sees a misspelled word and points it out. Do I say, "Thanks, but let me have twelve other people look at it too." No. It's wrong, I know it's wrong, I was just too close to it and didn't catch it. Little miss fresh eyes did, and I make the change based on an n of 1. The UI equivalent is a bug, or where I failed to apply a known and widely accepted best practice. It takes one user stumbling on it to trigger a click of recognition.
Now my wife keeps reading and comes across the sentence "Tom told Dick to fire Harry, and it made him mad." She makes the following observation, "I'm a bit confused about which of these characters you mean by 'him.' Was Tom mad because he had to tell Dick how to do his supervisor's job, was Dick mad because Tom was making him do the dirty work, or was Harry mad because he was getting fired?" Hmmm. Crystal clear to me when I wrote it because I knew whom I was referring to. Now that I have her lens, I can see how ambiguous (or triguous) the referent is. Do I need to get another opinion? Politics of marriage not withstanding, no. Now that I see someone else's reasonable take on it, I have a click of recognition.
But then she says, "Times New Roman is so boring, I think you ought to use Verdana." "Thanks," I reply while making a mental note to get twelve other opinions.
Tuesday, May 10, 2011
Eight ways...
I'm going to be running a meeting online in which I'll be showing design concepts to key customers to get their input. One of the product managers can't make it and asked me if I would be recording the session.
It caused me to remember a class I took about 20 years ago in Instructional Technology. The instructor was covering "slide presentations" (yes, I'm THAT old) and said, "There are eight ways to put a slide into a slide tray, and seven of them are wrong."
Sort of summarizes my current feeling about the risks we incur any time we add technology to a meeting or presentation.
I told the product manager, "No."
It caused me to remember a class I took about 20 years ago in Instructional Technology. The instructor was covering "slide presentations" (yes, I'm THAT old) and said, "There are eight ways to put a slide into a slide tray, and seven of them are wrong."
Sort of summarizes my current feeling about the risks we incur any time we add technology to a meeting or presentation.
I told the product manager, "No."
Thursday, May 05, 2011
Three Mistakes in Social Media
Three mistakes we make when participating in social media:
- We fail to recognize that there ARE multiple realities. It is possible for two diametrically opposed positions to both be right--if you account for perspective. This mistake manifests itself by someone saying "You are wrong," when the more accurate statement should be "I have a different perspective."
- We vilify those we disagree with. "You are wrong," becomes "You are evil," or "You are a troll."
- We comment on political or social issues in inappropriate forums. for example, a website for Bluegrass musicians is not a good place to discuss bin Laden's death.
Tuesday, May 03, 2011
Association of Technical Communicators
I just had a blog posted at the ATC website. I talk about how technical communicator skills can be useful as a UX architect.
By the way, I really like this new group and the community website. Give them a look over at http://www.mytechcomm.org/main/summary.
By the way, I really like this new group and the community website. Give them a look over at http://www.mytechcomm.org/main/summary.
Thursday, April 28, 2011
The Art of Losing
I lost an argument yesterday.
Essentially, I proposed "to-may-to," a peer countered "to-mah-to," I rebutted with some additional facts, and the boss chimed in with "I like to-mah-to."
My first instinct was to rebut again and make my points again but stronger. But my experience and executive overrides kicked in and I reminded myself of an old adage "Before you can influence others, you must first allow yourself to be influenced by them." This has led to my own adage: "Never squander an opportunity to lose an argument." Losing can be good; it gains you equity with the team if you do it gracefully. Here are some points that help me when I need to lose (or when I'm going to lose anyway).
Truth is, most people do not remember who made specific points in a meeting. More times than not I hear the wrong person being credited with a particular statement. What people will remember, however, is how well the teams you are on end up doing.
Don't seek a reputation of being the "guy with the answers." Instead, become the "guy who initiates and facilitates productive conversations."
And many times that means both making the initial proposal and then graciously losing the argument that ensues.
If I weren't so naturally talented at making the wrong proposal, I'd probably have to do it on purpose just to get ahead.
Essentially, I proposed "to-may-to," a peer countered "to-mah-to," I rebutted with some additional facts, and the boss chimed in with "I like to-mah-to."
My first instinct was to rebut again and make my points again but stronger. But my experience and executive overrides kicked in and I reminded myself of an old adage "Before you can influence others, you must first allow yourself to be influenced by them." This has led to my own adage: "Never squander an opportunity to lose an argument." Losing can be good; it gains you equity with the team if you do it gracefully. Here are some points that help me when I need to lose (or when I'm going to lose anyway).
- Any time you disagree with another expert, there is a 50% chance you are wrong.
- Even if you are right, any time you disagree with an expert, there is a 50% chance that what you're arguing about has no practical significance for the user.
Let's stop there for a moment. That means there is only a 25% chance that if you continue an argument and win, you will do any good. I think point #2 is generous in assigning a 50% probability that there is any efficacy in the outcome. If two experts disagree, either proposition will probably work. Think about the bottom line impact some of these disputes have or don't have. The answer should be a gauge as to how long the argument should go on. For example, how much will your company's profitability be affected if you use "e-mail" or "email" in the UI? In this example, flip a coin but don't flip it too high. Every second you wait for it to land is losing money.
- Give the other side the last word. Losing with an "OK, but..." forfeits any equity the loss would have gained you.
Truth is, most people do not remember who made specific points in a meeting. More times than not I hear the wrong person being credited with a particular statement. What people will remember, however, is how well the teams you are on end up doing.
Don't seek a reputation of being the "guy with the answers." Instead, become the "guy who initiates and facilitates productive conversations."
And many times that means both making the initial proposal and then graciously losing the argument that ensues.
If I weren't so naturally talented at making the wrong proposal, I'd probably have to do it on purpose just to get ahead.
Wednesday, April 27, 2011
Outliers and Parallelism
Sometimes we tout parallelism with the same misguided religious fervor with which we persecute any use of the passive voice. For example, I am not the least bit bothered by the lack of parallelism in the following menu (nouns and verbs mixed):
That having been said, it is a pretty powerful force. And sometimes we must choose between being parallel and some other good rule of rhetoric.
Two examples that vex me periodically:
Am I being overly zealous in my desire to have parallel treatments? Are there other examples that vex you? Chime in.
That having been said, it is a pretty powerful force. And sometimes we must choose between being parallel and some other good rule of rhetoric.
Two examples that vex me periodically:
- Tables where all of the cells in a column have multiple entries except one. I want to use bulleted lists to make the multiple entries more readable. Do you bullet the lone item in the one odd cell? I do.
- Grouping fields on a form where inevitably there is one field that accounts for an entire function and doesn't go with the others. Do you fence in the one lone field with a grouping box or leave it out there as a free range field? I fence it in.
Am I being overly zealous in my desire to have parallel treatments? Are there other examples that vex you? Chime in.
Monday, April 25, 2011
Monday, April 18, 2011
On Nudging and Fudging
I went to an interesting TAG (Technology Association of Georgia) Product Management breakfast meeting last week, and I participated in a buzz group that talked about Agile and Product Feature road maps. It was interesting that nearly every company/person in the session had the same experience about how to manage executive expectations.
Executives are focused on dates, much more so than features. Don't miss a date! But what you CAN do is get flexible with the feature set that releases on that date. Or if you like pithy rules: "Don't nudge dates; fudge features.
Now customers are a different thing, and they pay more attention to features. The collective wisdom of the group was to commit to only 80% of your capacity so you had some bandwidth to fix problems or accommodate late entries into the requirements mix. Some also had quarterly communications with customers to let them know what would be rolling out in the near future.
Another interesting nugget from one company was to let product managers communicate only with prototypes and not bullet points. It made sure that PM was talking about things on the "Do" list and not on the "wish" list.
Executives are focused on dates, much more so than features. Don't miss a date! But what you CAN do is get flexible with the feature set that releases on that date. Or if you like pithy rules: "Don't nudge dates; fudge features.
Now customers are a different thing, and they pay more attention to features. The collective wisdom of the group was to commit to only 80% of your capacity so you had some bandwidth to fix problems or accommodate late entries into the requirements mix. Some also had quarterly communications with customers to let them know what would be rolling out in the near future.
Another interesting nugget from one company was to let product managers communicate only with prototypes and not bullet points. It made sure that PM was talking about things on the "Do" list and not on the "wish" list.
Thursday, March 17, 2011
Accessibility: Some honest talk
Sometimes I like to use my blog to wrestle outwardly with conflicts I am having so that others can weigh in with their perspectives. This one can get a little edgy, so let's all stay on our good behavior.
Is it just me or can accessibility be a big pain in the ass at times? As Andy Rooney once said about an entirely different subject "I am violently ambivalent" about this. By that I mean I can passionately argue two opposing perspectives, mainly because I have two opposing perspectives.
The side of me I like holds the position that accessibility is good and anything we do to make our products more accessible makes our products better.
The part of me I'm a little nervous about exposing wants to offer a lot of rich Internet interactions and resents the constraints that accessibility requirements put on that.
These opposing poles can be summarized by what I call the accessibility paradox:
I don't need to be accessible because my clients aren't physically challenged--but none of my client base is physically challenged because my product's lack of accessibility won't let physically challenged persons become my clients.
These debates make great barroom entertainment and inspiring conference presentations, but right now I have some very real design decisions to make. Anyone who has both design and accessibility responsibilities knows the frustration of using AJAX. Anything dynamic on a screen starts to cause problems for adaptive technology devices.
I'm not going to pick on Jaws because it is a good product, but I will use them as an example. Instead of making me constrain my design so that Jaws can handle it, why not beat Jaws up until it can handle these modern types of interactions? Instead of regulating me, regulate them!
OK, it felt good to whine, so let's get practical for a minute.
As a designer I have to strike that balance between rich interactions that enhance the user experience for my majority base, namely folks who can see the screen and manipulate a mouse. I also need to make the content and functionality available to those who can't. Companies, in general, get a little bipolar on this. Marketing wants to say the products are accessible; they also want rich interaction; and they want a lot of new features. How's the classic punch line go? "Pick any two."
I read an accessibility tip yesterday that said to summarize the key points of a graphic in its caption. I work with dashboards where the graphs are dynamically generated in real time with the latest available data. How am I going to do that? You caption a sparkline that contains 30 days of trend data or a tree map that is summarizing hundreds of data points--and generate that caption dynamically.
And yes, I know the classic solution to the problem is linking to the source data from a longdesc attribute in the image tag. That's work, that's time, that's less features we will be able to build for the release. (BTW, I elaborate on this in the Comment section.)
I'm not saying we shouldn't do it; I just wish the conversation about accessibility would be more frank when it comes to the opportunity costs and real costs to implement it.
And I'm embarrassed by my own petty frustration in having to accommodate someone who has a real beef with the world and a legitimate cause for frustration.
Is it just me or can accessibility be a big pain in the ass at times? As Andy Rooney once said about an entirely different subject "I am violently ambivalent" about this. By that I mean I can passionately argue two opposing perspectives, mainly because I have two opposing perspectives.
The side of me I like holds the position that accessibility is good and anything we do to make our products more accessible makes our products better.
The part of me I'm a little nervous about exposing wants to offer a lot of rich Internet interactions and resents the constraints that accessibility requirements put on that.
These opposing poles can be summarized by what I call the accessibility paradox:
I don't need to be accessible because my clients aren't physically challenged--but none of my client base is physically challenged because my product's lack of accessibility won't let physically challenged persons become my clients.
These debates make great barroom entertainment and inspiring conference presentations, but right now I have some very real design decisions to make. Anyone who has both design and accessibility responsibilities knows the frustration of using AJAX. Anything dynamic on a screen starts to cause problems for adaptive technology devices.
I'm not going to pick on Jaws because it is a good product, but I will use them as an example. Instead of making me constrain my design so that Jaws can handle it, why not beat Jaws up until it can handle these modern types of interactions? Instead of regulating me, regulate them!
OK, it felt good to whine, so let's get practical for a minute.
As a designer I have to strike that balance between rich interactions that enhance the user experience for my majority base, namely folks who can see the screen and manipulate a mouse. I also need to make the content and functionality available to those who can't. Companies, in general, get a little bipolar on this. Marketing wants to say the products are accessible; they also want rich interaction; and they want a lot of new features. How's the classic punch line go? "Pick any two."
I read an accessibility tip yesterday that said to summarize the key points of a graphic in its caption. I work with dashboards where the graphs are dynamically generated in real time with the latest available data. How am I going to do that? You caption a sparkline that contains 30 days of trend data or a tree map that is summarizing hundreds of data points--and generate that caption dynamically.
And yes, I know the classic solution to the problem is linking to the source data from a longdesc attribute in the image tag. That's work, that's time, that's less features we will be able to build for the release. (BTW, I elaborate on this in the Comment section.)
I'm not saying we shouldn't do it; I just wish the conversation about accessibility would be more frank when it comes to the opportunity costs and real costs to implement it.
And I'm embarrassed by my own petty frustration in having to accommodate someone who has a real beef with the world and a legitimate cause for frustration.
Monday, March 14, 2011
Happy pi Day
I love pi! It's Greek; it's irrational; it's a number that eschews exactitude and demands rounding.
What exactly is it? Take a piece of string and tie a loop in both ends. Pin one end in the center of piece of paper and put a pencil in the other. Now, with the string stretched tight, move the pencil around the pin until it inscribes a circle. Now lay another string around the circumference of the circle you just drew. Cut off any extra. Fold it in half and cut it. Lay one of the halves next to the first string. The second string is pi times as long as the first.
Here's the cool part: Even though you have obviously created a physical ratio (second string to first) there are no numbers that can express that ratio. Really pissed off the Pythagoreans ;-)
Enjoy pi today.
Thursday, February 24, 2011
If I only had an *
My favorite quote from the Wizard of Oz:
I'm designing a new user experience for submitting technical support requests. The support folks said customers aren't giving them enough information and they specified what fields they wanted to be required. So I mocked up a form and put "*" in front of the required fields. Then I cross referenced it against the existing form and found mine was pretty much the same--except for the asterisks.
Pretty powerful thing, an asterisk, apparently it can make our users smarter.
Why, anybody can have a brain. That's a very mediocre commodity. Every pusillanimous creature that crawls on the Earth or slinks through slimy seas has a brain. Back where I come from, we have universities, seats of great learning, where men go to become great thinkers. And when they come out, they think deep thoughts and with no more brains than you have. But they have one thing you haven't got: a diploma.
I'm designing a new user experience for submitting technical support requests. The support folks said customers aren't giving them enough information and they specified what fields they wanted to be required. So I mocked up a form and put "*" in front of the required fields. Then I cross referenced it against the existing form and found mine was pretty much the same--except for the asterisks.
Pretty powerful thing, an asterisk, apparently it can make our users smarter.
Wednesday, February 23, 2011
When did I become "that guy?"
Five months ago I was in the camp of "All I need my cell phone to do is make and take calls." Then I realized that sooner or later I was going to need to design user experiences for smart phones and that I had no direct experience as a user. So I cowboyed up and bought an iPhone.
Fast forward to yesterday. I got a call from our customer loyalty manager late in the afternoon (on my iPhone). We are doing a big customer hoo-hah thing today and we were out of Post-it flip charts. (Who you gonna call? Apparently the UX guy!)
So I go down to the conference room to see what they need. They showed me what they had and suggested I write down the part number and description. "Not necessary," I said. I took out my iPhone and opened my RedLaser app. I scanned the bar code and got a description and the pricing for all the local office supply stores. I put the address of the closest Office Depot in my Google Map app and used my iPhone's GPS to get there.
When did I become "that guy?" Five months ago I'm all about "I don't need no stinkin' camera in my cell phone," and yesterday I'm laser scanning bar codes with it.
Lesson for UX: Discount NO technology. The adoption rate happens in dog years, if not faster.
Fast forward to yesterday. I got a call from our customer loyalty manager late in the afternoon (on my iPhone). We are doing a big customer hoo-hah thing today and we were out of Post-it flip charts. (Who you gonna call? Apparently the UX guy!)
So I go down to the conference room to see what they need. They showed me what they had and suggested I write down the part number and description. "Not necessary," I said. I took out my iPhone and opened my RedLaser app. I scanned the bar code and got a description and the pricing for all the local office supply stores. I put the address of the closest Office Depot in my Google Map app and used my iPhone's GPS to get there.
When did I become "that guy?" Five months ago I'm all about "I don't need no stinkin' camera in my cell phone," and yesterday I'm laser scanning bar codes with it.
Lesson for UX: Discount NO technology. The adoption rate happens in dog years, if not faster.
Wednesday, February 09, 2011
Hughes' Law of Non-linear UX Time
I've always wanted my own law. Here it is:
t=log(UX)
User experience time is logarithmic. The user's first 30 seconds on an application or web page is as important as the next 30 minutes. And that 30 minutes is as important as the next 3 hours.
Loren Burke, my usability mentor, created an entire business fixing the first 30 minutes of products that were about to be launched or which were already in trouble.
I am reminded of this as I am working on dashboards right now. Manage the first 30 seconds, then the first 30 minutes.
The next question then is whether to move on to the next 3 hours or to find another 30 second/30 minute problem to solve.
t=log(UX)
User experience time is logarithmic. The user's first 30 seconds on an application or web page is as important as the next 30 minutes. And that 30 minutes is as important as the next 3 hours.
Loren Burke, my usability mentor, created an entire business fixing the first 30 minutes of products that were about to be launched or which were already in trouble.
I am reminded of this as I am working on dashboards right now. Manage the first 30 seconds, then the first 30 minutes.
The next question then is whether to move on to the next 3 hours or to find another 30 second/30 minute problem to solve.
Wednesday, February 02, 2011
The Spherical User
Just read a great joke--OK, a joke I liked at any rate.
"A dairy farmer, in a fit of desperation because his cows aren't giving enough milk, consults a theoretical physicist about the problem. The physicist listens to him, asks a few questions, and then says he'll take the assignment. A few weeks later, he calls up the farmer, and says 'I've got the answer.'
'Tell me,' pleads the excited farmer.
The physicist starts his answer by saying, 'First, we assume a spherical cow...'"
Physicists often have to construct clean, clear-cut laws to describe messy realities. They do this by cleaning up their concepts about reality, assuming frictionless surfaces, loss-less mirrors, and yes, lots of spherical objects.
UX and UI designers sometimes do the same thing, assuming a spherical user who knows what he wants to do, will not make errors in doing so, and will do it in an environment that supports his objective, his timing, and everything else idiosyncratic about him.
Anything outside of those design boundaries we term "edge cases." The result is often a design that works great when it works and that really sucks when it doesn't.
I admit that I laughed at the cow joke, but it was a nervous, could-this-be-me laugh. Maybe because in my Agile zeal, I try to avoid over-thinking the solution at the front end. My scenarios are happy paths that lead to success.
But I'm going to stop and pause more and ask myself, "How can someone do this wrong?" Anyone have any experience or ideas on how to implement that step systematically in an Agile model?
"A dairy farmer, in a fit of desperation because his cows aren't giving enough milk, consults a theoretical physicist about the problem. The physicist listens to him, asks a few questions, and then says he'll take the assignment. A few weeks later, he calls up the farmer, and says 'I've got the answer.'
'Tell me,' pleads the excited farmer.
The physicist starts his answer by saying, 'First, we assume a spherical cow...'"
Physicists often have to construct clean, clear-cut laws to describe messy realities. They do this by cleaning up their concepts about reality, assuming frictionless surfaces, loss-less mirrors, and yes, lots of spherical objects.
UX and UI designers sometimes do the same thing, assuming a spherical user who knows what he wants to do, will not make errors in doing so, and will do it in an environment that supports his objective, his timing, and everything else idiosyncratic about him.
Anything outside of those design boundaries we term "edge cases." The result is often a design that works great when it works and that really sucks when it doesn't.
I admit that I laughed at the cow joke, but it was a nervous, could-this-be-me laugh. Maybe because in my Agile zeal, I try to avoid over-thinking the solution at the front end. My scenarios are happy paths that lead to success.
But I'm going to stop and pause more and ask myself, "How can someone do this wrong?" Anyone have any experience or ideas on how to implement that step systematically in an Agile model?
Subscribe to:
Posts (Atom)