Timeshifting Interactive Blog

Web Directions is a series of web conferences held in North America, Europe and Australia. I’ve been to several of their previous events and I recently attended the first of their Web Directions Code series in Melbourne last month. Most conferences are a mix of business, technical and inspirational talks,  but this one was different. Two solid days of tech, the first on HTML5 and Mobile, and the second JavaScript, the programming language that powers the web.

Some of the technologies for browser based games coming out are simply amazing. Hardware accelerated 3D graphics, ability to use PS3 or Xbox controllers within the browser, and full screen game play. Many of the demos looked indistinguishable from games on the PlayStation 3 and other consoles. Compared to Flash, HTML5 based technologies are definitely on an equal footing — of course unless the site needs to work in Internet Explorer. Some things never change…

There were many good take-aways from the talks. Improving tools was one of the main ones, one that I’ve now had a chance to implement. I’ve built a number of new tools in both shell scripts and compiled code to validate the code quality of the sites I produce. These validators, called ‘lint’ in programming, help make sure the sites I build not only work but are well written too. I’ve made a tool to help automate site creation, which really improves consistency – another core part of quality work.

It’s really incredible how far JavaScript has come as a language. The number of places it’s now used outside the browser is amazing – server-side to run web servers, inside PDF documents to validate forms and as the automation language of choice in many applications, including Photoshop and InDesign. As the language matures, so do the best practices and this conference was a great opportunity to catch up on the latest thinking in this area.

And last but not least, another if not web related takeaway was Decaf Sucks, a coffee review site that is excellent if you’re visiting Australia – really takes the stress out of finding a decent espresso!

As a web developer I see these mistakes too often when browsing the web: do any of these affect your site?

1. No Opening Hours
   You would be surprised how many sites don’t have this essential piece of basic information. If you have a retail business, people visting your site most likely want to know where you are and when you’re open. There’s nothing more annoying than turning up at a business, and finding them closed because you couldn’t find out their business hours.
2. Poorly Designed Credit Card Forms
   So many e-commerce sites get this wrong, it seems like no thought goes into this most information screen. If the customer has reached the last screen of the checkout process, you want to make it as easy as possible to complete the transaction. The details printed on credit cards are always laid out in the same order, top to bottom: card number, expiry, name on card. The customer copies the details line by line into the form — easy, right? Except how often have you started to type in the card number and then realised the first field was labelled ‘Name on Card’? Don’t make your customer do more work then they need to, make sure the form is laid out like the card.
3. Assuming Familiarity
   This is another content issue. Sites that seem to assume you’re already very familiar with their business and products, and thus provide no information about what they do or the value their products provide. It’s very uncommon for a business not to want new customers, yet many sites like this exist – by all means provide information for your existing clients, but don’t alienate potential new ones by ignoring them in your content strategy.
4. Are You Local?
   In the past, the holy grail of domain names was the ‘dot com’. But the Internet has become more congested with sites, so users are now scanning the search results for regional domain, like .com.au or .co.nz. For businesses based in New Zealand it’s much better to have a .co.nz address than .net or even a .com address.
5. Login and Abandon
   If pages on your site require login, make sure they redirect correctly after login. For example if a user follows a bookmark to a page that requires login, after they login, make sure they’re redirected to the page they were trying to reach and not default post login page. This seems to happen more often than it should, hopefully not on your site!

and one extra…

6. Captchas
   Those little hard to read number and letter codes to make sure a human is filling out the form. If your site has this functionality — make sure they work as there’s nothing more annoying than an unsolvable captcha!

We’ve worked on a number of multilingual sites over the last few years, each coming with its own set of challenges. Often it’s easy to underestimate the extra amount of work an additional language will add. Design is the main area that needs to be considered, but it’s also important not to forget about messaging and quality assurance.

Design needs to take into account the different amount of space each language will need to say the same thing. Problem areas include menus, dialogs and buttons. For example, on any given button, the text in French will be four times wider than in Chinese; this means that not only will the button have to be wider, but its container also needs to be able to accommodate the extra length.

There are roughly four main language groups:

• English: 100% width
• European: on average 130% wider than English
• Complex Scripts (Thai, Arabic, Hindi, etc.): generally about 80% of the width of English
  and can be right-to-left
• CJK (Chinese, Japanese and Korean): on average 50% of the width of English

