All posts tagged as "Design"

I have been been working on an ereader project lately,* and thinking about it a lot therefore. This has been soaking for a week now, it isn’t coming together with a common theme as I like all my posts to do so; so I give up and am just gonna push it as a list of semi-random rants.

For a narrowly focused by very spot-on analysis of formats for eBooks (and how html is going to be the way forward) read Joe Clark’s article Web Standards for E-books at ALA.

And I’ll start by quoting, because he says it better than I could:

The internet did not replace television, which did not replace cinema, which did not replace books. E-books aren’t going to replace books either. E-books are books, merely with a different form.

I’ll also say that eReaders have essentially no penetration compared to anything else. any pronouncements are gonna look like Cliff Stoll’s oft derided article on the lack of future of the internet. Much like the Information Superhighway and other early internet-related pronouncements, we don’t know what will happen, but I suspect Joe is right, and eBooks are going to be yet another form of media, and paper mills are safe for a while.

My first list of random thoughts is things I keep hearing, and which I think are dumb. Having worked on an eBook directly for six months now, I’ve seen this all along about the Kindle and almost every new device, but “iPad will save the world” hype has increased it exponentially.

“This changes everything.” See all the points above. It might change something, but seriously? Even those who get no paper publications now still read a lot of traditionally print media, and watch TV. Broadcast from a small group to a large group.

“The page-by-page reading paradigm is old and will be pushed aside.” Then why is it generally true on that published content I mentioned on the web? And why did we move from scrolls way back when? Actually, scrolls mostly have page breaks in the same way current interactive products do, as convenient blocks on content, then you move to the next (look it up… history is useful). This is therefore serious as can be; pages work for some fundamental reason, and sizes of books are driven by reader preference and innate usability (market driven, not explicit tests, and over centuries, but it’s still true) not industrial design and manufacturing so much. Why haven’t ebook designers noticed this?

“It can all be delightfully interactive, with photo spreads and blah, blah…” Again, why is this not true on the web, with /much/ more horsepower, screen space, and well-understood tools? I am regularly disappointed in what my web news experience is like; each page has the same thumbnail photo? I know the print edition has several, so show me. And slideshows, and movies? Really? Multimedia does not mean video or animation or any one thing, but the interplay between different types of display content. Please make /true/ multi-media experiences on the web, and I’ll start believing that eBooks can do something more than formatted text and click-to-view-the-photo.

