Archive for the ‘MobileWeb’ Category

Mobile AJAX FAQ @ Horizon Channel

Thursday, June 7th, 2007

Earlier this week, Rocco Georgi, Bryan Rieger, and Ajit Jaokar published their Mobile AJAX FAQ at the Horizon Channel.

There has been a number of reactions to it that you can find in the blogosphere, Ander's response is here, and Mike Rowehl's response is here, both who are mobility practitioners who emphasize that Mobile AJAX is not ready for prime time.

My perspective on Mobile AJAX is that its time will come, but when taking in consideration the essence of the mobile context, and the user experience, and the current state of the mobile browsers in general, its time is not today, not for advanced mobile applications…

But to get there, it is a good thing to start today documenting terms, and FAQs, and work on mobile browser standardization and consistent behavior, and so on.

For additional background information on the Mobile Web and its future, see the Mobile Web FAQ

ceo

The Future of Web Applications is "Local"

Monday, June 4th, 2007

The disconnected Web… the future of web applications is "local". The line in between that separates "local" and "web-based" applications will continue to blur.

First Dojo Offline, now Google Gears, next Mobile…

The future of the (mobile) web applications will continue to move toward local; same concepts, different mechanisms — for mobile web it will be about local script-based, disconnected application, with access to local resources and capabilities, served and updated by web servers…

The user experience (from latency, cost of ownership/operation, to rich and media-rich user-interfaces) demands/enforces this path; it is the same reason why today mobile is about local applications (written in Java and native)… it is about delivering a better user experience… and this is the reason why future mobile web applications will follow the same path. It is the logical next step.

And this is especially true for mobile, including mobile web. While the tendency (thinking) about mobility is towards “always-on”, mobile will continue to be an “occasionally connected” environment. The ability to work disconnected is particularly useful, and necessary, on mobile in general. It is the natural evolution to "move to the edge".

Previously I wrote a piece about The Dojo Offline Toolkit, and its relationship to Mobile Web. Now Google has released Google Gears with their approach to web applications to run local:

  • Store and serve application resources locally
  • Store data locally in a fully-searchable relational database
  • Run asynchronous JavaScript to improve application responsiveness

…it is part caching, part about storing the web application itself locally: the application scripts, and the supporting (framework) scripts, all local.

But for mobile web, we will see a tendency where such supporting scripts, both to support offline and local access will be part of the (local) browser runtime — it is about the web runtime:

"It's not about AJAX, or Widgets… it is about the mobile web “runtime”. The “runtime” is what makes thin clients dynamic and exciting. The “runtime” is what allows for client-side scripting, and AJAX, Widgets, and other methods not invented yet.

The “runtime” and consistency across (mobile web) “runtimes” is what is going to make mobile browsing what needs to be.

The (mobile web) “runtime” doesn't have to be the browser. This is especially true for mobile."

In addition to the ability to work disconnected or offline, there are other characteristics future browsers will and must exhibit, such as access to local capabilities beyond storage. See the Mobile Web FAQ for more information about this and other the Mobile Web information.

The future of web application is local… sounds ironic, doesn't it? …but it is true.

ceo

(Originally written on June 4, 2007)

Nokia Web Browser Design Guide

Friday, June 1st, 2007

Nokia published a new Web Browser Design Guide (PDF). It covers:

  • Overview of the (S60) Nokia Web Browser
  • Content delivery, usability, and development and testing environments
  • Basic Web development issues
  • Site layout design
  • Media formats
  • Progressive enhancement – the future Web design philosophy

The Nokia Web Browser is industry standards compliant, with support for:

  • HTML 4.01, XHTML 1.0, including image maps, frames, background images, <meta> and <object> tags;
  • CSS 1, 2, 3 (partially), including external style sheets;
  • DOM 1, 2;
  • SVG-Tiny;
  • JavaScript 1.5.

The browser supports plug-ins for SVG-T, audio, and video.

ceo

Mobile Web FAQ has been updated

Wednesday, May 16th, 2007

The Mobility Resources Mobile Web FAQ has been updated…

