AIDA in eCommerce – Landing on product pages

AIDA in eCommerce – Landing on product pages: "

AIDA stands for Attention, Interest, Desire and Action. It’s the oldest trick in the sales book, but rarely thought about when it comes to eCommerce. The idea is that a sales person should follow these four steps when pitching a product to the potential buyer. In the world of eCommerce, you don’t have your sales person, so this process is (should) be done by your online store.

Attention

Using search engines, in most cases visitors will land on product or category pages. We will concentrate on your product pages within the AIDA process. Once the visitor lands on your product page, you have merely a few seconds to grab his attention. In these few seconds, this visitor will decide weather this is what he was looking for or he’ll move along. We are talking about attention, the first part of AIDA process. In the real world, you’d be trying to catch the attention of the buyer in this step, but online, you already have his attention. All you need to do is make sure you don’t lose it.

You’ll lose the attention you’ve been given in case your product page is to crowded and doesn’t give the impression of what it’s really about from the first look. Too many distracting items can cause your visitor to think he didn’t find what he was looking for, even though he was on the right product page. You can spot this behavior if you are using Google Analytics. Try finding people that landed on the right product page that perfectly fits the keyword they entered into search engine, but right after they landed they used your internal site search to try to find the product they were looking at. In case there are none of these in your Analytics, your product pages might be built pretty good from the attention retention point of view.

Interest

In the real world, you would try to make the buyer show some interest in your product. Luckily for you, visitors that came from search engines searching for your product already showed the interest, now you need to show them why they should act. You need to make them desire the product.

Desire

The visitor landed on the product page and you managed not to lose his attention. Awesome! In this step, you need to make him desire the product. You can do this in several ways, but what really works well is good product representation – readable, scan-able product description, high quality multiple images from different angles and if possible, video showing the product. If the product can be shown “in action” that would also be a thing that encourages desire.

Look at the product page and information you provide there from the visitor’s perspective. Ask yourself if you could envision this product’s size and feel if you’ve never seen / felt it in the real life. If you can’t, work on the description, images, and video.

Action

Visitor landed, you have his full attention, you made him desire the product. Now it’s time to make him take the one last step, to click the button. I cannot stress enough how important it is to have a clear call to action. Your “Buy now” or “Add to cart” button has to be the most easily found element on your product page. It has to be big, in different color than surrounding elements and on a logical spot. Bring in a person that never saw your website and show him the product page. Tell him to add the item to the cart. If he can do it without reading anything or looking around the site for more than few secunds, thats a good button. If not, you should improve it.

Some elements can distract the visitor from completing the last step of the AIDA process. Those can be different banners, or some other buttons that compete with your “Buy now” or “Add to cart” button’s attention. I know you want multiple things from your visitor and several call to actions are likely to be placed on modern online stores, but always ask your self, is it more important for you that visitor checks some other item on discount on your store, to follow you on Twitter / Facebook, to subscribe to your newsletter or to buy the item he is looking at at this point. All of these other calls to actions can be present on other pages – such as category page, CMS pages, checkout success page – but the product page should be as free of these distractions as possible.

"

Database Export Wizard for ASP.net and SQL Server

Database Export Wizard for ASP.net and SQL Server: "A step wizard for ASP.net to export database objects to CSV, TXT, HTML, XML, or SQL."

Managers vs. Leaders: Can Theory Make a Difference?

Managers vs. Leaders: Can Theory Make a Difference?: "Most of us have heard someone say things like this before, “My boss can only manage from the book.” Management theory should be an important part of the strategic management process. Managers are challenged by employees in many ways almost daily. Manager, Leader, or Both? Think about the ways that managers are challenged almost dail..."

AJAX Using RESTful MVC3 Services and jQuery

AJAX Using RESTful MVC3 Services and jQuery: "REST is an approach to providing a highly efficient API that can be called by other applications or by your AJAX framework. David Talbot shows you how to use MVC3 to define REST services in your controllers to be called by jQuery AJAX requests in your view."

6 CSS Shorthand Tricks Every Developer Should Know

6 CSS Shorthand Tricks Every Developer Should Know: "

Recently, I decided that I needed a refresher in all of the various CSS shorthand properties. The best way to learn something is to teach it so here’s my attempt at exactly that.

Today we’ll learn how to use CSS shorthand for backgrounds, margins & padding, borders, fonts, list-styles and transitions.

Like the article? Be sure to subscribe to our RSS feed and follow us on Twitter to stay up on recent content.

Background

CSS background images are one of the most common places that I see CSS shorthand being implemented. There might be a little more functionality here though than people take advantage of. Let’s start with a typical example of the normal way to declare a background.

Background: The Long Way

background-color: #eee;
background-image: url(background.jpg);
background-repeat: no-repeat;

Background Shorthand

From here, most of us know how to take these three properties and throw them all inside the background property. Check out how much room this saves.

background: #eee url(background.jpg) no-repeat;

Attachment and Position

Two other properties that you don’t see in the shorthand as often are position and attachment. Just as a refresher, let’s look at what these two are.

Background-attachment refers to whether or not the background image will scroll with the page or not. The default value is scroll, which means that you will lose sight of the image as you scroll down the page just as you do with the rest of the content. If you change this to fixed, the background will stay right where it is as the rest of the content scrolls over the top of it.

Background-position refers to where the image is placed within the element. You can use something generic, such as left top, bottom right or center center, or something more specific such as a percentage or pixel value.

Here is the long version with these two thrown in.

background-color: #eee;
background-image: url(background.jpg);
background-repeat: no-repeat;
background-attachment: fixed;
background-position: center top;

Take note of the order here because we’ll use the same order in the shorthand version:

• background-color


• background-image


• background-repeat


• background-attachment


• background-position

Background Shorthand with All Five Values

Here we throw all these in respecting the order that we just outlined. Feel free to leave any of them out to revert to the defaults.

background: #eee url(background.jpg) no-repeat fixed center top;

Margin and Padding

Another place that you’ve no doubt seen some shorthand is in margins and padding. Here this works exactly the same way for both so I’ll just give examples for margin and you can apply it yourself to padding.

Margin: The Long Way

Here we have the normal way to set your margins. I’ve set each at an arbitrary value, the important parts to take note of are the order and the fact that they’re all different. Both of these will affect the shorthand.

margin-top: 10px;
margin-right: 11px;
margin-bottom: 12px;
margin-left: 13px;

Margin Shorthand

