Accessible Planet

BREAKING TRIVIAL NEWS…in the past couple of hours, the Amazon sales ranking for my autobiography I’ll Do It Myself shot up from #67,557 in the Kindle Store – after being at about #797,998 for weeks – to #41,004!

And I have screenshot to prove it:

I usually don’t pay much attention to the sales ranking; ranking does not not necessarily equate to dollars, which, really, is the only one number that really counts But when it jumps 26,553 points in an hour, that caught my attention!

Thank you to the Kindle readers who made that happen.

In the next hour, my book dropped slightly to #44,297 in the Kindle Store.

Did you know you don’t need a Kindle device to read Kindle ebooks? These ebooks can also be read on your PC, Mac, iPad, iPhone and other devices.

My question is: do we, together, have fun with this and see how high we can get the sales ranking? Is there anything better to do on a wintry weekend? What do you think?

Thursday, March 1 is Adobe Day at the CSUN Conference. We’ve got five sessions lined up, all in Elizabeth C (2nd floor):

• Acrobat X, with Greg Pisocky and Pete De Vasto, 9:20am
• Accessible e-books with Adobe Digital Editions with Kiran Kaja, 10:40am
• HTML Accessibility with Adobe Software with Michael Jordan and Matt May, 12pm
• Video and CVAA Compliance with Adobe Tools with Andrew Kirkpatrick, 3:10pm
• Adobe Town Hall with the whole Adobe Accessibility team, 4:20pm

There’s more to come. (Probably involving hors d’oeuvres.) But for now, mark your calendars, and we’ll see you in San Diego.

For a while now, Firefox has had the ability to collect anonymous usage data. Internally, we call this telemetry.

Recently, we also started to incorporate statistics about the way the accessibility features of Firefox are being used.

Our newest addition to this feature is the collection of data about which screen reader is being used with Firefox on Windows. For Linux, there is only one screen reader that’s widely used really, so we primarily concentrated on Windows, since there are a variety of screen readers and screen magnifiers out there that Firefox is being used with.

So, to get a better idea about what our user base is using Firefox with, we’d like to call out for assistance in gathering this data! Let me stress once more that this is purely voluntary, but that this will help us improve our over-all support even more focused once we know better what assistive technologies are the most used. Moreover, this is anonymous data, so there is no way we can link a particular screen reader to a particular user. Which assistive technology you use is and stays your private matter. You’ll only be contributing to an over-all picture of usage statistics.

So how do you turn this on? In Firefox:

1. go to Tools/Options.
2. With the arrow keys, navigate to the list item called “Advanced”.
3. Tab once to set focus to the tab page selection.
4. Select the “General” tab using the left and right arrow keys.
5. Tab through the dialog until you reach a check box called “Send performance data”. Note, instead, you can also press Shift+Tab a couple of times to get there faster, since this is the very last checkbox before the “OK” button.
6. Press Space to check it if it is unchecked.
7. Tab once to get to the “OK” button and press Space to close the dialog and save your changes.

Firefox will now send anonymous usage data to us and inform us about any relevant performance like memory usage, screen reader in use (if any), or whether accessibility is instanciated at all.

Note that part of this feature is currently only in the Nightly development builds of Firefox. If you use a regular release like Firefox 9.0.1, this checkbox will not have any effect for screen reader usage data yet. But for other data such as the memory consumption, you can still enable it. Once you get upgraded to Firefox 12 in 3-4 months, you’ll start sending us data about your screen reader usage automatically.

If you’re on the Aurora channel, you’ll get this feature with the next big uplift that will happen early February.

To all who enable this feature, thank you! Your helping us improve Firefox even more is appreciated!

And to those of you who do not wish to send us your anonymous information, that’s perfectly fine, too! No grudges will be held against you.

Design patterns are generally considered a good thing, but do they actually help run a user experience group? As a user experience group manager and an observer (and sponsor) of design pattern exercises, I’ve come to have serious questions about their actual utility. It’s not that design pattern libraries are bad, but that in a world of limited resources, it is it is not clear that the investment is worth it. Fortunately, there is a better approach: reaching outside the design group to solve the whole problem.