The n magazine app has sold 140mm copies in the first week.” I do not care about trends today. So an app for a magazine (which has other issues) sells well on iPhone? So? Maybe it’s because there is no common magazine reader? And how well compared to even their dwindling print sales? And how sticky? The magazines I subscribe to I have been getting for decades. When trying to save traditional media, forget ongoing costs; if every publisher now has to figure CPGA and churn as non-trivial values every quarter, they need a whole new way to run their business. That might happen, but it doesn’t make “just publish your magazine on an eReader” a likely model. A method is needed with paper-subscription-like customer loyalty, and comparable price. Wishing for people to pay at newsstand rates will not make it so. (There’s more to say about payment schemes.

And now, a different but equally un-ordered list of random thoughts. These are more like design objectives, and business objectives for making a useful eReader:

• Books are not designed for annotation, bookmarking, etc. These are behaviors people created because they innately wanted them, and books support the methods. You have to support the /root need/ in your new device. How? I say starting with copying the existing methods, but new ones seem possible as well. Maybe someday I’ll show examples of what I think.


• How much would you read if every book was laid out differently? Some are right spine, some left, some fold up like a roadmap, etc.? Apps, with custom interfaces, for each publication are a clear non-starter. Not to mention issues with cross-referencing, or searching for bookmarks and notes, and social synching, and… all the other issues that trip up any number of services. Interoperability will be key.


• Battery life better START at days, not hours. If I had my way, the wall-plug would be hidden because you never use it; these need to be solar-charged, or similar. Minimal power consumption (ePaper types of technology, with NO consumption when static) seem required at least for now. There are color screens like this right beyond the next door. So we might be almost there.
  
• Cheap, cheap, cheap. Who wants to carry their ONE eBook around with them, and the people I know with one mostly carry it only sometimes. Why do waiting rooms have magazines? Because you have enough to do without carrying your own. Even in mobile-ubiquity days, a LOT of folks read those waiting room magazines. Need cheap enough everyone has several, and eventually they are given away.


• Rugged, approaching indestructable. A ruggedized device can be life chaging but this will only really happen when they are small enough to carry around we well. Alternatively, if the reader is dirt cheap, this makes up for some. But it’s not just disposal; how annoyed are you if you bring one reader with you on a trip and ruin it? It’s hard to ruin paper so completely you cannot read it later on. Who has not dried out an accidentally-soaked magazine to finish an article?
  
  My wife has a rugged phone, and it’s been very helpful to be able to carry gardening, talk when cooking, have it by the tub, etc. But it’s sort of an awful, featureless phone. We need small, rugged and full-featured to compete with paper seriously.


• Portable content. I don’t even want to talk about how the DRM works, but the end state has to be that I, as a person, can /always/ see my content on any device. E.g., I smash it and buy another, content is there seamlessly. If we want to get to a social scene, you better add a way to share that doesn’t involve me handing the device over. I had my phone off all the time, and it seems to make people nervous; it’s hard to get a phone out of most folk’s hands. When photos are shared, half the time it’s held up for others to see, not passed around. How will a reader get past this personal-device bias?
  
• Make it social and connected. Once you get past the table stakes of making it not uncomfortably un-book-like, work on where digital devices can be better, and that’s not the BS about carry a library in your pocket, it’s that it’s connected to the world. Better make a social media tie in, and better not be a unique one. Clearly, we’re not there in both vision and for business reasons; These silos of protected competitive space need to go away… but that’s a whole other blog entry I am working on.
  
• And be sure that data is handled in an information-processing-device sort of manner. Don’t be single session just because it’s easy; allow switching between books rapidly. Be sure search is easy to find and use, and is comprehensive. Display in multiple formats, and visualizations, and allow processing of content. I start thinking, why can’t the functions in math books be able to have actual values plugged in, and work?
  
• Be accessible, and not just for legal or regulatory reasons, not just for the stereotype blind user, but because if we’re going to use this everywhere, for all users we need it to work in all lighting, when you are tired, when you are driving and cannot read at all, and so on. Build true multi-media experience from the ground up. Again, no need to dream this up; there are rather good systems that exist, and just need to be implemented robustly, and universally.

Much of this discussion reminds me of every other technology that has come about while I have been a conscious, technically aware human. BD-Live just for one example, is wildly disappointing compared to the promise of interactivity . Since grade school I have been waiting for an experience half as clever and innovative as the Aspen Movie Map.

Despite all my griping, notice that I don’t say eBooks are a dead end. Or even that they must not be innovative. I say they have to be /usefully/ innovative, and to misquote what we say about mobile here “be a good book first.” It’s worth going back to first principles when a new technology comes about, and I think eBooks will be silly and niche until they are really, really designed to some useful principles.

* It’s not a secret project, so is a publicized devices, but my involvement is secret, so that’s all I can say about it.

On some of my latest projects the phrase "collaboration" has been thrown around a lot, as part of being Agile with a capital A. But generally, my initial reaction is that hardly ever does anyone mean it, or mean the same thing each time. For anything that strikes me like this, I'll often pop up and not just say it's dumb, but explain (for as long as anyone will listen) why that is.

And then it occurred to me that although I knew what I meant, I couldn't define "Collaborative Design" off the top of my head in any useful way. Normally I am not just opinionated about design and process, but have a solid reason for my opinion. So I considered this, kept quiet, and in the spirit of collaboration, later I sat down all by myself, and started to ponder what I think collaboration means.

And very rapidly I got almost nowhere. Even reviewing specific lists like Kelly Johnson's rules for Skunk Works project management wasn't that helpful; they are all too focused on their vertical market.

I came up with a few tactics, both derived from these and from my own observation, but I don't like simple step by step processes, at least unless there's an understanding of /why/ that simple process exists. It's not just my opinion; in industrial human factors a lot of accidents occur from mismatches between mental model and actual system behavior. So I need to find the underpinnings to make it work. But weeks pass while I have other things to do and no idea how to solve this problem yet.

Today, I was working on some stuff in the office (a slideshow, some "what do we do" language) and kept inviting people over to help evaluate, confirm and even create the content. Ten minutes later, Eric wandered by to ask where the best place for a help icon would be – an open-plan office is great for this stuff. And it all reminded me suddenly of this, because we were working /together/ on the problem. Even when asked about the help icon, I had to get scads of information from the designers working on the product full time, confirmed some of my other understandings, and then gave him options, and opinions on why each solution was good and bad.

And it occurred to me that this is exactly what I was doing earlier, and last week, and on all of the best collaborative products I have worked on. In fact, thinking about the method alone reminded me of projects I hadn't thought about in years.

A bit more typing and revising leads me to these principles and operational guidelines for collaborative engagement.

• Collaboration best employs the skills and knowledge of each individual. If a gap is identified, find the right person for that slot. This can be ad hoc (like Eric asking me to help solve a problem for a few minutes) or the way the whole project is set up, with a permanent team of these people all working together.
• Each collaborator contributes as they know best. That often means you trust someone's opinion, because that's their skill area. And it also means you keep quiet (or at least don't push too hard) when talking outside of your area. I know a little bit about database design, but try to limit my comments about data architecture, because I am not a DBA. And I hope they don't express an opinion on the color or alignment of everything I draw.
• There must be a product concept to start with. As I say it, you need a Problem Statement, Target Audience, Design Morphology, set Design Objectives and so on. Then stick them on a wall, stick them in the front of the documents, and constantly make sure that you stick with them. This carries through the whole process, so once the concept of design is done, stay with those templates and grids and the basic navigational architecture.
• Everyone is designing solutions. Technical contributors design data stores, software and so on. This is as legitimate a type of design as interactive or graphic design, so make sure everyone's contribution is as valued.
• Be a conscious designer. Every collaborator should offer (or be able to offer) an explanation for their decision, with upsides and downsides to each option. Inexplicable, unilateral proclamations to not engender trust with the team. And trust is the only way to make everyone believe in a decision and keep working collaboratively.
• Have a good team leader. Even for ad hoc collaboration, someone should clearly be the lead designer. For larger, and more permanent teams, a dedicated team lead is best. He should be only that, and maybe do other coordination and planning but never be a designer to avoid bringing his own opinions to the table. His key roles are to facilitate the process (make sure each of these other hints happen, make sure everyone actually works together and work through issues) and to make executive decisions. If a decision cannot be made, but either would work, he has to take responsibility for one, and that should be the end of the discussion.
• Discussions should be limited. Cutting discussions off is good. Sometimes it's that last 1% and any decision will yield a good result. If too far apart, it's often no good to keep going. While disagreement fosters creativity, argument just makes everyone entrenched. When collaboartion stops, it's time to stop the discussion, and take it up later. What these time limits are vary by the project, so I don't have any.
• The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.*
• There must be a minimum number of reports required, but important work must be recorded thoroughly.* Remember to record all the discussions about design objectives in the same manner as drawings; they are a design deliverable. Archive all this stuff, but try to let the team do its job, and report to management only when needed. Regular demos and proof of value spreadsheets interrupt the process for the whole team.
• When it gets to drawings, there must be a simple, understandable and universally-employed method of drawing, revising, versioning and distributing the files to everyone on the team. This same system should be used for prototypes, final code, and bugs. Yes, this last never seems to happen, but team members get left behind every time there is a system shift, and that is a bad thing.

I also think it's important, with overused phrases like this one, to define what it is not, and to address the edges and fixes.

• Don't jump in after a design is locked, present a totally different design (or some change that will require a totally different design) and then claim that's collaboration. If there's a legitimate issue, and this change is needed, first you need to get agreement from everyone that the whole design is up for grabs. Remember, this includes making sure the timelines (and dollars) can handle going off and redesigning everything again.
• Generally, revisions are not a good place for collaboration. A second release is, sure, and so are specific aspects of a fairly locked product; I'm not saying it only works for some "pure" clean sheet of paper design. Collaboration works well to devise new solutions to a problem.
  If a design is solidly on paper, and changes start piling from other teams and individuals there will be problems. I don't just mean teamwork problems, and hurt feelings but problems...
• ... One-problem-at-a-time is a solid way to organize tasks, to approach bugfixes and so on. But it's a terrible thing for design (of any sort). Remember, everything has to be holistically approached. And not just because it's the right thing to do, or to make sure everything is pretty. No, once that design starts proceeding, things get tied together in arbitrarily complex ways, and simple changes become hard to keep track of. Components will fail, or throw errors, links will get lost, etc. Now, a good designer will get over these, but not without raising yet more issues, or making other changes... which presumably need to be addressed with the team again. And you rapidly get to a spiral of exponentially-increasing changes.
  Use design objectives, grids and templates as a ruler here. If you find yourself on the third or fourth "we'll just violate that this one time" it's time to stop entirely and re-address things. Can you discard this changed item? Can you identify another component causing all these issues, that can be discarded or redesigned? Maybe the whole product assumption is wrong. This has happened – lately, to me – and usually the results of a total redesign or reset of the design objectives are better than before.
• Don't make emotional decisions. Even if you are trying to design a product that is specifically supposed to appeal to the user on an emotional level (and really, most of them are), don't let gut feelings, anecdote and opinion rule. And as a general rule, don't vote. Someone should be in charge of that practice area, and if there's a disagreement, the team leader makes the call. Other methods invite emotional decision-making, which is rarely correct.

I am aware some people think I am hard to work with, because I am very opinionated and push for it. But I'm not really; what I push for is the design decision I have arrived at based on my knowledge in my practice area. When I run out of that knowledge, I look up more, beg for research or go to get the person who knows.

Some of the best projects I have worked on have resulted from being locked in a room for 16 hours a day, with all the right people brought in so we can work together. That sort of process is where I learned to push for the value of interactive design, and also to get out of my chair and ask the developers, analysts and marketing guys right now when you need to know something or get them to make a decision.

So, don't make a note for later, or promise to make a collaborative team next time. Get up or send that IM this afternoon, trust them to do their job and also to give you the right answer.

* These are pretty much straight rips from other sources. Everything else I wrote.

I need to start just writing down about half the things I say, apparently. I am constantly finding some other brilliant blog post or tweet that makes me go “of course. We already do that.”

Kate Rutter at Adaptive Path recently posted about no longer using the word “web page.” I think that post went on a bit much about the philosophical underpinnings of the original term, and I’m not loving a lot of the terms she came up with. It reminds me more of some terminology I have created in the past couple months regarding eBooks (settled on “page” as a reference to the original book only, and “leaf” as the unitary, non-scrolling content in the current viewport).

As a general rule, I agree with tossing the term “page” for interactive products. I still think you have to know your audience and I use “page” and “web page” periodicially. It’s okay, as long as you know it’s wrong and work towards the right solution.

And here’s where it matters. Semantics matter, because they carry meaning. Replacing one word for “a fixed piece of content” with another is not that helpful. As I address briefly in my book on design process there is no difference now between applications and hypermedia. The whole concept of a page, leaf or card is suspect. More importantly, it constrains you as a designer.

My terms are along the lines of “state” and “view.”

I’ve started trying to clearly talk lately about the difference between interface design and interaction design – and other types, but these two get confused a lot. And interface design is not bad, but too many interface designers think they are interaction designers. Interface design is good and important, but (as I define it) it’s about the relationship of items within a single view.

Interaction design begins when the view changes, or between different views and states of the system, or related systems. Thinking entirely about decks views lets you loose sight of the basics of interactive design:

• Information
• Interaction

Nothing else is basic. So everything is up for grabs in the design. Why, therefore, does a new piece of information get a new page? Why can’t it modify the display properties of the application as you are currently looking at it? That’s a new state of display.

I fell into hating the term “web page” years ago, but not because I felt it was dated or over-used or because someone told me it was. It was a natural outgrowth of thinking about design from the ground up. Flowing directly from problems, to information design, to interaction design, to interface design… and having the revelation that there are no web pages anymore.

The other day the team here at Little Springs working on [the other big project] were talking about one of their next phase deliverables, a help system. So I jumped in and intruded with all my ideas. Open plan offices are great for this.

Especially in my time at Sprint, building large scale account management systems, I've run through a lot of serious help systems, that had to meet specific financial and satisfaction goals. So, I've not just designed a lot of help stuff, but had some user research, and metrics on effectiveness. I am therefore pretty confident these methods all work. It should also be mentioned that this is not mobile-specific. That's a subset which I haven't worked out quite as well, but will try to someday. This is more like application and web systems help.

And after I gathered all my best practices to present to them, it occurred to us that these seem to be published nowhere else.

My guiding principles are that most help systems suffer from two distinct problems:

1. That you need help at all.
2. Internal organization and jargon.

Solving these will guide you to the right design.

Problem: That you need help at all

What I mean here is that customers don't want help. They usually don't want to pay bills, or change their settings. In their heart of hearts, they just want everything to work, seamlessly. When it doesn't that's a problem, and help gets called on in these dark times to get them out of it.

To solve for this fundamental problem:

• Design as though you have no help system — I almost never design a help tab or little question-mark icons into my basic system designs. Any user going to help is a failure of the design, so work to avoid that with other design principles. Don't throw errors. Make everything clear. Set expectations, and follow them up.
• Pre-empt help questions — When you come across a problem, very often you can solve it by sticking the "help" content on the page. Whether it's explanatory intro text, hint text below the form fields, or a balloon that pops up when you fill in that field wrong, you can tell the user how to avoid errors, or that something is wrong before it's a serious problem.
• Simplify errors — Though back to system design, this is the sort of thing that often tends to come up only when detailed help documentation is being created. One example serves to illustrate this best: A web-initiated SMS sender I designed once, which attached to a number of different back end systems. Any number of them could fail, in a number of ways. Development had cut down the 80-some errors to 15. But the user can't fix them and they all meant "something is wrong, try again" or "something is very wrong, try again later." So we cut down to two messages, with basically that text. If you have more than a handful of error messages, something is certainly wrong.
• Place help content contextually — "Help" does not have to mean a pre-packaged, self-contained knowledge base. Often, it should not be. I covered this some in the pre-emptive stuff above, but the principles apply more universally. If the user calls for help, it can appear on the page. When browsing help, make sure it's a new window, and you can regain focus on the application (or browser window) so the customer can follow along with your recommendations. Make sure interactive help is at least no worse than a book open on their desk.
• Contextually link to and within help — Launching help should pretty much never just open a help home page. Take the user to the help topic, or section, for their current location in the system. Sure, there will be a search, and other navigational elements to help them move around, but most of the time help is related to the location from which it was launched.

Problem: Internal organization, and jargon

All too often I encounter, or have to build, systems that are communicated in the way the company works, instead of the way the user perceives things.

• No FAQs — We've all seen it: the "Frequently Asked Questions" section of a brand new website. Frequently asked by who? And it's true, that almost all of these are just what some marketing team or other has dreamed up. Users see through this. They are as cynical about FAQs as you can imagine, and disregard them whenever they can find a better solution. Not that the concept is bad. If you can actually talk to the customer service arm of the company, and get the top 100 call reasons, go right ahead and narrow them down to the top 10-20 basic problems. Be sure to highlight them somehow (whether inline or as a topic area on the help landing page). But don't call them FAQs if you want any users to read them.
• Gather and organize information carefully — The best way I have found, on anything like a reasonable budget, to get help topics written is as follows: Get "help topic writing" to be a task on each developer's checklist. Right after successful unit testing, he has to write up the topic. These all get gathered up, and the product manager (or account manager, or development manager, depends on the dev team) reviews them to make sure nothing is totally unexpected. They can also turn impossible jargon into something useful, or reject them as too dense and ask for rewrites. Then the UX team organizes them in a sensible manner (see next bullet) and gives the final result (with reference back to the original topics) to the tech writer to clean up. With more time or money, you bring the writer in earlier and earlier. To the UX meeting, to review, even to interview the developers directly about what they wrote.
• Organize help like the application, site or service — Assuming that you have managed to build your product correctly, do not then fall back on the way the business is run for your help system. In fact, once you have all the help topics in hand, laying the product information architecture on top of them is often a good organizing principle for the topics. Sub-organize and cross-link all you want, but make the topics reflect the product. This also helps when you want to link to the help system from any location; there's a heirarchically-relevant location in the help architecture to send them to.
• Use common terms, not jargon and brand terms — Unless of course, your product is full of jargon and brand terms. And even then, also use the more common terminology along with it "Super FrogConnect, high speed 802.11g WiFi, can be configured..." Be sure to use several levels of terminology, to appeal to experienced and novice users, as well as tying it to the product.
• Teach the users, using good educational practices — I am not an instructional designer, but I know some. All I remember is that I have encountered normal distributions with visual learners on one end, and textual on the other; and on one help system I included diagrams of the new account management structure. Which worked great. And is especially important if something about your system is new, or breaks previously-established expectations. Be sure to hire a good writer, at least, and someone like an instructional designer if you can. They'll tell you more about this.
• Don't make users classify themselves — In theory, knowing the knowledge level, or intended use of the customer is a great thing. You can give them the correct experience, or here the correct sort of help language. In practice, this is a total non-starter. Even when people can classify themselves in useful ways (which is rare) they usually resent it. You don't need more ways to annoy customers, so just present the information and take your best guess as to how to communicate to them.

Be trustworthy

There's a sort of third principle that emerges when you look closely at these, and that's Trust. Sure, it's a common principle of all interactive design, but as I explain in my book on design process it's good to identify which of these principles are most important to the targeted users of your particular product.

Certainly, help systems need to be easy to use, transparent, preserve user data, identify them personally and so on. But trust is the biggest problem. Customers seeking help are (almost always) having a problem. You are already in a hole, and any friction is going to add to the frustration.

Aside from informing the rest of the design, this leads to one last best practice:

• Let your customers call you

This is rejected a lot by folks looking to cut Customer Care costs. Phone calls cost money, so anything to redirect them is good. But it's one of those where the conventional wisdom is wrong.

I'm not saying calls don't cost money. But customers already on the website are (generally) trying self-care anyway. They want to solve the problem themselves. Putting the phone number at the bottom of every screen doesn't drive more calls, it gives customers the confidence that they can try to solve the problem themselves. If they can't figure it out, they know there's someone to help them. Call rates often go down the more you add the number to the website.

This is not a theory. Several times I have seen this borne out by data, and I've heard the same from others, in all sorts of industries.

So, in summary, my best practices for interactive help are:

1. Design as though you have no help system
2. Pre-empt help questions
3. Simplify errors
4. Place help content contextually
5. Contextually link to and within help
6. No FAQs
7. Gather and organize information carefully
8. Organize help like the application, site or service
9. Use common terms, not jargon and brand terms
10. Teach the users, using good educational practices
11. Don't make users classify themselves
12. Let your customers call you

Lots of “speed” tips are focused on content providers. Plenty of information available. Here’s a starting point.

In general, tips for speeding up a web site will help for at least some devices, but there are some extra niceties for mobile optimization.

Start with the giants: check out

• Yahoo: Best Practices for Speeding Up Your Website
• Google: Let’s make the web faster.
• Google: article focusing exclusively on mobile

Some specific tips:

• Each fetch request adds to latency, even more than most desktop users’ requests. Collect images into a single file.
• Design and develop as if all users were using satellite connections.
• Whenever you see a desktop maximum size recommendation, guess that you should multiply the number by 10%.
• Understand “make sure your size is no larger than 25k because that’s what the iPhone can support” type advice is not helpful for anything other than the iPhone. And 25k will take a while to download even on an iPhone.
• HTML 5, while not yet a standard, is becoming available for high-end mobile browsers. Local data cache can really speed things up.
• Design efficiently. Do you really need the JQuery library? It’s nice, but it’s big. Could you get away with a smaller framework?
• Use progressive enhancement. Design a great experience for less capable devices, and enhance it for more capable.
• Don’t get carried away with progressive enhancement: don’t send down code that a device doesn’t need.

Speed and effectiveness

Speed is not just about speed; we have to consider perception of speed. We talked about that quite a bit in part 1 of the series.

Good design is about more than just speed; sometimes slower speed can result in faster perceived speed and higher satisfaction. If a user is having fun or is easily achieving her goals, she will perceive the site (or application) as being faster.

And not all speed is the same. In general, interfaces that mimic physics, such as the buttons, sliders, and scrolling in most touch interfaces, must respond immediately. The illusion of physics must not be broken. But the parts of the experience that do not mimic physics, such as following a link, can have a delay.

So the design team must design well (there are lots of tips over at Design For Mobile), and must help the entire team decide when to break the speed optimization discussed above. For example, delivering larger image sizes than strictly necessary can enhance the experience. Using the occasional gradient can enhance the experience.

It’s a balancing act.

With all the latest announcements for e-readers and book pricing, I’ve been thinking a lot about the nature of reading recently. It seems like each company’s reading experience presumes everybody and every bit of content is the same experience.

Amazon is quite proud of their $9.99 pricing for e-books. They claim that it is cheaper than paper. And it is … for one type of reading. If you read mass market hardbacks or trade paperbacks (the ones that are the same size as the hardbacks) then $9.99 is cheaper than $15.99 or $25.99.

I do that type of reading, but only for professional-related books. These books I might want to learn from, cross-reference, make notes for adoption at the office, and so forth. I will read while traveling, but not relaxing in the tub. I don’t really share these books with my friends, though I share some of the ideas with my colleagues.

In contrast, my personal reading time is spent almost exclusively with cheap paperbacks. They’ve increased in price to $7.99, which I think is too much, but I pay it anyhow. I actively share these with people I live with, and share with friends. These are the books I take into the tub, and are more likely to come to bed with me. I keep them for a long time, but if they get lost on a trip or wet in the tub, it’s okay.

Several of these books currently live on the shelves of the people I lent them to, and while I’d like to have them back it’s completely livable. You can tell which series I really enjoy, because I no longer have the first book in the series. It’s been loaned elsewhere.

Then there are newspapers and magazines. This content is temporary by its nature, and at least for me is more akin to skimming online news and blogs.

These are not the only types of reading out there. One of the key lessons in graduate school was how to read research papers. Reading for learning or book clubs might also look very different. Reading business documents, at least in my product development world, really needs a large screen and a strong social connection. The documents do not live in a vacuum, and their business context must be considered while reviewing the product requirements document. I suspect that legal reading is different again.

Each manufacturer/provider has presumed one type of reading. Kindle is targeting trade paperback/hardback reading, largely for pleasure. The Que is designed for business use. Hearst’s Skiff is targeted more at newspapers. Apple is going after content deals galore, including textbooks and newspapers. None appear to target my pleasure-reading needs.

I’m not really worried about device fragmentation in the e-reader market. We know how to design and develop for that. I’m more worried about the purpose fragmentation. Is one going to win?

Clearly the mobile phone will continue to win here. The Kindle’s ability to continue reading on the phone where you left off on the device is brilliant. But the problems with sharing and moving content to other places still plague them; I only want to purchase material I know to be temporary. This is an industry DRM problem, but Kindle appears to be extra protective. Still a no-go for me.

In the meantime, I’m still reading the occasional book on my phone, and carrying several paperbacks on trips.