Declaring margins in shorthand is a pretty versatile technique that saves a lot of space no matter how you do it. Basically, you just throw all your values right in a row into the margin property.

margin: 10px 11px 12px 13px;

The order here is very important. To remember how this works, just think about a clock. It starts at the top and rotates clockwise, hitting each edge. First is margin-top, then margin-right, margin-bottom and margin-left.

Declaring all of the margin properties to be the same is even easier. If you only input one value, it will apply to every property. The code below will result in a 10px margin on every side.

margin: 10px;

Now, let’s say you really only have two different values you want to work with, meaning the top and bottom margins will have one value and the left and right will have another. By default, when you declare the shorthand top margin, the bottom will match and when you declare the shorthand right margin the left will match.

margin: 10px 20px;

This holds true when you declare three values as well. So the following code will set the top, right and bottom margin manually while the left is automatically grabbed from the right.

margin: 10px 20px; 30px;

Border: The Long Way

Border comes with three primary properties: width, style and color. These are written out individually as follows:

border-width: 2px;
border-style: solid;
border-color: red;

You can fudge the order of these properties a bit when switching to the shorthand version, but it’s best to keep it in this standard order to ensure complete compatibility.

Border Shorthand

Here is the shorthand version of these three border properties.

border: 2px solid red;

Another thing you can do with borders is declare each side of the border differently. Here we can see the shorthand border formatting still at work, just in each individually.

border-top: 2px solid red;
border-right: 4px solid red;
border-bottom: 8px solid red;
border-left: 16px solid red;

Alternatively, you can target one of the three border properties and apply them in a clockwise fashion just like wed did with the margin shorthand. Notice how the second width declaration overrides the first.

The following will give us a solid red border that is 2px on the top, 4px on the right, 8 px on the bottom and 16px on the left.

border: 1px solid red;
border-width: 2px 4px 8px 16px;

Similarly, this will give us a 5px solid border that is blue on the top and bottom and red on the left and right.

border: 5px solid;
border-color: blue red;

Outline Shorthand

I don’t want to spend too much time on the outline property simply because support isn’t great and you probably hardly ever use it. The benefit is that, unlike border, outlines won’t affect your layout. If you do find yourself ever using outline, the syntax is pretty close to that for borders.

The following represents the values for outline-width, outline-style and outline-color in that order.

outline: 1px solid #eee;

Font: The Long Way

There are a bunch of different font properties that you can mess with to change the appearance of your typography. Consequently, your stylesheet can quickly fill up with blocks of styles like the one below.

font-style: italic;
font-variant: small-caps;
font-weight: bold;
font-size: 15px;
line-height: 30px;
font-family: Helvetica, sans-serif;

Font Shorthand

Font shorthand is a really heavy hitter as far as space saved. We can take all of the information above and cram it into one brief and surprisingly easy to read line.

font: italic small-caps bold 15px/30px Helvetica, sans-serif;

Most of the time, what you’ll have is probably much shorter simply because you won’t need all of these styling options. You can ditch the font style, variant and weight and just declare a quick font size, line-height and font-family.

font: 15px/30px Helvetica, sans-serif;

Lists: The Long Way

List shorthand is really interesting because I rarely see anyone mess with these properties anyway. If you are a list master though you might use the three properties of list-style shown below.

list-style-type: circle;
list-style-position: inside;
list-style-image: url(marker.jpg);

List Shorthand

This one is pretty predictable, just toss these three properties into “list-style” and you’re good to go.

list-style: circle inside url(marker.jpg);

CSS3 Transitions: The Long Way

CSS3 transitions are obviously still quite new and therefore support is different across browsers. Here we’ll use transition but you would likely break this out into -webkit-transition, -moz-transition, and -o-transition as well.

Here are the basic properties listed one at a time:

transition-property: width;
transition-duration: 2s;
transition-timing-function: linear;
transition-delay: 2s;

CSS Transition Shorthand

This is one property where you almost always see the shorthand used instead of the long version. If you’ve ever done CSS transitions you’re probably more familiar with the syntax below.

transition: width 2s linear 2s;

And of course, as we mentioned above, since browsers are still not quite uniform on this you have to include those nasty little vendor prefixes. Here’s a typical example of the code you would use for a transition with maximum compatibility (IE is still left out).

transition: width 2s linear 2s;
-moz-transition: width 2s linear 2s;
-webkit-transition: width 2s linear 2s;
-o-transition-transition: width 2s linear 2s;

Conclusion

CSS shorthand is an awesome tool to both save time and space. If you’re familiar with the syntax, you could argue that shorthand is actually more readable than the long version. However, for newbies, it’s much easier to read labeled properties so just keep in mind what your goal and audience is for a given project. If you’re writing a tutorial, you might want to list out individual values or at least explain your shorthand, in production though shorthand works perfectly.

Leave a comment below and let us know which properties you generally use shorthand for and whether or not you learned anything from the examples above.

"

How to Stop Writing Spaghetti Code

How to Stop Writing Spaghetti Code: "This video explores different coding styles for event-driven, non-blocking server-side JavaScript and which styles are most successful."

Robert Bosch Foundation: Seven points to improve research

Robert Bosch Foundation: Seven points to improve research: "In the aftermath of the plagiarism affair that led to the withdrawal of German defense minister zu Guttenberg's doctor title and, eventually, his resignation, the Robert Bosch Foundation invited a panel of experts to formulate ways to improve the conditions under which research is conducted. The outcome is a seven point paper 'to assure integrity and quality in scientific research.' You can download the paper (PDF) here. Since it's in German (and I realized Google translate doesn't cope well with academic-style German), here is a rough translation:

(All awkward grammar is entirely my fault.)

'1. Mitigation of publication flood

The number of publications around the world should be reduced (relative to the growing number of scientists) and thus - against the economic interests of publishers - also the number of journals. This is the only way to ensure that this important basis for assessing the quality of research will again consist of reflected and carefully evaluated results. And only then researchers will be able to again take sufficient note of relevant results and findings from their field.

2. Basic insights need permanent funding

Science needs durable and reliable funding, because the search for something new and for an increased understanding of nature follows radically different laws than a commercial enterprise. Of course academic institutions have to deal responsibly with their funds. We have to vehemently object however the expectation that academic institutions have to make direct financial profit or are evaluated by strongly economically oriented criteria. Rather, we should work together, even more than is already done today, to highlight the high intrinsic value of knowledge gain for the general public.

3. More emphasis on the content of scientific achievements

