Mobile web browsers and SmartPhones, such as the iPhone, are rapidly gaining in popularity and the question of how to accommodate user accessing the web via Mobile phones and PDAs has become of interest to many organizations and developers.

Constrained Devices

The standard desktop monitor size these days varies from 800×600 to 2560×2048 pixels, with websites today being implicitly designed for a minimum resolution of 1024×768. Mobile web browsers on the other hand generally have screen sizes of 480×320 pixels or less.

When it comes to resolution, typical monitors have screen resolutions ranging from 67 to 130 pixels per inch (ppi), with typical modern LCD monitors having resolutions of around 96 ppi. Smartphones, typically have much higher resolution – he resolution of the iPhone, for example, is 163 ppi.

In other words a standard mobile web browser typically has one fifth the screen real-estate but about 50% better resolution then the typical desktop monitor.

Furthermore, users sitting in front of a desktop or browsing from a laptop, generally interact with the page using his keyboard and a pointing device such as a mouse or touchpad.  Smarthpone users typically use stylus or their fingers on a touch sensitive screen or miniature keyboard.

Also, most mobile devices are less powerful, in terms or memory and processing power then your average desktop or laptop and sites relying heavily on client side processing might be disadvantaged. Bandwidth might also be an issue in some cases.

Many Browsers?

While the desktop market is dominated by Internet Explorer Firefox and Safari, the mobile browser market, at least until recently appeared more fragmented. However, the leaders are quickly emerging and appear to be Opera, Safari Mobile. With Safari Mobile’s popularity being driven by the popularity of the iPhone

Nokia, is also popular choice for mobile browsing. However, I do believe Nokia’s browsers is based on the same WebKit an open source application framework that the Safari Mobile browser is based on

So for my money, unless there was definitive reason for doing otherwise, when designing for mobile device, I would simply concentrate on designing for Mobile Safari.

Optimising Existing Sites

There essentially three approaches that can be taken when adapting a site for mobile browsers, the first of which is to simply optimise and standardize the existing site.

After all, the foundation of every good web site is a good HTML structure that clearly separates content, style and behavior. A well designed site that follows web standards and best practices will stand a reasonable chance of at least providing an acceptable mobile browsing experience, especially on newer devices such as the iPhone. The focus in this approach should be on the use of graceful degradation and progressive enhancement techniques for CSS and JavaScript, simple navigation and the limitation of purely decorative elements. If you’re on a budget, and don’t need to be a cutting edge iPhone content provider, this might well all that is required.

in the case of services or sites aimed primarily at mobile users, it may be the standard desktop site that is not actually required.

Dedicated Mobile Sites

However, in many cases optimizing and existing site, while a worthwhile exercise it its own right, may simply not cut the mustard. Because, lets face it, the increasing complexity of most sites, means that many web pages simply contain too much information and have too complex layout to be workable on a small screen.

For those on the cutting edge, flush with funds and brimming with enthusiasm,

In such case, developing a separate site dedicated to mobile users will guarantee the best result. It will allow developers and content provider to truly aim both styling and content at the mobile browser. Specific functionality such as location based services (LBS) and the tel: protocol, which can cause a mobile phone to dial a phone number when a link is clicked on, can also be taken advantage of.

