JQuery for Mobile Web Development

In 2009, Neilson estimates that 21% of Canadian mobile subscribers use their phones to surf online and check their email. There are 3.9 Million unique mobile internet users in Canada

Juniper estimates that worldwide users of mobile web services will increase from 577 million in 2008 to more than 1.7 billion in 2013.

Clearly, mobile web development is going to become more prevalent and a part of integrated campaigns.

Developing for the multiple handsets with their myriad of standards can be a frustrating experience -- and explaining the intricate nature of those differences to a designer who has to design an interface or an account manager who has to explain to the client can be a lesson in futility.

That is why I love when someone comes up with a clear, tested standard - with visuals and handy charts. It makes the job of Sherpa tech translator much easier.

JQuery, one of my favorite libraries has done such a job. JQuery mobile is a subset of the popular library that does an incredible job of standardizing interface elements across all the supported mobile browsers.

JQuery mobile even comes with a handy chart for Account Managers to show very clearly what browsers are supported.

They have rated browsers as the following

A High Quality. A browser that’s capable of, at minimum, utilizing media queries (a requirement for jQuery Mobile). These browsers will be actively tested against but may not receive the full capabilities of jQuery Mobile.

B Medium Quality. A capable browser that doesn’t have enough market share to warrant day-to-day testing. Bug fixes will still be applied to help these browsers.

C Low Quality. A browser that is not capable of utilizing media queries. They won’t be provided any jQuery Mobile scripting or CSS (falling back to plain HTML and simple CSS).

Authentication Methods

There are several industry standard methodologies to provide single sign capability. Due to the level of integration required, creating a customized solution would be cost prohibitive and would lack the credibility in terms of security and standardization that all of the following solutions have.

Open ID

OpenID is an open, decentralized standard for authenticating users which can be used for access control, allowing users to log on to different services with the same digital identity where these services trust the authentication body. OpenID replaces the common login process that uses a login-name and a password, by allowing a user to log in once and gain access to the resources of multiple software systems.

An OpenID is in the form of a unique URL, and is authenticated by the user's 'OpenID provider' (that is, the entity hosting their OpenID URL). The OpenID protocol does not rely on a central authority to authenticate a user's identity. Since neither the OpenID protocol nor Web sites requiring identification may mandate a specific type of authentication, non-standard forms of authentication can be used, such as smart cards, biometrics, or ordinary passwords.

OpenID authentication is now used and provided by several large websites. Providers include AOL, BBC, Google, IBM, Microsoft, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!.

Logging in

The user visits a relying party web site (e.g. website.relying.com) which displays an OpenID login form somewhere on their page. Unlike a typical login form with fields for the user name and password, the OpenID login form has only one field—for the OpenID identifier, typically along with a small OpenID logo: Openid small logo.png. This form is connected to an implementation of an OpenID client library.

A user typically will have previously registered an OpenID identifier (e.g. alice.openid.provider.org) with an OpenID identity provider (e.g. openid.provider.org). The user types his OpenID identifier into the aforementioned OpenID login form.

The relying party web site typically transforms the OpenID identifier into a canonical URL form (e.g. http://alice.openid.provider.org/). With OpenID 1.0, the relying party then requests the web page located at that URL and reads an HTML link tag to discover the identity provider service URL (e.g. http://openid.provider.org/openid-auth.php). The relying party also discovers whether to use a delegated identity (see below). With OpenID 2.0, the client discovers the identity provider service URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.

SlashID

Unlike OpenID, SlashID operates closer to a password and profile manager. SlashID keeps up with information such as the user's email address, website, and contact information, and sends that information to the requesting website when the user inputs their SlashID username and password.

Both systems require the website to support the feature before it can be used, and this is their main obstacle in achieving universal acceptance.

The Benefits and Downside of SlashID

The major benefit of SlashID over OpenID is its ability to keep track of more information, which makes it more adaptable to websites. A user can even have multiple profiles, so if they want to use one email on some websites, and a second email on other websites, this can be easily accomplished.

The biggest downside of SlashID is its current dependence on a single website. While OpenID allows almost anyone with their own website to set up an OpenID server, SlashID is run from a centralized source. There are plans to decentralize the authentication process, but this will be dependent upon SlashID gaining some acceptance across the web.

Implementation

Both of the above methodologies for granting authenticated access are similar. In both cases the third party sites must install and configure the authentication libraries. Security changes to the third party sites must include the implementation of the library on the front end.

Additionally, the company would have to control the token ID's that are permitted authentication.

Hyperspeech Transfer Protocol (HSTP)

Giving a new dimension to the internet, the Indian research arm of the US-based IT giant IBM has developed a technology that will allow users to talk to the web and create voice sites using mobile phones.

SQA Methodologies

In large, complex applications, such as operating systems, it is practically impossible to iron out every single bug before releasing it both from a difficulty point of view and due to time constraints. Different software applications require different approaches when it comes to testing, but some of the most common tasks in software QA include:

• PPQA audits: Process and Product Quality Assurance is the activity of ensuring that the process and work product conform to the agreed upon process.
• Validation testing: Validation testing is the act of entering data that the tester knows to be erroneous into an application. For instance, typing "Hello" into an edit box that is expecting to receive a numeric entry.
• Data comparison: Comparing the output of an application with specific parameters to a previously created set of data with the same parameters that is known to be accurate.
• Stress testing: A stress test is when the software is used as heavily as possible for a period of time to see whether it copes with high levels of load. Often used for server software that will have multiple users connected to it simultaneously. Also known as Destruction testing. Fault injection is especially useful for any software system with exposed interfaces, e.g., protocol implementations.
• Conformance testing: Confirms that the software implementation complies with established standards.
• Load testing: Establishes the maximum amount of traffic that a target can accept.
• Usability testing: Confirms that the software solution is "user-friendly" enough.
• Robustness testing: Software systems are presented with invalid or unexpected inputs to determine whether they have robust error-handling or input validation. Such systems pass the test(s) if they can tolerate a wide variety of invalid or unexpected inputs across the entire protocol interface specification.

ADA (Americans with Disabilities Act)

One of the better legislative rules that have forced web developers to pay attention is the introduction of the ADA and the resultant guidelines that they force developers to use.

The primary function is to provide alternative means and to facilitate assistance technology like screen readers to access content and functionality on your site.

Generally, the guidelines state that you must
a. provide text equivalents for non text elements (i.e alt attributes and/or LONGDESC)
b. avoid dependence on colours (i.e. red lettering for error messages)
c. avoid actions that are not triggered by user input.

HTML should be used for structure and CSS for style.