In the allocation of research funds it should be content that is assessed, not mindless promises of success of practical implementation. The qualitative assessment of the scientific work of a scientist or a researcher should at least equal in importance the quantitative bibliometric performance indicators. The sheer number of publications is not a valid criterion.

4. Proscription of strategic authorship

Authorship of a scientific publication requires substantial contribution to the content of to-be-published work. Authorship has become a currency of science, which is rewarded with money. The system for performance-based allocation of funds should therefore carefully investigate the actual contributions of the authors and proscribe a merely strategic authorship without substantial participation.

5. Researchers must write their own research proposals

External funding is an important competitive component of the academic system. Due to the trend to demand very high shares of external funding, the pressure has increased so much that a professional application system has formed, one in which scientists no longer write the research proposals themselves, but, in extreme cases, agencies formulate standardized applications. But scientific concepts need to be written by the researchers themselves. Ghostwriters must not be tolerated, not even in composite applications where parts written by different scientists are often 'smoothed' by agencies.

6. Transparency in the presentation of data collection

Science needs transparency, despite the increasing complexity. Rapid technological progress, together with an excessive competition leads to more complex, and difficult to verify experiments. Without transparent and accurate representations of data collection and the scientific approach undertaken, more mistakes and improbities occur which jeopardizes the substance of science.

7. Good research takes time

Development and implementation of sound projects are not compatible with short-term contracts. The pressure generated by short-term contracts leads scientists and researchers to carry out small projects with no substantial knowledge gain and to publish fragments. Only contract terms that offer, through sensible conditions, the possibilities to plan long-term projects (esp. for young researchers) allow the quality of research indispensable for international competition.'

This sounds very Germenglish, even to me ;-) Gee, all these many-syllable words and convulated grammatic constructs. I had to look up 'improbity,' and I'm not even sure I know what the German translation 'Unredlichkeit' means (literally it means 'something one doesn't speak of'). In any case, I hope it's roughly understandable. I think these are all very good points. However, I wasn't even aware that ghostwriting of proposals is an issue, I've never heard of this.

Do you have anything to add?

'You do not really understand something unless you can explain it to your grandmother.' ~ Albert Einstein

"

Foundation HTML5 Canvas (Free Copies)

Foundation HTML5 Canvas (Free Copies): "

Advertise here

Rob Hawkes, author of our popular Canvas from Scratch session recently released his fantastic new book, Foundation HTML5 Canvas. This book is unique in that it introduces the HTML5 canvas element from more of a gaming angle. Even better, we’ve got some free copies to give out!

Learn how to become a true master of HTML5 canvas in my new book. In it, I teach you how to use all the major features of canvas, including how to animate with physics and how to create two awesome space games.
– Rob Hawkes

Get the Book on Amazon

---

Free Copies

I’m pleased to announce that Rob and Apress have agreed to offer a few free copies to some of our lucky readers! To enter, simply leave a comment below, and write either an HTML5 or Canvas tip. Tweet length (a sentence or two) should do just fine. Next week, we’ll contact a few of you with instructions for downloading your free book!

Page from Foundation HTML5 Canvas

---

Thanks again to Rob for writing this book. Be sure to pick up a copy if it could be of use to you!

Rob Hawkes, author of our popular Canvas from Scratch session recently released his fantastic new book, Foundation HTML5 Canvas. This book is unique in that it introduces the HTML5 canvas element from more of a gaming angle. Even better, we’ve got some free copies to give out!

Learn how to become a true master of HTML5 canvas in my new book. In it, I teach you how to use all the major features of canvas, including how to animate with physics and how to create two awesome space games.
– Rob Hawkes

Get the Book on Amazon

---

Free Copies

I’m pleased to announce that Rob and Apress have agreed to offer a few free copies to some of our lucky readers! To enter, simply leave a comment below, and write either an HTML5 or Canvas tip. Tweet length (a sentence or two) should do just fine. Next week, we’ll contact a few of you with instructions for downloading your free book!

Page from Foundation HTML5 Canvas

---

Thanks again to Rob for writing this book. Be sure to pick up a copy if it could be of use to you!

"

A client side Glimpse into whats going on in your serve

http://getglimpse.com/
http://www.blogger.com/img/blank.gif

Front-End Development Best Practice

Front-End Development Best Practice: "

Table of contents

1. Browsers
   
2. HTML
   
3. CSS
   
4. Javascript
   
5. Frameworks
   
6. Performance
   
7. HTML5 / CSS3
   
8. Accessibility
   

Foreword

This little book is to aid a shared understanding of front-end development best practice at PUP.

It's to help us deliver high quality content that works better, reaches more people - not only in today's browsers & devices, but in tomorrows.

Browsers

Statistics, naturally

Our own user logs are almost all that matters in deciding which browsers we officially support.

However, if we give our clients good reason to upgrade or switch to a newer, more standards compliant browser our jobs will be easier and our work higher quality as we won't need to be spending time fixing bugs in older browsers.

Do web sites need to look the same in every browser?

No. A page needs to serve its purpose in function and not appear broken.

It's not about browsers, it's about serving the users of our software by delivering content that that is valuable to them.

We currently support

The latest versions of all modern browsers, IE6-9 & top-level modern mobile browsers Opera & Safari.

• IE6-9
  
• Firefox
  
• Chrome
  
• Safari
  
• Opera
  

---

• Opera Mobile & Opera Mini
  
• Mobile Safari
  

Install the latest versions of these browsers from U:/

IE6-8 are currently best tested on VM's pageuptest-ie[6,7,8] or run your own VM's.

You can test Opera Mobile from your desktop machine - You can also introspect Opera mobile inside a phone using Opera Dragonfly.

The iPhone SDK comes with Mobile Safari but is mac only, there's plenty of iPhones and iPads around the office. Make sure error reporting is enabled in Safari settings.

If you write front-end code you will need to test in all of these browsers to ensure it looks ok and functions as it should.

• Scale the window down and see what happens at different screen resolutions and with different amounts of content.
  
• Javascript will throw errors if something is wrong, most of the time.
  

Mobile

Mobile is hugely important today, we will need to review our mobile support regularly and follow the industry and our user-base. It will soon be more important than the desktop.

Writing front-end code without considering mobile doesn't cut the mustard, it cuts the cheese.

Simple things we can do

• Optimise styles for small screens with @media queries & viewport meta
  
• Add touch support - 44px x 44px minimum tap size
  