(I'll announce “updates to the FAQ”, when major or considerable changes are done).

ceo

The Dojo Offline Toolkit, and its relationship to Mobile Web

Saturday, April 28th, 2007

Dojo Offline

The Dojo offline toolkit allows for web applications to work offline. It consists of a JavaScript library (bundled within the web page) and a ~300K download with the logic to cache a web application's user-interface for offline use.

How is Dojo offline related to mobile web? Right at this moment, not directly.

But Dojo offline touches on a very important and needed characteristic, a key feature that future mobile web browsers must support:


“The ability to work disconnected”, or “Support for disconnected or offline browsing (cache), allowing the Mobile Web application operate as an occasionally connected application”

See the Mobile Web FAQ for more information about the Mobile Web, and about other characteristics that future mobile browsers must exhibit.

From the mobile perspective, the 300KB+ Dojo offline download is pretty stiff, and again, caching is of great importance.

ceo

Mowser

Thursday, April 19th, 2007

Mowser

Russ Beattie has introduced Mowser web content translation technology for mobile web. Neat… there is so much to be done in this space of “proper web content translation for mobile web”… I tackled this problem many years ago, on a different but related problem-area, and I'll tell you that it is good to see Russ tackling and solving this problem-space…

ceo

Mobile Web FAQ

Tuesday, March 27th, 2007

I started putting together a Mobile Web FAQ with focus on design, development and resources, including answers to questions such as what is the Mobile Web, Widgets and Mobile Widgets, future and other. This FAQ should in theory complement Ajit's Mobile AJAX FAQ.

See Mobile Web FAQ; the FAQ is a living document…

ceo

dotMobi Mobile Web Developers Guide

Monday, March 12th, 2007

dotMobi
Blue Flavor

The dotMobi Mobile Web Developers Guide, written by Brian Fling of Blue Flavor, is now available.

dotMobi Mobile Web Dev Guide

It contains great tips and information on creating mobile web applications for dotMobi, but also great tips and information on mobile web development in general, regardless of dotMobi.

Related:


* Brian Fling (Blue Flavor) Mobile Web Presentation @ SXSWi


* dotMobi developer's page

ceo

[Image source: dotMobi]

Brian Fling (Blue Flavor) Mobile Web Presentation @ SXSWi

Monday, March 12th, 2007

SXSW


Brian Fling


Blue Flavor

Brian did a wonderful job with his presentation on Mobile Web development at SXSW Interactive which was titled “Everything you always wanted to know about the mobile web… but were afraid to ask”.

Both content and how he presented were great.

The room was packed, I would say like 200 people, showing the increased interest in mobile web (note that SXSW Interactive attendees are all across the board, so having this kind of attendance, on this topic, shows people's interest on the topic; is great).

The presentation focuses on present or current mobile web development.

It was great to finally meet Brian.

ceo

Paxmodept's Javascript Test Suite for Mobile Browsers

Friday, December 15th, 2006

Jason at Paxmodept has created a (basic at the moment) test suite to help investigate Javascript and DOM support/capabilities in mobile browsers. See his announcement.

ceo

W3C mobileOK Basic Tests 1.0 Working Draft

Tuesday, November 14th, 2006



From the W3C web site:


…The Mobile Web Best Practices
Working Group has released the First Public Working Draft of W3C mobileOK Basic Tests 1.0. This document defines the tests that provide the basis for making a claim to be W3C mobileOK Basic compliant and are based upon W3C's Mobile Web Best Practices. Read about Mobile Web Best Practices Working Group.

ceo

W3C WICD Mobile 1.0

Thursday, October 12th, 2006

Are you aware of the W3C Web Integration Compound Document (WICD), and its mobile version, the WICD Mobile 1.0?
The
WICD Mobile 1.0 specification is going to be a very important piece moving forward for Mobile Web and mobile browsing, and in the convergence between rich-local clients and browser-based technologies.


The WICD Mobile profile is primarily designed to enable rich multimedia content on mobile handset devices. These are devices with:

  • small, narrow screens (approximately 2 to 4 inch, up to 30-40 characters per line)
  • 4- or 8-way joystick navigation (no pointing device)

The WICD Mobile specification defines (standardizes) the use of the following for Mobile Web:

  • XHTML Basic 1.1
  • ECMAScript 3rd Edition Compact Profile
  • CSS 2.1 Mobile Profile
  • SVG Tiny 1.2
  • Bitmap formats
  • Audio formats
  • Video formats
  • User Agent Identification
  • DOM Level 3
  • XMLHttpRequest
  • Focus Navigation Model

ceo

[Image source: W3C WICD Mobile 1.0 spec]

On .mobi

Thursday, August 24th, 2006

I haven't expressed much about how I feel about .mobi – months ago I wrote a piece about it, but never finished editing it… Today Carlo wrote a very good piece on .mobi, which I am going to piggyback…

.mobi is not needed. There is no technical reason for it, and there is no user experience reason for it (you can accomplish the same without .mobi), and there is no business reason for it. And the way it's being introduced has much to be desired.

I've read the .mobi guidelines, and they are open to interpretation and that is a problem. And the reason it is open to interpretation is because it is next to impossible to put guidelines around web applications look-and-feel, without hurting innovation and progress.

The .mobi folks are trying to bypass the most important piece in the evolution of the (mobile) web – letting the market, the users, decide what is good or not good. If a mobile website is no good, well, people won't use it. Good websites will do well and will stick around and be examples for new websites. This is not rocket science, and it doesn't need a business model around domain names, look and feel, or certifications.

For those who are thinking about reserving a .mobi domain, doing so 1) is going to possibly SLOW down things for you, your progress and time to market, and 2) there is no real gain on .mobi – as I mentioned before you can accomplish the same goals without .mobi. Why add yet another domain, related costs, and possibly delay your product to market? What is important is your brand-name and company name – why confuse the user with .mobi or similar attached to your name. You want your users to type in your brand-name, or company URL from anywhere, and that yielding good results. What is important is that you use your common sense when developing mobile websites. What is MORE important right now is fixing the out-of-the-box user experience, which has nothing to do with your mobile website or .mobi or URLs, but more with how handsets are configured by default, and with walled-gardens, and hoops users have to jump, and cost at the carrier, to get to the desired website, and things like that.