An interaction design pattern is a “general, reusable solution” “to common usability or accessibility problems”. They usually consist of pictures and descriptions of the best way to handle a GUI design element, such as a date picker. Libraries of them are found online (see below) and in many institutions with a user experience practice. Like all tools, they exist to solve a problem; but what is the problem?

They are generally said to help:

• instruct junior user experience people
• save time of documenting design details in every project
• make collaboration with developers easier
• encourage consistency

The case against design patterns

Pattern libraries have laudable goals, but in practice, design patterns do not support how teams actually work. Practically, the pattern approach assumes that the users:

• know (and remember 3 months later) that the pattern library exists
• quickly find the pattern that they need
• know how to interpret the language
• know when to apply a particular pattern and how much they can deviate
• have the time and motivation to continue documenting ideas

Design patterns are not effective training tools.

Patterns, once literally a design on paper that could be copied, in UX are an abstract idea that professionals can reference. You can not copy a UX pattern, like you can copy a sewing pattern. Having someone read a pattern library will not make them a competent user experience designer. It would be akin to teaching writing by reading the dictionary – the “why”s are not answered.

Design patterns don’t replace UX expertise

Design patterns can be a useful reference point for the junior user experience designer. But experienced professionals find ideas and inspiration in the whole world. Should your team invest time in making a pattern library as a training tool, or just change the way they work? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

Completeness and learn-ability are in conflict.

In order for a pattern to be used, it has to be easily read. But completely describing even the simplest UI pattern (like a two-panel selector) requires such detail as to prevent the person from absorbing it. Additionally, any design pattern I’ve seen inevitable contains “it depends” clauses, which leave the important decisions right back with the reader.

Pattern libraries suffer from a similar problem. Many seem to start by defining the basics, to answer questions like “when should one use radio buttons versus a drop down menu”, but lose steam before they get to the complex pieces. This is ironic, as the complex interactions are the ones that need the most definition, and offer the most creative opportunity. Defining the pattern of a radio button, is necessary for completeness, but not a good use of time or creative energies.

Design Patterns take a lot of investment.

The investment in the library needs to pay off in later efficiency to be successful. But each pattern is essentially a mini design project with extreme documentation and design reviews. Having corresponding template widgets is an additional effort, as is updating the designs when the inevitable rebranding comes along. (I’m already tired just writing this.) If your team uses more than one design tool (InDesign, OmniGraffle, Visio), who is going to update all the versions?

Design Patterns should help non – UX people first

Design patterns reduce work for UX people, but they clearly increase work for developers. Developers operate under time pressures and need a spec to code to. Directing them to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe. The design pattern’s open ended nature requires them to read a general case and code a specific case. Because they are just designs, they can also ignore the ugly complexities in many of the problems, by simply not addressing them.

Design Patterns don’t work with a normal designer’s motivation – indeed, they seek to restrain it. When a person sits down at their drawing program to address a problem, a reference document is several steps away, especially under time pressure. They almost always want to design rather than copy, especially, when it is unclear if a new situation is different “enough” from an existing pattern. On the contribution side, any change will entail a review with peers, which could take weeks to finalize, too slow for a project. Large organizations who most need a pattern library (many practitioners) are least able to build one (complex organizations, conflicting deadlines).

Why do people make design pattern libraries anyway?

I’ve never heard of a business owner or technology lead asking for a design pattern library. They seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

Pattern libraries seem to be made by a UX person who wants to put a stamp on how things SHOULD be done. To establish, once and for all, the right way to do something. The design pattern library could be more akin to building a model train set: like the real world, but controllable. They are like design projects without clients or time pressure. “Just this once, we’ll do it perfect”. A participant at a recent New York IXDA event said with pride that he personally had created several pattern libraries –it was a personal accomplishment, not a business achievement. No one can argue with how a person spends their free time, but teams have to make sure work time is spent wisely.