• Don't rely on :hover, or mouseover events to get to content
  
• Keep popups stand-alone - they cannot send data to the parent(e.g. binoculars)
  
• Avoid scrolling content areas - It can be achieved in Mobile Safari using touch events and CSS transitions but it's not easy
  
• Keep bandwidth to a minimum
  

@ppk writes about mobile at http://www.quirksmode.org/mobile/

Web standards

To 'Write once, deploy everywhere' was the great goal of the web standards movement.
Thanks to the efforts of web designers & browser vendors supporting web standards, browser compatibility is far easier today than it ever has been.

The W3C and WHATWG are groups that debate 'What the web should be', argue over APIs and publish standards for browser vendors and developers to implement.
These are open groups, anyone interested enough in them can contribute.

• http://www.w3.org/TR/
  
• http://www.whatwg.org/specs/
  

Follow

Following changes to the specs and listening to developers& designers is important. Follow changes at
@w3c
@whatwg

People to follow
@paul_irish
@brucel
@nimbuin
@keithclarkcouk
@thecssninja
@leaverou

Read from great authors
Dan Cederholm
Andy Clarke
Jeremy Keith

Join a forum
SitePoint

Rendering engines

The rendering engine in a browser reads HTML, CSS, other standards like XSLT, SVG, and paints the pixels on the screen.

The four biggies

Trident

IE

Gecko

Firefox

Webkit

Chrome, Safari, Apple & Android mobile devices.

Presto

Opera, Opera mini

Understanding the differences and quirks in these 4 rendering engines will reduce the amount of time needed to test layout & rendering.

HTML

HTML is the unifying language of the World Wide Web. Using just the simple tags it contains, the human race has created an astoundingly diverse network of hyperlinked documents, from Amazon, eBay, and Wikipedia, to personal blogs and websites dedicated to cats that look like Hitler.

- @adactio

Semantics

HTML gives meaning to content so that browsers and devices can then give that meaning to a user. e.g.

• Headings h1 to h5 form a document outline and can give a table of contents for easy navigation.
  
• A screen reader gets to a <table> and explains to a blind user how to navigate its content by rows/columns.
  
• When a user clicks on a <label for="email"> the associated input control gains focus <input id="email">
  

If it's a heading use a heading.

If it's tabular data use a table.

If it's a list of links then make it so.

Lonely HTML

HTML should work without the presence of CSS or Javascript.
The content should be accessible, form submissions should work, the HTML on it's own should have value.

A good way to test the quality of the HTML is to disable images, CSS and Javascript and see how meaningful it is.

If we write our HTML like this when we get around to redesigning the UI, the HTML doesn't have to be rewritten.

Which version?

HTML5 is the version we use, but HTML versions don't really matter.
Browsers understand the tags they support, regardless of the doctype / version we validate against.

A doctype is necessary to force browsers to render in standards mode and prevent quirks mode head aches in ie.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset='utf-8'>
  <title>I ♥ HTML</title>
  <link rel='stylesheet' href='style.css'>
</head>
<body>

<h1>HTML5 <abbr title='For The Win'>FTW</abbr>!</h1>

<script src='script.js'></script>
</body>
</html>

* Lower case tags, double quote attributes.

Best practices:

• Use as few 'nothing elements'(span / div) and styling hooks(class / id attributes) as possible. The leaner the HTML is, the easier it is to work with.
  
• Feel free to use HTML5 tags / attributes but keep backwards compatibility in mind.
  
• Use uft8 character encoding.
  
• Avoid inline styles or event handlers
  

CSS

Be stylish

• Keep CSS completely separate from the HTML
  
• Re-use specific modules e.g. reset, grid, forms, type, print
  
• use shorthand syntax wherever possible
  
• use lower-case-hyphenated .class-names and #ids
  
• code to a standards compliant browser first, then fix issues in IE
  

Internet Explorer WTF?

We really should be thankful that non-ie browsers have such great consistency, I have never needed a CSS hack for a non-ie browser.

Without IE, web development would just be too easy.

Prevent IE from switching to unhelpful modes:

<meta http-equiv='X-UA-Compatible' content='IE=edge,chrome=1'>

When testing your work in IE start with the latest version and work your way back.

IE conditional comments

<!--[if lt IE 7 ]> <html class="ie6"> <![endif]-->
<!--[if IE 7 ]>    <html class="ie7"> <![endif]-->
<!--[if IE 8 ]>    <html class="ie8"> <![endif]-->
<!--[if (gte IE 9)|!(IE)]><!--> <html> <!--<![endif]-->

If we replace our html tag with the above we can use classes to deliver styles to specific versions.

e.g. 'float to fix' a bug with #myElement in ie6

.ie6 #myElement { float: left; width: 100% }

What is hasLayout?

The single most important thing you need to know about fixing bugs in IE!
Giving an element 'Layout' will fix 99% of ie rendering bugs, as if by magic. The other 1% will most likely be related to position: relative; or floats. Use 'zoom: 1' as a trigger for whatever ie versions need it.

.ie6 #myElement, .ie7 #myElement { zoom: 1 }

http://www.sitepoint.com/forums/2041209-post24.html

Media queries

Deliver specific styles to different devices, they can test for things like:

• screen or print
  
• width and height
  
• orientation – is mobile device in landscape or portrait mode?
  
• resolution
  

You can optimise styes for different devices

@media only screen and (max-device-width: 480px) {
  /* hide header and footer on small screen devices */
  #header, #footer { display: none }
}
@media only screen and (max-width:800px) {
  /* linearize navigation under 800px */
  nav, nav li, nav a { float: none; width: 100% }
}

See http://colly.com/ for a great example

The viewport meta tag is also needed to instruct a mobile device to keep the viewport to the amount of pixels it has on the screen i.e. prevent it from zooming out like a desktop version.

<meta name='viewport' content='width=device-width'>

Great article on viewport and media queries http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/

Best practices:

• Use meaningful class names and IDs - e.g. 'loading' as opposed to 'bigYellowSpinnyThing'
  
• Control the margin and padding on all the elements you use.
  
• Avoid absolute positioning
  
• Avoid !important
  
• Don't suffer from divitus and classitus
  
• Don't use breaks <br> just to make space in your layout
  
• Avoid hacks unless there is no other way to achieve what you want
  

Javascript

Hold on there Bald Eagle. Why are we always in such a hurry?

- @malarkey

Moving parts

Javascript sits on top of the HTML and CSS foundation and enhances the user experience & behaviour of the page, that's it.