No need to establish precedence with .mobi. Today we have the .mobi guys pushing their solution, with the best of intentions, but worst of solutions, and tomorrow we may have the .settopbox guys pushing their own URL/domains. And the result is us, the product developers going through hell with bids, and more costs, and time spent and distractions, and the customer confused, having to first think what URL to type based on the device/computer they are using, before going to the site (yes, future mobile browsers may auto-complete the .mobi URL, but that is just masking the real problem).

What gives .mobi folks the right to define what is good or bad experience? Who are they to determine what a difficult navigation, or poorly formatted pages, or inappropriate or excessive content is? It is all relative. No need to impede innovation by restricting the user experience to a predetermined set of ways or guidelines. And it is not their job or role to decide what is good or bad. Let the user and market decide.

.mobi will NOT solve barriers. It will not solve difficult logins, or slow access and long load times (a moot point as network connection speeds are drastically improving), or make things better. It is all common sense anyway. Let's start fixing the user experience from the bottom up, starting at the handsets, and the carriers, and let the web evolve, as it has for the last 16 plus years. Let the normal evolution of the mobile web, and time, take care of how mobile web sites should and will look and feel – believe me, the users, market and time will take care of it.

I only see one positive thing (maybe) with .mobi, but I will cover that in another write-up.

In conclusion, .mobi introduces more harm than good. While the purpose of .mobi is the improve the mobile user experience, which as previously mentioned it can be perfectly accomplished without the need of a .mobi, it does so by introducing restrictions that impede innovation, and that introduces unneeded precedence. It also confuses the user, as well as brand-names.

I predict that .mobi will go obsolete. As companies learn how to detect a handset and redirect to URLs such as mobi.company.com or www.company.com/mobi (the way it should be), .mobi will be just another redirect that over time will become irrelevant.

ceo

W3C The Mobile Web Best Practices

Tuesday, October 18th, 2005

[Via W3C]

The W3C Mobile Web Initiative Working Group has released the First Public Working Draft of Mobile Web Best Practices 1.0.

“The draft describes how to produce Web content and Web sites intended
for delivery to mobile and small-screen devices. Writing for a wide
audience, the group invites feedback from developers and network
operators as well as Web professionals who are not technology
specialists.”