If the design requires copy to fit tightly, then a separate layout for each language or language group is the best option. The alternative is a design with built-in flexibility to handle variations in content width. Designing for the longest language, and allowing for the layout to contract if necessary, tends to be the best plan of attack. Trying to build a design that works for all languages, unless it’s very simple, generally ends up with a poor visual result.

Messaging is easy to overlook, but there are a lot of places where error messages can be generated. There’s the front-end in form validation and the back-end in Ajax responses; all the possible error, confirmation and status messages need to be translated. In addition, Quality Assurance needs to test every combination in every language – and if several languages are involved, the amount of work can really add up.

Multilingual sites can be straightforward if they’ve been well planned, but it’s never a case of just dropping in replacement copy over the English text!

We’re a big fan of using the latest APIs and pushing browser-based technologies to their limits. A recent project required complex Google Maps implementation, so the new version 3 API was the obvious choice. It’s many times faster than the previous version, has location services, and works well on mobile devices (like the iPhone). The project’s mapping functionality proved to be a success; however, it wasn’t without a few technical challenges along the way.

One of the problems with adopting new API’s is that the eco-system of code that interacts and extends it is often very immature as well. Code examples can also be a little sparse, though fortunately Google’s documentation was excellent in this regard. The difficulty is when you need something that’s not included in the box. Our map has markers, a lot of markers, thousands of them in fact, and to stop the browser impaling itself on a spike we needed marker clustering.

Clustering is where you replace several individual markers with a single marker group icon that indicates to the user that there is X number of markers in this location. The more you zoom out, the greater the number of markers grouped into each cluster. The clustering solutions for Google Maps version 2 were numerous, but for version 3 there was just a handful. The most suitable library was barely 3 weeks old, certainly immature, but as a port of a stable release of the same library for the v2 API it was a viable option.

This is where the having a strong knowledge of the language and the browsers you are working with is really helpful. The library definitely had a few bugs, but having come from a time before JavaScript libraries it was easy to write override methods to patch these until library author corrected them. In between the initial implementation and project release the library authors did in fact patch those issues, so we were able to drop in the latest code and dispense with these patches.

Another problem we faced was that the styling provided by the library was limited. It expected the marker to be centered on the location, rather than above the location as the design needed. Method overrides and a good understanding of cross-browser rendering bugs allowed us to extend the library to meet our – and our client’s – needs.

I still wonder if too many new programmers now rely too heavily on JavaScript libraries, without understanding how things work behind the scenes. Every browser will always have its quirks and a professional front end developer should know how to deal with these. I’m not advocating against using JavaScript libraries, as they definitely get projects out faster and reduce costs. But if things don’t work correctly, or if they require slightly different functionality, I wonder whether many programmers would cope without their jQuery fix.

Search is one of those things that seems simple but is difficult to do well. The most common problem users tend to face when searching is that either no results are returned, or there are too many irrelevant results.

On a recent project we had the case of a simple keyword search bar that not only had to return relevant results but aggregate data returned from several sources. The user expects to type a search and get nicely-formatted results that match their query. Our problem was that the results came in multiple formats from multiple servers with quite variable response times.

The project in question was a Google Maps API and Google Local Search API powered Facebook Application. A search query could match one of several things: an address (Google Maps API Geocoder), a business or landmark name (Google Local Search API with the current view port of the map), a user’s name or personal details (either from the local database or via the Facebook API), or a game location (from the local database). The Google-related searches are done in JavaScript and the Facebook/local database ones were SQL queries in PHP.

Our initial implementation was to have tabs. The Addresses search was run, results were shown, and the other inactive tabs when clicked would carry out their respective searches. The problem was that there was no guarantee the first search type (addresses in this case) would return any results, and if the businesses search had returned results it would have been much better to display that first. The tabbed interface was also very disjointed, as swapping tabs had to perform the search (causing a delay), and users expect switching tabs to be instant. Also, the usability suffered, because if the search resulted in a few matches of each type, you couldn’t see them all on one screen.

The final implementation was in two parts. Firstly, all the searches were executed in parallel via Ajax, displaying and updating a progress bar as each was completed. This visual feedback helped offset the now-longer delay before any results were displayed. Then the data returned from each API was normalized so it could be fed to a single HTML render, facilitating output into the same screen. This allows the results to be displayed in a single list, grouped by type. Types with no results (or ones that timed out) are omitted from the output, pushing the relevant results to the top.