All posts tagged as "Carriers"

I am thrilled to announce that we have announced the first of the speakers, more details, and the registration page for the first North American conference focused on mobile design, Design for Mobile.

Speakers include researchers, visual designers, interaction designers, UI developers, and design strategists. They work in operators, device manufacturers, open source, academia, content companies, technology companies. They work on web, applications, services, devices, and best practices.

We've more in the works, so stay tuned.

Register now!

Over on the Mobile Design and wmlprogramming mailing lists, Pedro Barros José asked views on content adaptation (minor corrections made):

1. What is the future of Content Adaptation?
2. What are the main factors dictating that future?
3. Who will be the main players?

To help further streamline the discussion, let me know categorize the different types of Content Adaptation (inline with the W3C).

1. Server-side Adaptation: where the web server employs some type of device detection together with a Device repository, to then optimize the content sent to the requesting device based on the device’s capabilities (e.g. Drutt, MobileAware, Volantis, etc).
2. Network Adaptation: web content is altered or “transposed” by one or more network components (e.g. Opera Mini, the infamous Novarra transcoder used by Vodafone)
3. Client side Adaptation: reformatting of content typically done on the device by a mobile browser (e.g. Opera Mobile browser)

Essentially looking at answers/opinions to the above 3 questions for each of the above 3 categories.

In short, content adaptation is here to stay. Not all web sites will have mobile-friendly versions, so gateways and/or clients will do some sort of adaptation. This will continue for as long as mobile screens stay small.

Some sites will make mobile versions, either through complete redesigns or through content adaptation processes. These will be high volume sites or mobile-targeted sites (sites for which there is a strong business case for a mobile version).

Why? Small screens, long tail sites. Time and money.

The only real problem with network adaptation is non-consensual transcoding: I make a mobile site and the transcoder assumes that its automatic system can create a better user experience than my mobile-focused version. Ha. But if you listen to the defenders of this process, you'll notice that I am not putting words into their mouths.

Using the above definitions, server-side adaptation allows the people who know the purpose of the content and the goals of the user to best adapt the site to their users' needs. Any other solution is suboptimal from a user's perspective — assuming server-side adaptation is done well!

Don't believe me? Then why, with the iPhone's fancy high end two-processor largish screen browser do companies still make iPhone-specific web sites? Because the experience is better. Zooming is a low price to pay to get otherwise unavailable information, but a high price to pay for very frequently used content.

Network adaptation is a system that makes assumptions about the intentions of the site based on how the markup is structured. This is a very hard problem, made far simpler by limiting themselves to XHTML and CSS. Even if we assume that they get even better and can magically translate all Javascript into dynamic HTML or something and make it work on scroll and select devices, they still don't really know the users' goals. This doesn't mean that the site owner really does either; I would like to tag and archive my email within Gmail mobile, but I can't. But I prefer Gmail mobile to a transcoded Gmail full sized.

Theoretically the semantic web can fix all of this. If all web pages were coded fully semantically, then maybe a system could be devised to do best-case layout for all situations. Don't hold your breath: in 2005 there were 11.5 billion indexable pages on the web. Besides, the web diverged from a semantic viewpoint to a visual viewpoint in 1996 or so.

On top of all of this, mobiles are not miniature computers. They are much more: cameras, companions, texters, connectors. Do we really want to limit mobile web to a stripped down version of the desktop web? No.

To me, the best thing to come out of the Luca vs. Novarra/Vodafone and Luca vs. W3C arguments is a concrete list of best practices for not destroying this hard work and making things worse.

Rather more complete and actionable than my open letter to mobile gateway providers is the evolving developer community’s Guidelines for Responsible Reformatting. I support these guidelines.

Keep in mind that reformatting is not necessarily bad, except when you destroy somebody else’s work.

AT&T has gotten a lot of press this week talking about its universal design principles. It’s worth a read for anybody in mobile development, as is the training offered by both major sources for their definitions: North Carolina State University Center for Universal Design and the University of Wisconsin TRACE Center (I’ve had training both places).

I applaud AT&T’s new-found desire for universal design. Not only did I write about the business model in my book, Designing the Mobile User Experience, but I’ve written about different software and devices to improve mobile accessibility. When I was at Sprint, I managed to get a few improvements on a few devices. Not as many as I wanted, but a few improvements.

My concern with this announcement and this document is that they are targeting it at developers, who have very little influence over the accessibility of devices or web sites. For example, a device with a web browser that can not in any way read aloud the text can do nothing to facilitate mobile web use by blind users, regardless of how many accessibility principles the site employs. Similarly, a device with only 2 font sizes will have some issues with displaying text for folks with declining vision.

Nevertheless, increasing the visibility of the problem is worthwhile. Smart phone developers at least can come up with product improvements.

While the FierceWireless report said, “Developers must first submit applications created via Universal Design principles to AT&T for certification if they wish for the apps to be available on the operator’s Media Mall mobile site,” the press release did not indicate that would be required. I hope this remains true, because this would pretty much limit Media Mall to Symbian, Palm, and Windows Mobile applications. Not very accessible to feature phone users, now is it?

What I’d like to see is the various “smart phone” operating system providers helping out in similar ways. I think the impact would go further than the AT&T document. What I’d like to see AT&T do is buy feature phones with accessible features.

In the meantime, testing for accessibility is a variant on usability testing. If you want help with this, let us know.

There are some really wonderful mobile and mobile design resources written in Spanish. And apologies in advance for my somewhat broken Spanish abilities.

Primer, tenemos movilsur, noticias de movilidad y negocios. A mi me gusta mucho el “Graffiti” en el newsletter, de usuarios móviles. Muy bien.

Mobile Design (Espana), con muchos screen-shots. Y Usando.info es solo sobre usabilidad. Avidos es un blog sobre desarrollo y usabilidad web para dispositivos móviles.

En noticias y Telefonía, tenemos El Observatorio de Internet Móvil (trabaja en Volantis). Movilizame es noticias frecas de Telefonía móvil, casi como Digg por Telefonía.

Animatu nos da entretenimiento y marketing móvil.

Finally, though not Spanish, please see Web Librarian, about information architecture, including mobile, from Brazil.

In a number of recent projects, we’ve wanted to help users by actually giving relevant information on how to download and install a file. This sort of thing is regularly done appropriately for high end phones (S60, Palm, Blackberry, iPhone, WinMob), because the install process and messaging is consistent for devices on the platform.

Things get more difficult for feature phones. Has the operator blocked access? Will there be a “mother may I” for each access? Can the user dismiss it? What will it say? How does the user find the downloaded content?

What I’m thinking about is a repository of instructions for users, based on class of use (such as always needs access to the web) and device. An application would detect the device and render appropriate instructions from the repository.

A download web page, for example, would give accurate instructions on how to find the specific content on the user’s device, with the instructions pulled from the repository library. As this is a key failure point in using applications, this would be helpful to both users and developers.

Please, post a reply in comments. This may be something we can work together to solve.