Jared (Spool) is saying it's the first time he's done this presentation, and trying something new, expects it to be challenging.
One skill we don't talk about that often, and it plays a role: magic. Magic conferences are a lot like developer conferences.
The user's model is different from the designer's model. Traditional tech comm is all about explaining the designer model to the user.
Google complexity hidden in the background, the foreground simple experience makes users feel empowered. Company creates an illusion. The illusion has to be maintained.
It's hard to do this, and not everyone does it well.
Perception of time turns out to be a difficult thing. We perceive time differently, depending on what's going on.
Perceived performance doesn't measure the actual speed of a site. It measures the success of the user.
The role of delight, the Kano Model, has to do with performance. Some features, as the features go up, you get a payoff, the payoff grows as you add more features. But some things, you can't get above neutral satisfaction. Take a calculator, at some point, you can't improve the multiplication function. Idea of delight, of creating excitement. Items you can add, don't have to be great quality, but if you do it the right way, you get a sense of delight.
You can create delight by paying attention to the user.
Delight by functionality is just doing the right thing. Can;'t begin to do the delight stuff until we understand the basic stuff we want to do, else the delight stuff doesn't matter.
People want magic in their lives.
Wednesday, April 1, 2009
iPhone!
This was a tough one., Dave Gash--a great speaker, always with highly tech-y topics--is speaking now (his only session this year) , and there's also a session about creating great personas, but I'm here listening to a session about iPhone development. It was a toss-up for the last two, and because mobile is going to have a big future, I decided to land here.
Christopher Garrett says that he changed a number of his slides. Ugh. But apparently there's a slide sharing spot. He'll give the URI later.
Early experiences developing for mobile devices involved lots of barriers for developers. The ability to purchase content was also a painful experience, and another barrier.
2007, first release of the iPhone, people wanted apps for it, but Apple said use Safari, so people created mobile web apps.
Want to develop applicaitons for the iPhone? You need an iPhone (or at least an iPod Touch). Duh. And a Mac (because Apple has locked its development tools to the Mac OS (for now). Also need to read the docs here: http://developer.apple.com/iphone/.
2008, released an SDK for developing apps, "barriers were gone."
If you want to develop for iPhone, you need an iPhone (or an iPod Touch). Duh. And a Mac (Apple has locked its development tool to the Mac OS, for now.) And you need to read the docs here: http://developer.apple.com/iphone/.
Stick with the UI standards. Which means that you have to download lots and lots of apps and see what they do, what they do right and what they do wrong. And something done one way elsewhere doesn't mean that it's the right way for the iPhone (or other mobile app).
If you have a native app that you think requires a sign-on, think again.
Where there are 25,000 apps in the AppStore, there's no reason to release an app with a poor interface.
When you delete an app from the iPhone, you're given a chance to rate it. And if someone's deleting it, it's likely because they don't like it. And so you're likely to get your overall app rating skewed downward.
Christopher Garrett says that he changed a number of his slides. Ugh. But apparently there's a slide sharing spot. He'll give the URI later.
Early experiences developing for mobile devices involved lots of barriers for developers. The ability to purchase content was also a painful experience, and another barrier.
2007, first release of the iPhone, people wanted apps for it, but Apple said use Safari, so people created mobile web apps.
Want to develop applicaitons for the iPhone? You need an iPhone (or at least an iPod Touch). Duh. And a Mac (because Apple has locked its development tools to the Mac OS (for now). Also need to read the docs here: http://developer.apple.com/iphone/.
2008, released an SDK for developing apps, "barriers were gone."
If you want to develop for iPhone, you need an iPhone (or an iPod Touch). Duh. And a Mac (Apple has locked its development tool to the Mac OS, for now.) And you need to read the docs here: http://developer.apple.com/iphone/.
Stick with the UI standards. Which means that you have to download lots and lots of apps and see what they do, what they do right and what they do wrong. And something done one way elsewhere doesn't mean that it's the right way for the iPhone (or other mobile app).
If you have a native app that you think requires a sign-on, think again.
Where there are 25,000 apps in the AppStore, there's no reason to release an app with a poor interface.
When you delete an app from the iPhone, you're given a chance to rate it. And if someone's deleting it, it's likely because they don't like it. And so you're likely to get your overall app rating skewed downward.
What if the reader can't read?
That's the intriguing title of Tony Self's 10:00am presentation. Even Tony introduces it as being "controversial."
Reader is king. We don't write for ourselves or our bosses.
Audiences are changing. Tony showed this very interesting video: http://www.youtube.com/watch?v=dGCJ46vyR9o.
Grammar rules used to be an indication of social class, but it now serves the purpose of speed and social interaction.
Texting (txting) is a new grammar.
Really talking about "digital ethnography."
Tony then showed another interesting video, http://www.youtube.com/watch?v=pMcfrLYDm2U, which referenced this site: http://shifthappens.wikispaces.com/.
An Akami study in 2006 found that 75% of people would not go back to a website that takes more than 4 seconds to load. 4 seconds!!!
Mike Hughes suggests that we shouldn't be using tasks, that we should be using just conceptual information for user assistance.
Readers don't believe in manuals, but they do believe in collaboration, which is seen as legitimate.
Bosses will eventually realize that writing stuff isn't effective, but videoing stuff is.
As in this video, about how to use a blog, from Commoncraft.com.
One of our most common jobs in the next 10 years will be a deleter. The cost of storage is so cheap, it will become worthwhile to have somone who sifts through the data and throw out that which is not valuable.
Reader is king. We don't write for ourselves or our bosses.
Audiences are changing. Tony showed this very interesting video: http://www.youtube.com/watch?v=dGCJ46vyR9o.
Grammar rules used to be an indication of social class, but it now serves the purpose of speed and social interaction.
Texting (txting) is a new grammar.
Really talking about "digital ethnography."
Tony then showed another interesting video, http://www.youtube.com/watch?v=pMcfrLYDm2U, which referenced this site: http://shifthappens.wikispaces.com/.
An Akami study in 2006 found that 75% of people would not go back to a website that takes more than 4 seconds to load. 4 seconds!!!
Mike Hughes suggests that we shouldn't be using tasks, that we should be using just conceptual information for user assistance.
Readers don't believe in manuals, but they do believe in collaboration, which is seen as legitimate.
Bosses will eventually realize that writing stuff isn't effective, but videoing stuff is.
As in this video, about how to use a blog, from Commoncraft.com.
One of our most common jobs in the next 10 years will be a deleter. The cost of storage is so cheap, it will become worthwhile to have somone who sifts through the data and throw out that which is not valuable.
Content models
Decided to hit the "double scoop" case study session out-of-the box on editing. Both speakers are from Microsoft, and the first, Richard Carey, is talking about content modeling.
Long-term tech writers will have to understand the XML model, the reuse strategies. Content modeling: powerful end-to-end development model. More relevant and consistent experience for users. A "programmatic application of basic technical writing principles."
"Topic" and "document" synonymous.
When users get to topic, they get solution that is relevant and easy to understand. Use links to get to larger concept. Solution is standalone, but can get context if they need it.
Been writer-centric, need to start thinking content-centric. XML universe brings the tools to us.
Break end-to-end story into solutions your customer can use.
Next, Microsoft's Terry Lee is talking about the value of editing.
Editors just want to make your excellent writing shine, and we let you take all the credit.
Quality content drives customer satisfaction, contributes to customer productivity and trust. It strengthens the brand. Dissatisfaction with content can engender dissatisfaction with the product that it supports. IEEE study showed that 70 out of 100 times were able to predict satisfaction with product by measuring satisfaction with content.
Editors reduce errors before publication, translation costs, support costs, and legal liability. Always cheaper to get it right the first time that to fix it later, even in a web-based environment.
Gave example of an error message that was technically accurate, but so cryptic that it drove support calls, became the #1 call driver, and created added cost of $1 million/year.
What if you don't have an editor? Use a peer-editing process. Have a style sheet. Have product names, capitalization. Have one person maintain the style sheet. Check cross references (especially TOC). Don't always rely on spell checker.
Bottom line: clarity trumps everything (including eloquence, parallelism, editorial idiosyncrasies).
Long-term tech writers will have to understand the XML model, the reuse strategies. Content modeling: powerful end-to-end development model. More relevant and consistent experience for users. A "programmatic application of basic technical writing principles."
"Topic" and "document" synonymous.
When users get to topic, they get solution that is relevant and easy to understand. Use links to get to larger concept. Solution is standalone, but can get context if they need it.
Been writer-centric, need to start thinking content-centric. XML universe brings the tools to us.
Break end-to-end story into solutions your customer can use.
Next, Microsoft's Terry Lee is talking about the value of editing.
Editors just want to make your excellent writing shine, and we let you take all the credit.
Quality content drives customer satisfaction, contributes to customer productivity and trust. It strengthens the brand. Dissatisfaction with content can engender dissatisfaction with the product that it supports. IEEE study showed that 70 out of 100 times were able to predict satisfaction with product by measuring satisfaction with content.
Editors reduce errors before publication, translation costs, support costs, and legal liability. Always cheaper to get it right the first time that to fix it later, even in a web-based environment.
Gave example of an error message that was technically accurate, but so cryptic that it drove support calls, became the #1 call driver, and created added cost of $1 million/year.
What if you don't have an editor? Use a peer-editing process. Have a style sheet. Have product names, capitalization. Have one person maintain the style sheet. Check cross references (especially TOC). Don't always rely on spell checker.
Bottom line: clarity trumps everything (including eloquence, parallelism, editorial idiosyncrasies).
Subscribe to:
Posts (Atom)