To easily identify the mobile version of a site is it possible to register a .mobi domain name. An easier choice however, is to use a subdomain, such as m.SiteName.com or mobile.SiteName.com instead. The Economists mobile web site for example can be found at m.economist.com. Another alternative is to create a sub directory, such as www.SiteName.com/mobile. Direction to the mobile version of the device can be achieved via client side user agent sniffing or server-side capability detection. (see

Obviously, a dedicated mobile site will require maintaining two sites, which does sound like a significant overheard. However, in reality this may be less of an overhead than it first appears. Many web sites these days are based on content stored in a database. And hence, provide it is the content, rather then the interface itself which undergoes frequent updating, a second mobile device interface, once it has been create created, will not require any continued maintenance.

In fact, in such cases, the dedicated mobile site solutions starts looking almost like the third option for implementing a mobile website: One site, different views.

One Site, different Views

Often touted as one of the simplest and most effective method of designing sites for viewing via different devices, is the use of different style sheets.

CSS 2.1 / HTML 4.0 offer a number of methodologies of dealing with different media types including handheld devices. The @media rule allows application of different rules for different media within the same style sheet.

</code>@media screen {
body { font-size: 10pt }
}
@media handheld {
 body { font-size: 13px }
 }

The @import rule allows importing of style rules from other style sheets.

@import url("webtv.css") tv;

The HTML link element allows setting of a media attribute to specify the target media type for the link.

<LINK rel="stylesheet" type="text/css" media="handheld" href="handhled.css" mce_href="tv.css"

CSS 3 will add another method called Media Queries.

As always, universal and consistent browser support can not be guaranteed, and cross-browser testing will be a necessity.

For data driven sites, where the page itself is simply a template for data drawn from a database or other files, I can not see much difference between the development of this method and the previous one.

Nuts and bolts: A practical example

The images bellow shows, as an example, a ScrewTurn driven wiki site that is to be made available to smartphone users. Followed by a mockup of a potential smartphone compatible layout.

ScrewTurn is a .Net wiki engine and does support theming for handheld devices through inclusion of a Handheld_Styles.css within the Themes\Default\ directory. This style sheet would then be used to manipulate the display of the page elements that are defined within the MasterPage.master page. Specifically, the CSS z-index property could be used to stack SidebarDiv and MainDiv.

Clicking on the Content tab within the menu would alter the value of the z-index, effectively re-stacking the layers. Similarly, clicking a topic within the tree menu, would not only load the appropriate content in the MainDiv but also bring the MainDiv to the top.

Obviously, implementing the above solution would require some DHTML coding to implant the automatic changes to the z-index value. However, when running in standard screen mode, the SidebarDiv and MainDiv would not be overlapping, and hence any changes to the z-index value should go unnoticed.

Resources and References

• World Wide Web Consortium (W3C) mobileOK Checker will check a site’s level of mobile-friendliness.
• The World Wide Web Consortium (W3C) Mobile Web Best Practices 1.0 lists 60 points to consider when delivering Web content to mobile devices.
• Chris Pederick’s User Agent Switcher 0.7 allows access to sites (and run style sheets) that are restrict access based on the browser being used.
• The iPhone Simulator allows a site to be viewed inside and iPhone “skin”. Works best when used in conjunction with User Agent Switcher
• Coding for the mobile web, Mar 08.
• A List Apart: Put Your Content in My Pocket, Aug 08.
• Tips to design your site for mobile devices, Jul 08.

And here are a couple of other points I have come across but not had a chance to look into

• Safari Book Store, a subscription-based media-download service, have developed completely new websites and user interfaces for their customers on the go.
• WordPress has a free WordPress plugin to develop mobile sites

Log into GoogleMaps. Then choose My Maps. Either create a new map or choose an existing map. Then choose View in Googl Earth.  Save the KML file.

URL Redirection and domain forwarding allow redirection of web traffic from one site or page to another.

URL Redirection

One of the simplest ways to redirect visitors from one URL to another is to set forwarding at the page level, using the meta refresh tag within the head section of the actual HTML page. However, some search engines will refuse to index a page with a high meta refresh rate, and Google (I think) will not index pages with any redirection whatsoever.

Wikipedia provides a fairly comprehensive list of URL redirection techniques.

Domain Forwarding

While URL redirection works at the page level, domain forwarding works at the sever level.  This means visitors will not experience any additional loading for the website that is being forwarded to. Furthermore, it is possible to use masking or cloaking to prevent the URL of the site you forwarded to from displaying in the browser’s address bar.

There are several different ways in which forwarding can be implemented on the server.

Examples

WordPress, for example, offers free hosting of blogs, using URLs such as UserName.WordPress.com. URL redirection could be used to forward the page www.MySite.com/blog.html to UserName.WordPress.com.

Alternatively, domain forwarding could be used to forward the URL blog.MysSite.com to UserName.WordPress.com. If masking/cloaking is set the, this redirect would be transparent to the user.

Dub, Dub, Dub and other subdomains

Universal Resource Locators (URL) are generally of the format http://www.MySite.com. The MySite.com part of this address is called the domain name, while the www prefix is called the subdomain. It is generally possible to have any number of additional subdomains, such as blog.MySite.com, wiki.MySite.com or mobile.MySite.com, under a domain. In fact internet service provides routinely create a number of standard subdomain, such as ftp.MySite.com and mail.MySite.com names under each hosted domain.

The primary issues to consider relation to implementing any web based survey are:

• Simplicity/Cost: How easily and quick can solution be implemented and what are the associated costs.
• Scalability: Relates to the ability to develop and expand system to meet future demands.
• Connectivity: Relates to the ability, or lack thereof, to complete the survey while off-line.
• Persistence: Ability to retrieve data or store partially completed surveys (i.e. what happens once the users leaves the web page)
• Data Storage/Analysis: Relates to how the data is stored, how easy it is to retrieve and how well it can be analysed.

It is in relation to the above three criteria that I will look at the technologies that could be employed to develop web based compliance audit software.

Simple Web Forms

Simple web based form, that users would fill in and submit back to site. Often users are required to fill in whole form in one sitting.  Some systems address the persistence issue by storing partially completed forms as cookies.  Inexpensive or free tools, such as JotForm, significantly simplify the form creation process.

Simplicity/Cost

Scalability

Connectivity

Persistence

Data Storage/Analysis

Host Web Surveys

More sophisticated than simple forms in that the information entered is generally stored within a database for later analysis. There area a large number of companies, such as Apian, SurveyMonkey and ZapSurvey offering hosted survey design and management software. Prices usually start at around US$20 / month. Not all of these services will necessarily provide the ability for users to log in and re-retrieve their surveys or complete partially completed surveys prior to final submission. SurveyMoney, for example, will store partically completed surveys data as coockies. Depending on browser type and settings, cookies may be restricted or dumped on exciting the browers.

Simplicity/Cost 

Scalability

Connectivity

Persistence

Data Storage/Analysis

PDF Forms

Users download a pdf form and return it via e-mail on completion, either with or without first saving it to their own computer. One advantage is the ability to save the form for later off-line completion. This is one of the simplest ways to implementing sophisticated form, but for some reason it does. The form can be e-mailed on completion (without saving). Printing the form for “in-the-field use” is also simple as pdf is often better at preserving layout then HTML. The pdf form design process, using Adobe LiveCycle Designer is relatively simple and offers incredible design flexibility, including the ability to hyperlink to web pages. Despite the many advantages, there is a reluctance by web designers to use pdf forms. One of the reasons might be that it is more difficult to extract data from a form, although I do believe automated methods do exist.

Simplicity/Cost

Scalability

Connectivity

Persistence

Data Storage/Analysis

Survey Database

Involves development of a custom on-line database store survey and user information and a web interface.  The system could be implemented using any number of technologies, but no matter which one is chose, it will require a considerable amount of development, both in terms of the front and as well as the back-end database.

Simplicity/Cost

Scalability

Connectivity

Persistence

Data Storage/Analysis

One method of simplifying the design process would be the use of XML The diagram bellow depicts the ER diagram for a simple multi user, multi survey database using XML which could be implemented using the ASP.NET WebSurvey control available from the CodePlex website.

The primary advantage of XML is the edibility to more easily store data in a tree format, which traditional databases do not. The drawbacks of XML data is that it is primarily a data interchange format, rather than a storage format, and hence it is difficult to query and navigating large datasets.

There are a few different methods that can be used to create a rubbers stamp affect in Photoshop,  including the use of the spatter filter (Filter -> Brush Stroke -> Spatter), as describe in in the Draw a photoshop rubber stamp effect article on oogletutorials.com,  or the use of the cloud filter (Filter -> Render -> Clouds) with some noise added (Filter -> Noise -> Add Noise),  as describe in the Passport Stamp article on thedesignworld.com.

For the Lavykim Australia stamp example I used the Noisy Cloud Filter method, and was reasonably happy with it. However, rather than creating the text and then wrapping it around a semi circle using the Wrap Text option and then duplicating and rotating the wrapped text, I used the path tool to draw a circle, as described on the Adobe site. This method involves creating cirle path and then positionion the type tool over the circle at the point where the type is to begin. Once all type has been entered the character palette (Ctrl+T) is used to ajust text size and spacing, such that the text wraps around the circle completely. The advantage of this approach is that, it is possible to have different text on both sides of the  semi-circles.

In computing, a literal simply refers to a value. This is in contrast to variables, which are names that can represent different values, and constants, which represent the same value throughout. For example, in the expression x = 3, x is a variable while the number 3 is a literal. Hence, I guess, object literal notation could be described as a way of embedding literals, or values, within an object. In practice this would look something like below

var objName {property: value, property: value}

or

var objName {
  propertyOne: valueOne,
  propertyTwo: valueTwo,
}

It is also possible to include functions within the object, which makes sense as in JavaScript functions are objects:

var objName {
  propertyOne: valueOne,
  propertyTwo: valueTwo,
  fctOne: function () { /* code */ }
}

Accessing the objects properties is achieved using dot notation or brackets

alert (objName.propertyOne)
alert (objName.['propertyOne'])

Of couse it would have been possible to creat an object using the more traditional s JavaScript approach, which proves that the object literal notation is simply a shortcut.

var objName = new Object();
objName.propertyOne = valueOne;
objName.propertyTwo=valueTwo;
objName.fctOne = function () { /* code */ };

References

• Jonathan Snook (September 18, 2006) Objectifying JavaScript. Digital Web Magazine. http://www.digital-web.com/articles/objectifying_javascript/. Accessed 6 June 2009.

But first a disclosure, while I do run Chrome on my computer and do use it occasionally, I still prefer Firefox (ver 3) at this stage. This is mainly due to a couple of factors:

• Availability of a great number of very useful add-ons (my personal favourites are All-in-One Sidebar and Xmarks)
• Better bookmark manger interface and the ability to dock the bookmark manager.
• Slightly more stable performance in Firefox as compared to Chrome (ver.  1)

Of course the stability issues are likely to be, or probably already have been, addressed and the user interface, including bookmark management is likely to be addressed in the future. The porting of many of the useful Firefox add-ons is likely to occur as the uptake of Chrome gathers pace. And we only have to think back to the middle of this decade, when Google made competing search engines, such as Lycos, AltaViast and Yahoo,  irrelevant almost overnight.

But where are we at the moment? Web statistics for April 09 show Firefox and Internet Explorer (IE)  to be almost head to head with Firefox accounting for 47.1% and IE for 42.1%. Chrome accounts for only 4.9%, but this number is slowly rising (it was 3.9% in January).

Google apparently developed Chrome with the expressed aim of creating a browser that was faster then any of the browsers currently on the market, and it certainly is. Running Google’s V8 Benchmark Suite (ver 4) test on my Pentium M 1.6GHz powered Asus laptop with 1.37 GB of RAM (no idea why this is such an odd number) gave the following results (the larger the score the better):

• Interent Explorer 7 – crashed
• Firefox 3 – 83.6
• Chrome 2 – 1,523

So, there is no doubt that Chrome is fast at running JavaScript, faster then the opposition by at least one order of magnitude. Google has achieved this by (obviously) focusing, amongst other things, on the development of a faster JavaScript engine. However, JavaScript is not the only technology in cyberspace and many sites today rely on server-side scripting, together with maybe some AJAX, to provide an interactive interface. Also, as some bloggers have pointed out, all too often it is Flash which is causing slow Browser performance. So what does it all mean?

Many Google applications rely on JavaScript and Google obviously sees JavaScript as an important enabler of  future technologies. As Chrome gathers pace I envisage a greater interest in JavaScript at the expense of other client based technologies such as SilverLight and Flash.

Of course, at the end of the day, everything will depend on the uptake of Chrome, which in my opinion, will depend to a large extent on Firefox’s ability to increase its performance in future releases. However, for the time being, I would recommend investing resource into JavaScript rather then technologies such as SilverLight or Flash.