The downside to this motivation is that individual authors want to create their own collection, which inevitably duplicates the other libraries. Pattern Libraries also tend to be abandoned when the author loses enthusiasm after the initial burst of activity. Even the major sites like Yahoo and Welie have stalled. The last update on Yahoo was 2 years ago; Welie was 4 years ago.

What is the solution then?

Let’s apply the user centered design process to this situation. Using the goal of “better designed products and increased productivity”, we can identify the three potential audiences of an enterprise Pattern Library: User Experience, the Business representatives, and Technology.

The UX group is primarily concerned with consistency and best practices. This is culture, not documentations and should be managed as such:

• Culture is built through personal interaction. Review, Review, Review. Regularly meet to share work, and best practices.
• Patterns do not mean your design sense can go on auto-pilot.
• Build a collaborative culture referring each other’s work. (“Joe worked on something like that.”)
• When a new design challenge appears, get a bunch of people to talk it over, get “good enough” agreement.
• Document decisions quickly and spread widely, for example on a wiki (so any one can edit it).
• Focus on content first, make the pretty library template as a reward for reaching 20 patterns.

Business and Technology are primarily concerned with getting work done and reducing costs. The biggest efficiency gain is reducing development time, focus on giving developers the tools and guides they need. The biggest issue is that typically, UX people do not code. The solution is to get out of the design cave and work with people who do.

Create a design ecosystem instead of documentation.

People do not RTFM. Period. It is hard to get people to engage with any documentation on their own. They are happy to read the details about what they want, but are put off by finding it inside a large document or library. The solution is to create an ecosystem where each piece reinforces the others. iPods were well-designed devices, but they succeeded because of the ecosystem (devices +iTunes + stores + accessories). Music was easy to find and buy, and easy to put on the computer. The overall experience of the ecosystem is what determines the success. When you say the answer is a document, rather than a community, it turns people off and limits their contribution.

The ecosystem should be composed of:

• People: Developers, Designers, and business leads. People who can answer questions, who are motivated by their own job requirements and professional pride
• Code library and documentation
• Management demand

A code library beats a pattern library

The code library should be “internal open source”, a shared library enabling developers at a company to share code without worrying about licensing or malware. Instead of the whole org waiting while a centralized team builds the future, let every group contribute.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests, supported by an active development and UX mail lists. Make them easily accessible as web pages, not a document. Style guides and pattern libraries get retained even if they are out of date. Social connectivity is much more important than printing them out.

It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests. This is supported by an active development and UX mail lists.

For each presentation layer technologies you support, there should be in Version Control system, with a Main branch, supported by a core team, and an open Contrib branch that anyone can put components in. Good components are promoted to the main branch, which is released in versions, so updates do not break existing apps.

Components should cover three scales:

• Basic styling of standard components
• Custom components, like a date picker or type-ahead
• Page sized components, such as forms,dashboards, or search result pages

How do you get such a library?

In a world of limited resources, one has to boot-strap the Library.

• Build off of the current running projects. Nominate widgets or functions in an active project as “library-worthy” and have them coded abstractly and contributed to the library.
• Publish and reward people who contribute to the library.
• Make a most wanted list and see who has them.
• Solve problems that you actually have, don’t worry about completeness.
• Have the patterns in working code samples accessible by anyone in the firm. Instead of pretty pictures, have the code that actually performs how your want it to. Make the options / parameters editable in the sample, so anyone can play with configuring the sample.
• Look and feel should be a separate code library, released in parallel, so that the design can be upgraded in the future (as it will be) without affecting functionality.
• For general guidelines, write high level guidelines a sketch or two, but point the developers to ask a mailgroup of designers and front end engineers. When a question gets asked enough that it is annoying, code the pattern.

