All posts tagged as "Devices"

One of my favorite niche blogs is AAS, or All About Symbian. Saturday (my birthday!) they posted this commentary on what exactly is the difference between a featurephone and a smartphone, anyway.

The commentary is more enlightening than the original post, so read all of those as well. I tend to agree with the bulk of the statements; its about customization, customization and also customization.

Most of the people I know have classic smartphones — some Blackerries, and lots of Window Mobile devices, as we're in the U.S. Most of these are of the new, cheap variety — like the Centro or Moto Q. And they are used like the featurephones they replaced. They make calls, add up to 15 people to the address book, take photos, and download a game or two from the operator store. They are terribly excited to show off that this phone can browse the web(!)

When I show off how much more they can do with their phone by whipping out my phone, and showing off some of the 27 (yes, I counted) apps I have downloaded and use all the time, I mostly get blank stares, but sometimes hand waving that its all too complicated.

So, I have to add another facet to what defines a smartphone, the user. Designing around user-intent is not impossible, but I have yet to figure out how to to get a device data repository to encode that.

And I could seriously use a header for "savvy user." Among the biggest design worries I have is getting people to understand that their device — whatever it is called — is almost certainly capable of doing other than those core items, so that the app I am designing gets downloaded, and used.

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!

The wife and I had some friends over for dinner last night. He’s a former researcher and now is an interaction designer, all for a mobile telecom, and she works in the IT department of a large local city.

That’s her phone, a city-issued Moto Q. I’ve never played with one, but others have told me its a perfectly useful smartphone. This one is used heavily enough its got the extended battery. And… a sheet of paper, folded many times and taped to the back of the phone:

She’s on call, for system failures, disasters, other task-force qualifying emergencies. The paper is the list of on-call contacts from every other department. Apparently, this is approximately what everyone else in the municipal government does as well.

It strikes me that there’s something terribly wrong with smartphone data entry, synch or… something when whole teams of perfectly smart people with access to all the enterprise servers and security systems have to resort to significantly inconvenient paper.

Its possible, sure, that the device has restrictions placed on it. But this was not mentioned, and I know almost no one who uses their device for document reading. The call list is distributed as a PDF, and even my phone has an Acrobat reader, so why not?

I feel, despite discussions of mobiles displacing laptops, that there’s something missing. I don’t have data, so its purely anecdotal, but something in mindset seems to be preventing serious use of mobiles, at least in the US.

I see lots of calling, quite a bit of texting, some photography with some MMS, and… a little bit of other stuff, but nothing worth mentioning. A lot of what I notice is not people from my age group, but the college kids on the bus, and they have phones for calling and texting (sometimes a second device for text and email, Blackberry or WinMobile) and a music player (always iPod of some sort) that is totally separate, regardless of the capability of either of their phones. More often than not, there is a laptop, but they are usually left in the bag. Books and paper may be used.

I wonder if this is a matter of some improvement in smartphones, waiting for the next (even more mobile-centric) generation, or whether there is indeed a need for a gap device like the UMPC. Either way, it should be fun to work on.

Ever since we posted (years ago) our page on text input on mobile devices, various promoters of mobile text input solutions have been sending me their products. Unfortunately, we’ve not seen many of these hit mass market yet.

In addition to all or almost all of the providers on the text input page, new providers include:

• ShapeWriter is a virtual pen-input keyboard incorporating not just taps but strokes of the pen and some level of prediction. This is nice because it is a more natural mechanism for the human hand.


• SpeedScript is another pen-input system with stroke recognition. Alas, it is rather simplistic in its prediction methods and also has an annoying web site.


• NeoKeys is for non-touch devices, but allows each button to be re-labeled for each mobile screen. Very nice, though it makes non-visual use more challenging. Unlike the touch solutions above but like Fastap, it requires device manufacturers to invest in more expensive keypads. Which means major interaction with an operator.

FYI, any of these can at least theoretically work with Android.

Maybe sooner or later I’ll move this stuff over onto the text input page.

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.

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.