So if I get this right, we are talking about: Same content, different design, when it comes to the "one web" on multiple platforms? If so, then I totally agree. But should all the same content be available on all different platforms or should only the core content be available on the different platforms? I would really like to know what you think of this. I'm trying to write my thesis on "what is the future of the mobile web user experience". And this is, I think, key in the whole discussion on the "one web".
The way I see it, this is really talking about what we term "contexts of use." It starts out in the normal usability-professional manner, with an understanding of the user of course. When I got out of desktop-oriented website design, I realized pretty fast you then have to move past this to understand what the customer is trying to do at that moment. In that environment. In that context.
I've been told in the past by clients things like "business people like to read things as spreadsheets." My rejoinder is that "business people are still humans." So they should act, on average, like people most of the time. But that in fact only goes so far, and there are micro-cultures, and social considerations and special needs and transient conditions.
I am, by the way, going to be talking about all this in the coming days in both a workshop and presentation at Design for Mobile. Sign up, or get my just released book for more about my design processes.
Some of these should be really obvious, like that the screen must be readable by most of your population, in most possible lighting conditions. Some are obvious once you are told, like the precepts of the carry principle, that the device is always on, always connected, personal and so forth. Some will be unique to the type of user targeted, or the reason they might need your service.
Let's take two examples to try to make it clear without getting book-length again. The USAA mobile site (which Barbara has written about before, but we did not work on) presents only a little bit of information; some key features and a few items (proof of insurance, contact info) for crises, which is what insurance is really for. Their desktop website is full of sales, promotions and all sorts of other stuff which – while perfectly useful in the desktop context – would be superfluous on the mobile.
The Weather Channel (which we did work on) on the other hand almost entirely lives by its ability to offer timely, detailed, location-relevant content that directly impacts the user's immediate goals and activities. There is almost nothing that can be eliminated from the desktop site due to this need and expectation by users. In this case, the focus was on making the content work as well as possible within the mobile screen. Without getting into the tactics used, this took on two approaches:
- Several designs were used, but they varied by graphic details, and interaction features as needed to appeal to the target device class. This means things like touch/pen devices were different from scroll-and-select. But the core design was the same, in labels, organization (IA) and the concept behind the interaction even.
- Content did have to vary, but based on screen size of individual devices. Resolution correlates to device capabilities, but increasingly weakly, so the design variations were uncoupled from the information detail level presented. In each case, "portal theory" is used to assure the same information is available, even if in summary or clicking through is required. An example of how content was increasingly summarized based on screen size is show below.
So, you take the design process you normally pursue, and apply it to narrow the features, and perform information design tasks on those features to present the most useful information within each expected context. To get back to the comment at the top, there is not necessarily some "core" content shared between everyone, just the right content for each context.
In practice, I guess I am a bit of a believer in " two web," though I had not consciously thought so before. Probably because I don't think it's the final state of things; for a few cases today, there is a TV context/device; I can imagine a mass-market UMPC-type device/context; and what about all those other small screens like the GPS in your car? While in some ways similar, these should be different design and analytical tasks from either mobile or desktop.
As a general rule, I tend to have a core set of mobile principles, so regardless of how the detailed design deviates within one of these key mobile device classes, the information will remain the same.
Thank you very much for your insight in all of this. This will really help. Thank you!
Nice article, I would agree with you that the information stays the same across platforms. Indeed it should! Also like your point about picking content based on context–this is a very user friendly approach. We have seen extreme examples of this, like to-do lists on the iPhone that organize themselves based on where you are, and the possibilities are extremely exciting.
The one point I would add is that there is a strong argument to be made for a clearer separation between the visual design and the user interface design. While these two items seem inherently tied together, they are none the less separate, no?
Visual design deals with the issues you pointed out such as the carry principle and varying light conditions–and also with subtle issues such as brand, focal points and interest.
User interface design deals with issues such as visual mapping, interaction features (such as you pointed out), and accepted best practices/human interface guidelines for the device in question.
Lastly, you mentioned screen size as a reason for data reduction, would bandwidth also factor in?
Thanks again for the post!
I tend to not talk a lot about the different roles of individuals for a couple reasons, but mostly I really think everything overlaps a lot more than most folks would tend to agree with.
For the full details of how I think design process works, I’ll plug my book again: http://dbd.littlespringsdesign.com/
But the summary is that I am not sure there is exactly a distinction between visual designers and interaction designers in the same way there is a distinction between say graphics assets and presentational code.
I think it’s possibly because my interactive theories have come full circle, and I am back to a graphic designer sensibility (though rather formalized). I find it hard to separate the flow of information from whitespace, and the hierarchy of information from the methods of implying it (Position > Size > Shape > Contrast > Color > Form).
Visual designers can be really, really useful. I like to employ them when I run out of ideas (or the client hates my ideas), but they have to work collaboratively, meaning understand the product, understand what and why the design constraints are, and so on. That made it sound horrible and limiting, but it isn’t. Unless the designer is not good at playing with others.
> would bandwidth also factor in?
Ideally, you’d get all sorts of neat user data from the operator. In practice, almost nothing gets passed so we muddle through with third party solutions unless we know for a fact we (rarely) get something. Even then, it’s usually not for all instances, just a few operators who they have agreements with.
The not-nothing I know about radio tells me that it’s almost meaningless to use signal type (wifi vs. 3g vs. whatever) to surmise a download speed. The backhaul network has a lot to do with it and the over-the-air speed of even the snazzy high-speed networks can vary tremendously. The operators and/or devices do have at least some of this data, so it would be neat if we could get it, especially as there’s more multimedia stuff on the mobile.
Great post, Steven. Couldn’t agree with you more. The one thing I would like to add is that the reason you still might lean towards to the ‘two web’ camp, given your experience with the Weather website might be because the tools necessary for creating a ‘one web’ version aren’t available yet? That is, the degradation of certain capabilities needed to satisfy the end user’s device can’t be done (yet) with tools off the shelf.
Much of the massaging of content (for mobile consumption) must be done by hand, necessitating the use of two systems. Hopefully, as the mobile web grows, programming tools which aid in content modification (for different devices) will become more common. As of this writing, I haven’t found much in the way of code working in this direction.
Maybe you know of examples. I have looked at using ImageMagik for image modification (for mobile context), but that is still a project bigger than I can take on alone. Any thoughts?
As is my usual practice, I’ll answer in reverse order: I have done some work with specifying automated image conversion with CLI tools. I suspect, ImageMagik for some of them, but how would I know. It’s much like other designer work: I come up with rules, in english or if needed in pseudocode and then the developer encodes this into the tool. This means (aside from experiments) no one actually converts any individual files, and on-the-fly data (maps, weather, user-submitted images) can readily be converted to an arbitrary number of formats or sizes.
This can even be done at runtime; to avoid too much batching, and trying to predict how many variants you will need, instead run by pure rules and when a client requests a page, assets are generated on the fly. Currently a tad heavy on processing, so calculations have to be done whether it IS better to do this than batch convert based on your model. But it hints at a useful OneWeb future where individualized, runtime… presentational customization (I hate to say “content modification”) is plausible.
As far as ” tools necessary for creating a ‘one web’ version” I am still unclear what folks are even implying here. Is there a presumption that /universal/ display rules will emerge and smarty-pants software will emerge that does this sort of customization for everyone? Not sure I buy it, but most of all I do not think the IA side will happen. USAA is one of barbara’s favorite mobile sites for a lot of reasons (we didn’t do it), but I like that it has very little info. However, NOT a subset of the desktop info, different stuff. AFAIK you cannot get immediate, on-screen proof of insurance on the desktop, but it’s a key attribute of the mobile site.
I have problems even dreaming up a world (short of AIs so smart they are always on the verge of the Robot Revolution) where any automated tool can decide this sort of content personalization by device. It is outside of customization of the presentation, and gets into core UCD types of stuff, with user needs and context analysis and all sorts of psychology stuff.
Okay then. You guys can all keep putting this stuff here, but if it’s strictly around defining OneWeb, and coming up with tactics to help technical teams (especially, but also designers) comply with the philosophy, start working on this page in the Wiki also:
http://patterns.design4mobile.com/index.php/One_Web
Note two things:
1) This is NOT meant to compete with anything W3C — or anyone else I am aware of — is doing. It’s design centric, but until we have a solid definition it might seem like it’s stepping on someone’s toes. Just be assured it’s not trying to. And please feel free to coordinate with us so we cross-link each other if that’s allowed.
2) It’s very, very rough. Much more so than I would normally release, but it’s almost all notes like should go on thetalk page. Try not to delete things that look final, like definitions. Just add to them for now.