Management support is critical -if the project is a “nice to have”, it is doomed. Each project should report what they contributed to the library and what they consumed. A developer’s performance evaluation should list what they contributed to the library and what they re-used -Both save the firm money. At a firm I worked at – a single component, taking 2 weeks of two developers’ time, was re-used over 200 times. This saved 16 person-years of effort -this is real money. Not every component will be so effective; the library team should be focused on the business value of each component and the user experience of the eco system. If done right, the design / code ecosystem has the potential to both improve design and save time, something we can all agree on.

Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. Working together with non designers can make everyone’s life easier, and make the final product as good as the design.

The Assistive Technology Industry Association’s annual conference, ATIA 2012, will be in full swing tomorrow, and our own Greg Pisocky will be appearing in three sessions:

• “Implementing ISO 14289 (PDF/UA)”, Thursday, January 26 8:00 am to 9:00 am Caribbean 6
• “eBook Accessibility with Adobe Digital Editions and EPUB”, Thursday, January 26 4:00 pm to 5:00 pm Curacao 3 – 4
• “Creating Accessible Documents More Efficiently with Adobe InDesign CS5.5”, Friday January 27 9:20 am to 10:20 am, Caribbean 3 and 4

That’s just the first outing of the year. In February, Adobe will be presenting at Techshare India, the 6th European eAccessibility Forum, and the CSUN Conference. We’ll keep you updated with sessions and times.

Last month Amazon announced Kindle Direct Publishing (KDP) Select – "a new option dedicated to KDP authors and publishers worldwide, featuring a fund of $500,000 in December 2011 and at least $6 million in total for 2012! …"

Understanding that early adopters would have a greater chance of substantially gaining from this opportunity, I opted in right away by making my autobiography I’ll Do It Myself available through the Kindle Owners’ Lending Library, which allows eligible U.S. Amazon Prime members to borrow the book. I would earn a royalty – based on a percentage – for each book borrowed.

December’s results

The numbers for December on now in: based on the number of total books borrowed and the month’s available fund of $500,000, each eligible borrow earned a royalty of $1.70. My sincere thank you to the lone Prime member for borrowing my book. It’s a start!

For fun, I did the math…doubling the number of borrows each month for a year, the royalty cheque for November 2012 would be $3,4581.670…and that doesn’t include any book sales. Now we are talking!

Of course, that number is purely hypothetical because as more authors opt in and as more Prime members borrow books, the available fund – increased to $700,000 for January – will be divided amongst more eligible borrows. The royalty earned per book could drop significantly from the initial $1.70. But seeing the potential income generated is exciting and shows me that promoting this revenue stream may be well worth the investment of time.

Now save 25%

Keeping a closer eye on the Best Seller in Kindle Store list for the last month, I realized my ebook was over priced, particularly for an unknown author. Taking a gamble that a lower price would increase sales, and, hence, increase royalties, I have dropped the price by 25%. $6.49 seemed a lucky number! We’ll see how that goes.

Requesting a favour, please

If you have purchased I’ll Do It Myself from Amazon, first, thank you. I do appreciate everyone who takes a chance and spends their money on my book when there are thousands to choose from. Thank you.

Second, if you enjoyed the book and found some value inside the cover, please consider writing a review. This may encourage other Amazon customers to also buy it.

ORDs still available

For those who prefer ORDs (old reading devices), there are less than 150 autographed paperbacks left. Once they are gone, they are gone. I likely will not have another print run done. An empty corner in the living room might motivate me to get going on my second book!

NV Access now offers  phone-based support and training for users of NVDA in Australia for a flat rate of AU$59.95 per hour. Hours are prepaid so that once purchased, you can give us a call any week day to have your query answered. Whether you have a specific question or you want a thorough introduction to the basics or more advanced features, we're only a phone call away. We can also offer face-to-face training for organisations or groups of individuals. Please  contact us if interested.

I'm redesigning Tar Heel Reader in hopes of taking load off the server and making the site friendlier to tablets and phones. Over the last few weeks I did a mockup with jQuery Mobile that works well enough on mobile devices but it was just kludged into the current system and it didn't work at all on IE6. So, I've decided to back up and rethink things.