What is javascript good for?

• User interaction
  
• User experience - e.g. Responsiveness
  
• Dynamic behaviour
  
• Animation
  
• Make pages easier to use
  
• Aid accessibility - e.g. add keyboard support.
  
• Shims - Adding support to browsers for features they don't natively support
  

Progressive enhancement

Is an important concept, it means making a page work without a feature that may / may not be supported first.
If a feature is supported the user gets the benefit, if not - it still works.

If we treat javascript like this it makes our code higher quality and prevents atrocities like:

<a href='javascript:myKillerFunction('sucks', true);'>Click here</a>

It means that if something breaks the page can continue to work without the enhancement.
Progressive enhancement also aids maintainability, keeping the javascript separate means there's no need to search all documents for function calls.

Clean API's

Because we are not cluttering the global scope we can have short awesome names for our methods& variables.

var Toggler = {
  open: function() {},
  close: function() {},
  toggle: function() {}
} 

Optional arguments

Add only the absolutely necessary parameters as arguments, put all optional parameters into an options hash.

function circle(x,y,radius,options) {
  options = options || {};
}

Controls framework

Controls are initialised via a container element with class=”init” e.g. If you're initialising stuff onload use this.

<input class='init control-awesome-toggler'>

On load this would pick up the above element and try to create a new instance of the AwesomeToggler Control below:

Controls.AwesomeToggler = Class.create(Controls.Base, {
  initialize: function ($super, container) {
    $super(container);
    container.observe('click', eventFn.bind(this));
  },
  eventFn: function(e) {}
});

Best practices:

• Favour the framework & DRY
  
• Avoid inline & embedded js
  
• Keep global scope clean, put code into namespaces Page, Util, Controls
  
• Be defensive, feature detect
  
• Test performance in all browsers mentioned above - use console.time to track down bottlenecks.
  
• Minimise number of event listeners on a page, use event delegation
  
• Keep components as independent as possible
  
• var every variable
  

Frameworks

If you want to use a library you must have read it, understood it, agree with it, and not be able to write a better one on your best day of coding.

- @sentience

Frameworks are not evil, they save time, fix cross browser compatibility issues and make us think in new ways.
But, they do add overhead so before we jump in bed with them, see above.

Javascript

We should only have one 'Core' javascript framework, additional libraries for specific tasks not handled by the Core framework can be added if they meet the above requirements.

e.g. Effects & animation, SVG, Charting, Shims(Add support for features that aren't natively supported by some browsers)

Read, Collaborate & Contribute to open source

Open source frameworks are the product of really interested people. Interested people create great stuff.

Schools out, but keep learning
jquery
mootools
prototype
scriptaculous
raphaël

Gain heroes
Paul Irish,
Thomas Fuchs,
John Resig,
Dmitry Baranovskiy

Roll your own

Create something great and share it with me.

Performance

YUI best practice

The YUI team has done as much research into front-end performance as anyone.

Here's a cut down version of the YUI best practices for performance, reading the full article is highly recommended though. http://developer.yahoo.com/performance/rules.html

Follow @souders if you're interested in web performance.

Minimize HTTP Requests

Combine all scripts and stylesheets & use image sprites to reduce the number of round trips to the server.

Use a Content Delivery Network

We should move all referenced files css, js, images etc. to dispersed servers like Akamai.

Put Stylesheets at the Top

Putting stylesheets in the <head> allows the page to render progressively.

Put Scripts at the Bottom

<script> tags block parallel downloads, put them last so other resources can be downloaded first.

Avoid Expressions

Expressions are a way of running javascript as part of a CSS rule in ie6-7. They can be used to fix support for non-supported features - like fixed positioning. The problem is they are constantly evaluated which can really slow down the page.

.ie6 .fixed {
  top: expression(0+((e=document.documentElement.scrollTop)?e:document.body.scrollTop)+'px');
}

Make JavaScript and CSS External

The Cache is our friend. The only exception would be pages with one view per session which may benefit from inline script.

Minify JavaScript and CSS

We should use a minifier like JSMin, YUI Compressor or Closure Compiler to reduce the file size our CSS & js.

Removing variables from the global scope can get better results from compression as the names can be shortened as they can't be accessed outside of their enclosing functions.

var canIBeShortened = 'no';
(function() {
 var willMyReallyLongVariableBeShortnedByTheMinifier = 'yes';
 alert(willMyReallyLongVariableBeShortnedByTheMinifier);
})();

// Minified
var canIBeShortened='no'function(){alert('yes')})()

Avoid Redirects

Slows down the user experience.

Reduce the Number of DOM Elements

Smaller pages with fewer elements are faster to traverse and modify.

Minimize the Number of iframes

Costly even if blank because they are new windows, they also block the page's onload event.

No 404s

Look through monitoring and remove these unnecessary trips to the server.

Reduce Cookie Size

Transferred in the page headers, remove unnecessary cookies, keep small, set an Expires date.

Minimize DOM Access

Save references to elements in variables to prevent lookups, innerHTML is generally faster than DOM, avoid fixing layout with js.

Develop Smart Event Handlers

Minimise the amount of event listeners in a page with Event Delegation.

Prototype's 'on' function registers an event listener on the body element once to handle all the occurrences of that event in the page. e.g.

<body>
  <p>
    <a href='#'>
      <span>linky</span>
    </a>
    <a href='#'>
      <span>linky 2</span>
    </a>

When a <span> element is clicked the event moves up through the tree, all the way to the body where the event handler can find which <span> element fired it.

If you have 100 elements in the page you want respond to click events, Event delegation will save you.

Learn http://icant.co.uk/sandbox/eventdelegation/

Avoid IE Filters in CSS

Filters are 'special features' in CSS for IE, they can slow down the page though, so use sparingly.

Optimize Images

Batch operations like the YUI image compressor, ImageOptim or sprite generators should be used to make the images as small as possible whilst keeping their quality.

Keep Components under 25K

The iPhone won't cache anything bigger than 25K uncompressed.

HTML5 / CSS3

Shiny new toys

Go to town, but keep backwards compatibility and progressive enhancement in mind. Making pages look identical is not the aim, just don't rely on an HTML5 / CSS3 feature for an important feature of a page.

CSS3 can be used, however with the majority of our users on ie6 still we should treat CSS3 features as visual rewards for capable browsers and things which save us lots of time, like gradients and border-radius. Use all vendor prefixes in alphabetical order with the prefixless version last.

