Tuesday, January 03, 2006
The need to build WAP sites vs. better mobile browsers
I was inspired/relieved by Scoble's calling out of sites that don't have a mobile presence. Great idea, and I hope his crusade gets companies to get with it. Probably won't though, if user demands, competitive pressure and revenue potentials haven't forced them to move to portable media already. (I'm glad I won't be on his list. We do WAP, PDA, SMS and MMS access for our news, and are rolling out streaming mobile video, so I think I'm safe.)
Scoble warns:
Should we leave our desktop sites as-is, but giving pages an option to do alternative rendering if the requesting device is a portable? Is this feasible knowing the Treo's Blazer, Windows Mobile 5.0's IE Mobile and Opera Mini will display content just fine on devices with reduced bandwidth and limited screen size?
For the moment, and predictably for the near future, the answer is a strong "no". Innovation's not that fast and adoption won't be that quick. That kind of market penetration will undoubtedly be the case someday, but for the moment we still need to work in the WAP world and migrate our applications and data across disparate platforms for maximum exposure, accessibility and competitiveness.
One of the tenets of wireless development - and arguably of web design in general - is working towards the least common denominator. Most people with cell phones can finally do WAP, so that's the overwhelming majority of our target audience. With streaming media, we previously had to release multiple streams encoded at different bit rates to satisfy low- and high-speed Internet users. Now software can intelligently detect the client's rate of connection and serve the most appropriate stream. Possibly such auto-detection will be available down the road, but while the future's bright, we've got to deal with what's out there now.
And at the very least, to keep ol' Rob off your case.
Scoble warns:
I’m going to call these sites out with increasing frequency in 2006. If your site makes you scroll for 20 minutes just to see your content, it sucks. It’ll get called out. If your site squeezes a column so that it’s only one word wide, it sucks. It’ll get called out.Steve Rubel also projects mobile web access being even bigger than it was last year:
In 2006 the mobile Web is going to be far more mainstream than it was last year, especially as EVDO (definition) access prices come down. I recently decided to retire my bulky Treo 650 in favor of a wafer thin Motorola RAZR V3C phone from Verizon that is enabled with VCAST for high-speed access.But I'm thinking that with advancements in mobile development, should we developers and designers worry about drilling down into WAP, CHTML and other wireless platforms and formats, or concentrate on helping vendors create more powerful web browsing software? Can we rely on phones with better microbrowsers having increased capabilities, growing device support for Java MIDlets, efficient handling of multimedia, and even proper ports of AJAX functionality?
Should we leave our desktop sites as-is, but giving pages an option to do alternative rendering if the requesting device is a portable? Is this feasible knowing the Treo's Blazer, Windows Mobile 5.0's IE Mobile and Opera Mini will display content just fine on devices with reduced bandwidth and limited screen size?
For the moment, and predictably for the near future, the answer is a strong "no". Innovation's not that fast and adoption won't be that quick. That kind of market penetration will undoubtedly be the case someday, but for the moment we still need to work in the WAP world and migrate our applications and data across disparate platforms for maximum exposure, accessibility and competitiveness.
One of the tenets of wireless development - and arguably of web design in general - is working towards the least common denominator. Most people with cell phones can finally do WAP, so that's the overwhelming majority of our target audience. With streaming media, we previously had to release multiple streams encoded at different bit rates to satisfy low- and high-speed Internet users. Now software can intelligently detect the client's rate of connection and serve the most appropriate stream. Possibly such auto-detection will be available down the road, but while the future's bright, we've got to deal with what's out there now.
And at the very least, to keep ol' Rob off your case.
Subscribe to Posts [Atom]