Risks of programming sites with jQuery Mobile?

Question

The jQuery team recently launched http://jquerymobile.com/ with the intent of creating a user-interface library for mobile devices.

Our aim is to provide tools to build dynamic touch interfaces that will adapt gracefully to a range of device form factors. The system will include both layouts (lists, detail panes, overlays) and a rich set of form controls and UI widgets (toggles, sliders, tabs).

Overall, it seems support for the framework is really low because most phones ship with crappy browsers. My question, is in two parts. Is it better to support a few browsers with a richer experience or give as many users as possible a merely average experience? This is similar to the question of supporting IE because the question is how much do we care about users with worse browsers?

More importantly, how much developer time is it really worth to build a mobile version of a site that isn't primarily for mobile user?

Answer 1

What you should aim to do is provide a rich experience but at the same time ensure that all of your core functionality works even when no javascript is present on the client (or it is turned off). Stackoverflow is a good example of a site that finds a good balance between those two approaches.

Answer 2

As a follow up to Silvo, I would add that the most useful answer to your question requires an understanding of your target user-base. For instance, if your target audience will not typically use mobile browsers, then you may be better off targeting a specific mobile-browser and letting those interested parties take that route. However, if your users desire the mobile-browser to be the primary interface, then you'll probably want a broader choice for functional browser options.

As a case-in-point, take all the old web apps that used to require the use of IE, simply because they (the developer(s)) didn't want to or couldn't guarantee the proper functioning on other browsers. If the target audience of this app was business users, who typically use(d) IE anyway, then this wouldn't have been a noticeable restriction. However, in a more general web app (web-mail, etc), then restricting all users to a single browser could be crippling in a competitive environment.

However, I will state that whichever of the direction you take, heed Silvo's advice about ensuring functionality, even without JavaScript. Many businesses, libraries, etc still limit JavaScript functionality.

Answer 3

Well, it's 1.0 Alpha 1, so I'd say the risks are:

1. It's largely untested, so you'll probably come across unknown or unresolved bugs as you forge new ground.
2. There is great potential for change in an early release, so you may have to update large swaths of your site, ie. when they namespace the data elements under "ui."

It's also important to consider the reasoning behind those grades:

What do the grades mean? The grades are a combination of the browser quality combined with the browser’s relevance in the larger mobile market.

An "A" grade is an indication of the browser's capabilities, not any current or future compatibility with jQuery Mobile.

If you want to help develop a new piece of software, start using jQuery Mobile, and contribute feedback, bug reports, code, or all of the above. If not, the team is hoping to see a 1.0 release in January 2011, which is just around the corner.

The theory around jQuery Mobile is providing a rich experience to rich browsers, and a functional experience to the more basic browsers. I think this is reasonable, especially considering how fast jQuery Mobile can get you up and running with a really great mobile UI.

I'd like to know what you mean by "a site that isn't primarily for mobile user." There are sites that are optimized for mobile, and there are sites that aren't yet optimized for mobile. Only some very specific niche sites don't require a mobile experience.