#slides img:hover {
  -moz-transform: scale(1.6);
  -ms-transform: scale(1.6);
  -o-transform: scale(1.6);
  -webkit-transform: scale(1.6);
  transform: scale(1.6);
}

HTML5 can be used, consider using shims to add support for more of our users and test the performance impact.

Learn http://diveintohtml5.org/ http://html5doctor.com/

Maintain a support chart

Maintaining your own pages with test cases of standards being developed is the best way to keep up to date. It helps you to really learn how to use them, if you don't practice you quickly forget what you learnt.

Best practices:

• Feature detect
  
• Treat CSS3 as visual rewards for capable browsers
  
• Use shims for HTML5 features if they perform well enough
  

Accessibility

People

Accessibility matters, it matters to those trying to use our software with a disability, it's in our contracts, it also directly relates to discrimination laws we need to know about, as well as simply being the right thing to do.

Writing semantic HTML, CSS that's flexible with layout & font-size as well as using Javascript to add keyboard support go a long way in making a web app as accessible as possible.

It's not always difficult to make something accessible. Always ask what you can do to improve a pages accessibility.

Visual impairments

Supporting blind users of screen reading software like JAWS / NVDA is the obvious case but there are others. Use a sensibly sized default font and provide alt stylesheets for different font sizes. Use enough contrast between colours and foreground / background to enhance readability.

Use a screen reader, it's the only way to gain a good insight into what using our software is really like for blind users.

Accessible tables & forms

Keep tables simple and avoid nested headings. Using th elements for heading cells with appropriate scope is the first step for accessible tables.

<table>
  <tr>
    <th scope='col'>Name</th>
    <th scope='col'>Age</th>
    <th scope='col'>Birthday</th>
  </tr>
  <tr>
    <th scope='row'>Jackie</th>
    <td>5</td>
    <td>April 5</td>
  </tr>
  <tr>
    <th scope='row'>Beth</th>
    <td>8</td>
    <td>January 14</td>
  </tr>
</table>

Linking labels to inputs with the for attribute is the first step for accessible forms.

<label for='email'>Email</label>
<input id='email'>

Learn
http://www.456bereastreet.com/archive/200410/bring_on_the_tables/

http://www.webstandards.org/learn/tutorials/accessible-forms/

Motor impairments

Most of us can appreciate using keyboard short cuts for navigating forms, people with low mobility will appreciate being able to use our software without a mouse far more than this.

UI consistency

This one is not as obvious as the other points, but is as valid. A consistent UI will help all our users be able to access what they need to. It's rare to find a web application of our size and complexity that doesn't have a style guide, let's make one.

WCAG & WAI ARIA

We have focused on WCAG 1 Level A compliance in the past, WAI ARIA is a fairly recent addition and focuses on the moving parts of a web app. The ARIA attributes can help explain dynamic changes to the page with javascript to users of assistive technologies.

http://dev.opera.com/articles/view/introduction-to-wai-aria/

Best practices:

• Test in JAWS or NVDA (on U:) - Add alt attributes, accessible forms & tables
  
• Consider Ajax & screen readers - How do you alert users to changed content?
  
• Add keyboard alternatives to all mouse events - mouseover -> focus, mouseout -> blur - Test without a mouse
  
• Assistive features - High contrast stylesheet, font-size stylesheets, access keys, skip links
  
• Avoid colour alone for critical information - e.g. Red = bad, Green = good
  
• Help everyone - Usable in different screen sizes, consistent navigation and user experience, friendly URLs, favicon etc.
  

People to follow
@jkiss
@stevefaulkner
@vick08

Go forth and multiply

Let's build something awesome and be home for dinner.

Comments"

How HTML5 will kill the native app

How HTML5 will kill the native app: "

Over the past two decades, the mobile industry has become increasingly stunted by fragmented protocols, standards, and regional differences. But a hot new technology called HTML5 promises to remedy this by delivering an unprecedented open, democratic and wonderfully fertile mobile web.

Evangelists say the HTML5 movement has so much momentum that it could defeat the native app — an application that is designed to run on a single platform — in as little as two years.

Sundar Pichai, who leads Google’s HTML5-happy Chrome OS initiative,  agrees that the “incredible advantages of the Web will prevail” over the dominant native app model. Another mobile developer expert Mike Rowehl adds: “We’ll forget that we even passed through another era of native apps on the way to the mobile web.”

The transition comes at a time when the mobile revolution is driving economic growth in the US and abroad. Phones are quickly become our second brain, and users are snapping the smartest phones they can find. Companies, large and small, are investing billions of dollars to create a smartphone presence.

HTML5 heralds huge efficiencies for web publishers, because it lets companies develop once and distribute across any device via an Internet browser. An HTML5 triumph will not only save billions in development costs, but it will also allow publishers to direct those savings towards more innovative, productive projects.

HTML5 apps are searchable by crawlers such as Google’s search engine, ensuring that the apps can be discovered by billions of consumers. They can mash content with data or apps from third parties, and access analytical services such as traffic measurement tools, and ad server targeting technologies. You don’t need to get anyone’s permission to distribute an HTLM5 app. And to top it off, at least one study says consumers prefer the convenience of them (though the research was commissioned by Adobe, which is partial to web apps).

HTML5 is so-called because it is the fifth generation of HyperText Markup Language, which is the coding language used to create web pages. By distributing over a web browser via fast, new mobile networks, HTML5 gets to bypass much of a phone’s underlying “iron,” or the chips, graphical cards and other components — all things that native apps rely on. Most phones being sold today have modern browsers that will operate on super fast 4g or LTE networks — the sort of thing that the HTML5 technology needs to thrive. Thus, as HTML5 advances (developers are working hard to improve it), companies will no longer need to build native apps.

So there’s tremendous logic behind HTML5’s onslaught. Opponents, of course, say it’s not an assured victory. HTML5 has some limitations on things like speed, and access to certain phone features such as bluetooth. What happens over the next 12 months, however, will say a lot about its chances. Its destiny primarily depends on the next steps by Apple, the biggest proponent of native apps, and thus the antagonist of this story. And  precisely because no one knows how this will play out that makes this drama so riveting: Apple is like the Joker in the Dark Knight, a fiend with flair and with a knack for eternal comebacks, while Batman (Google) works to keep the mobile metropolis safe.

(This debate about the emergence of HTML5, and its promise of a future beyond fragmented native app platforms is the focus of one of the sessions at the VentureBeat Mobile Summit April 25/26, a conference for the 180 executives active in transforming the mobile industry. Folks like Google’s Pichai, will be in attendance, as will the major carriers and CEOs of the most disruptive private companies.)

The story started in 2007, with the release of the first iPhone. Led by its enigmatic leader Steve Jobs, Apple gave developers their first real taste of independence from the carrier oligarchy. The iPhone’s beauty was manifold, but first and foremost, it allowed developers to build applications and sell them for a fee — to users who could conveniently tap their iTunes account to buy things through the iPhone’s App Store. This bypassed the control of the carriers, which had long dictated what phones featured on their “decks.”

By the time the dust began to settle, Apple had stolen a two-year lead. Not only that, millions of developers have invested in learning Objective-C, Apple’s programming framework for the iPhone, and other developer tools; these developers become specialists with vested interest to stay loyal to Apple. Now, well into 2011, Apple keeps pushing efforts to make native apps more attractive than HTLM5 web ones, in an effort to keep those millions of developers — and thus users — hostage.

And so paradoxically, Apple has turned out to be controlling, closed and manipulative. It has no incentive to push to full democracy on the web front. It is enjoys huge profits from its position, not only because it gets a 30 percent cut of the revenue from downloaded apps, but because its phones, and now iPads, are selling like crazy. It is now one of the most valuable companies in the world. At every turn, it seems, Apple finds a way to hamper or limit the features that allow HTML5 to work efficiently on its devices. It remains to be seen what tricks it has up its sleeve going forward, but it’s true that many people think Apple will be be able to stay ahead. There are so many areas where Apple and other companies have hived off their own platforms from the Web that Wired last year declared that the “Web is dead.”

But if you look closely, despite the Apple/Joker’s continued pranks to keep native app alive, you’ll see how much Google/Batman keeps closing the gap on him. The following are the areas where native app gained a quick advantage over HTML5. Note that in almost all areas HTMl5 has caught up. In several areas, HTML is about to catch up. In a few areas, HTML5 has a plan to catch up, but is admittedly at least a year or two away from doing so:

• Touch/gestural interfaces — Gestural technology has been implemented by HTML5 framework vendors, such as Sencha. UI components that are controlled by  touch and swipe, such as carousels, scrolling lists, disclosure panels and related widgets are all supported on the HTML5 web. Vendors like Sencha are also helping get rid of things like back buttons, refresh buttons, passed links, bookmarks and other “anachronistic” features of the desktop web that don’t translate well onto the mobile web. Thus coding time has been cut down too.


• Visual Scale — There’s nothing here that HTML5 can’t address. The web page now has sufficient ways to ask what size screen its on, and size images and resolutions accordingly.


• Video/Audio — Now addressed by HTML5 for sustained playback. Audio synchronization for short sound effects still needs work in the browsers.


• Graphics & FX — Native apps are faster for some operations – particularly anything very graphics-intensive. Graphic-intensive games won’t render as effectively in HTML5 anytime soon. However, increasingly, vendors like Sencha are working around many of the speed issues by doing things like embedding a map component that can be primed for loading maps — addressing the slowness you’ve seen in things like Google maps or other sites.


• Camera/Video access — HTLM5 can handle photo capture from a web page on Android devices (at least on the latest versions, run by the Honeycomb OS; but it can’t handle it on iPhones yet).


• Contacts access — Here, HTLM5 addresses file access, but most apps are beginning to draw from the cloud anyway, and not from the device client.


• Accelerometer access – HTML5 can handle this.


• Bluetooth access — This is one device access feature HTML5 has not addressed yet. That said, even for native apps, bluetooth access is fairly limited


• Disconnected Operation — Web apps through HTML5 can now work in disconnected mode; you can get up to 50MB of database space if you ask user permission, in order to keep operating without an internet connection.


• App Store Services (discovery, updates, payments & trust) — Not only can HTML5 apps be sold through HTML5 or Chrome app stores, they can be sold directly through Apple’s App Store, Android Marketplace or Blackberry App World, after being placed in a simple “native” app shell such as Nimblekit or Webworks.


• Running in the background and sending notifications – There are HTLM5 specs for these capabilities, but they haven’t been implemented in the leading browsers yet. When placed in a native wrapper, HTLM5 can do this, but it still means it can’t do this without extra help.


• Business model – Ad revenue works well on HTML5, since the mobile web already has ad networks.  But ads aren’t doing as well on mobile as many expected, so other monetization methods are necessary, such as payment technologies for subscriptions or virtual goods. For HTLM5, there are PayPal and Google APIs, but the experience isn’t very good. Lately, however, companies like Zong and Boku are making payments dead simple for the mobile web.

To conclude, native apps are still extremely popular for many developers, because HTLM5 is still working to close the performance gap. Take Trulia, the company that offers real estate information online. It’s not a game company, and so theoretically doesn’t need the blazing speed offered by a phone’s underlying chip iron. Still, mobile is a significant portion of the company’s traffic (20 percent and growing) and it’s map-heavy– and HTLM5 can’t handle the intensity of map graphics as well as native can.

Chief executive Pete Flint told me he hired ten developers to make native apps, and those apps have shown far superior engagement and page views, he says. “As a brand publisher, I’m loathe to create native apps,” he told me, “it just adds massive overhead.” Indeed, those developers need to learn specific skills to building native mobile apps, arguably having nothing to do with his core business. They have to learn the different programming code, simulators and tech capabilities of each platform, and of each version of the platform. By diverting so much money into this, he’s having to forgo investment in other core innovation. (do the back-of-the-envelope math: at least $100,000 per developer, or a total $1 million investment). In an ideal world, Flint says, he’d have embraced the evolution to HTLM5 Web apps — but HTML5 is just not there yet.

But HTLM5 will emerge competitive on just about every level within two years, says Michael Mullany, chief executive of Sencha, adding that already 95 percent of the functionality of native apps is being delivered by HTML5. And if you have any doubts about this, he points to the story already played out on the PC web. For at least 15 years, developers have been able to create “better apps” on the Windows PC desktop, compared to what they can do on a web browser. “But when was the last killer Windows native app developed?,” Mullany asks. It was probably Microsoft Outlook, which came out in 1998, he says. “Native has always had a performance advantage on the desktop,” he says, “but it hasn’t mattered because of the other benefits of being on the web.”

HTLM5 graphics performance for fast-moving games that have a lot of animation can’t match native’s performance, and probably won’t for some time to come. But for pretty much anything else, HTLM5 is good enough, an increasing number of developers are saying (see this great review by Redfin’s Sasha Aickin). The benefits gained from a slightly faster native experience will be so marginal for the vast majority of apps that it just wont’t matter enough to forgo the considerable benefits of the open web.

Things are moving very quickly. In just the past month or so, HTLM5 has shown momentum in other areas: The main browsers, from Chrome to Firefox to Explorer have bolstered their support of the web framework. Facebook, one of the fastest growing companies, and most popular companies in mobile, has largely embraced HTML5, but is expected to say more soon at its f8 conference. Enterprise players are realizing its advantages, too. Slow to embrace the smartphone native app, they’re now balking at the cost of developing those apps, especially now that Microsoft-Nokia is offering yet another compelling alternative to iOS, Android (we’ll talk another time about how Google is like Two-Face, sometimes), Palm’s WebOS and RIM — why even deal with the splintered distribution each each app would have? After all, many companies have already spent decades developing web apps for the PC, and so they don’t want to start over with native mobile apps. So some enterprise companies are embracing HTLM5 apps instead. Sencha says it saw its business double last year, largely because of this trend. Finally, publishers are getting pissed off at Apple’s insistence to retain 30 percent of the revenue from apps sold through it’s store.

This story is still in suspense stage: We just don’t know when it will end, but we do know it will end. The logic behind HTLM5 is just too compelling for native to win, but at the same time we just don’t now how many more tricks the Joker has up his sleeves to stave off this inevitable tidal shift to an open, democratic metropolis.

Tags: HTML5, native apps

Companies: Apple, Google, Sencha

People: Sundar Pichai

"

Making Web Apps Sizzle with Bing Maps and HTML5’s Geolocation API

Making Web Apps Sizzle with Bing Maps and HTML5’s Geolocation API: "

A few weeks ago, I wrote about Silverlight for Windows Phone’s location API, which allows applications to ascertain their location – latitude, longitude, altitude (if GPS is available), and so on. More recently, I’ve been writing samples around HTML5’s geolocation API. The two APIs are remarkably similar save for HTML5’s lack of support for setting movement thresholds. Both allow you to write location-aware apps with remarkably little code, and both can be combined with Bing Maps to produce stunning UIs pinpointing a user’s location, providing turn-by-turn directions, and more. In fact, once you learn one of the location APIs, you’ll feel right at home with the other. They’re that much alike.

To demonstrate how to combine HTML5 geolocation with Bing Maps, I wrote a sample that I call MapLocation.html. Here it is in IE9, with a pushpin directly over my house:

Here’s the source code for the page, minus the Bing Maps API key that you must register for before using Bing Maps controls and services:

 

<!DOCTYPE html>

<html>

<head>

<style type="text/css">

body {

    margin: 0;

    height: 100%;

    background-color: #404040;

}

#map {

     position: absolute;

    top: 50%;

    left: 50%;

    width: 800px;

    height: 600px;

    margin-left: -400px;

    margin-top: -300px;

}

</style>

 

<script charset="UTF-8" type="text/javascript"

  src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0">

</script>

 

<script type="text/javascript" src="jquery.js"></script>

 

<script type="text/javascript">

    var _map;

 

    $(document).ready(function () {

        // Create a Bing map

        _map = new Microsoft.Maps.Map(document.getElementById("map"),

            { credentials: "Insert Bing Maps API key here" });

 

        // Get the current position from the browser

        if (!navigator.geolocation)

            alert("This browser doesn't support geolocation");

        else

            navigator.geolocation.getCurrentPosition(onPositionReady, onError);

    });

 

    function onPositionReady(position) {

        // Apply the position to the map

        var location = new Microsoft.Maps.Location(position.coords.latitude,

            position.coords.longitude);

        _map.setView({ zoom: 18, center: location });

 

        // Add a pushpin to the map representing the current location

        var pin = new Microsoft.Maps.Pushpin(location);

        _map.entities.push(pin);

    }

 

    function onError(err) {

        switch (err.code) {

            case 0:

                alert("Unknown error");

                break;

            case 1:

                alert("The user said no!");

                break;

            case 2:

                alert("Location data unavailable");

                break;

            case 3:

                alert("Location request timed out");

                break;

        }

    }

</script>

</head>

<body>

 

<div id="map" />

 

</body>

</html>

 

So how does it work? First, I point a <script> element to http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0, which is home for the new Bing Maps AJAX control, version 7.0. Then I instantiate a Microsoft.Maps.Map object (the map) and insert it into the DIV named “map.” Next, I call HTML5’s navigator.geolocation.getCurrentPosition to get the latitude and longitude of my current location. When that call completes, I call setView on the map control, passing in the latitude and longitude provided by getCurrentPosition. For good measure, I create a pushpin at the same location so my current location is called out on the map. Not a lot of code, but a WHOLE lot of results!

Here’s what I found most surprising about this exercise. Testing it on my desktop PC, I wasn’t sure if the geolocation API would work. Even if it did work, I expected the accuracy to be low since the location data would have to come from Wi-fi positioning. In most browsers, the accuracy is good to within a few hundred feet. In IE9, it’s so accurate, it pinpointed the location of the router in my house! Most browsers, I believe, use a positioning service provided by Google to convert IP addresses into locations. (I know that’s true of Opera, because the first time an app running in Opera requests a location, Opera pops up a dialog and asks you to agree to Google terms and conditions.) IE9 evidently uses something different, which isn’t surprising given that Microsoft probably wouldn’t care to make their flagship browser dependent on anything Google provided. Whatever Microsoft is using, it’s amazingly accurate. Of course, your mileage may vary.

It’s pretty cool to know that with HTML5, you can write browser-based apps that, for example, use your current location to show nearby restaurants, movie theatres, and stores. But what’s even more alluring is the thought of building mobile apps that work across a range of devices. If I use Silverlight for Windows Phone to write a location-aware app, it only works on Windows phones. But if I use HTML5, it should work on iPhones, iPads, and even on Android devices. Once Windows Phone 7 acquires an HTML5 browser, it’ll work there, too.

Even HTML5 doesn’t insulate you from all the annoying differences between browsers; I still find myself spending way too much time trying to get something that works fine in Firefox working in IE9, too, or vice versa. But the geolocation API is so simple that there’s not a lot to break going from one browser to another. That’s good news for developers, and good news for consumers as well.

"