Mashed Articles

There’s a delightful story that does the rounds regarding one of the founding fathers of Linux. It’s said that during the early days of the open-
source operating system’s development, this fellow took to attending conferences in complete silence. All attempts to communicate via means other than hand gestures were refused. Instead, he pointed at things.

Apocryphal or not, the tale remains highly relevant today. Our hero’s beef was with the windows-based graphical interface metaphor and its knack for turning us into mouse-pointing morons. Fast-forward a decade or two and astonishingly little has changed. The windows GUI has, you might say, proven to be extremely gluey.

The classic case study is Microsoft’s eponymous Windows OS. Admittedly, early versions of Windows would seem pretty alien to today’s users – but that’s an illusion. Look past the clunky graphics and Windows 95 is largely identical even to Windows 7, Redmond’s latest and greatest OS. Icons, taskbar, the folder metaphor – all are essentially the same as they were 15 years ago.

That’s a long time in any industry, but it’s an absolute eternity in information technology. Along the way, Microsoft has flirted with a few interesting new features. Early betas of Vista included widespread use of virtual folders and the promise of a fully vectorised and hence scalable graphical interface, for instance. But in the end, the retail build of Vista was yet another reskin of Windows NT, just a bit prettier.

Linux and Apple’s Macintosh operating systems have scarcely been any more innovative. More user-friendly and configurable? Perhaps. More polished? Certainly. But both remain firmly rooted in the window-juggling keyboard-and-mouse camp.

Compared to the enormous advances made in computer hardware, it’s all a bit bizarre. Back in 1995, a single-core Pentium processor running at 100MHz or so was your lot. That’s an in-order 3.1 million transistor chip with 8kB of cache memory, for goodness sake. Today, we’re up to six cores, multiple GHz, over a billion transistors and cache pools nigh on double-digits in MB.

If you think that’s merely a matter of scale rather than a new paradigm per se, what about features such as virtualisation or hardware-accelerated 3D graphics? That’s to say nothing of the rapid rise of LCD monitors and more recently solid-state drives. By any sane metric, computer hardware has been in a constant state of revolution. It’s utterly relentless.

So, not to put too fine a point on it, what gives with GUIs? The answer, frankly, is that I don’t know. Over the years, I’ve visited several labs dedicated to advanced interface research, including those of Microsoft and Intel. I’ve even interviewed luminaries from the heyday of interface research, including some who worked at the fabled Xerox PARC lab in Palo Alto. The very people who invented the GUI, in other words. In fact, I reckon I’ve spoken to all the right people. I’ve played with all the latest table-top, touchscreen human-machine interfaces. But I remain essentially clueless. Nothing I’ve seen or heard of is obviously the next big thing.

At this point, Apple’s iPad inevitably hovers into view. A remarkable device in many ways, it’s no good for data input or content creation and therefore doesn’t offer a plausible alternative for desktop computing. However, what it does is underline just how painful the Windows interface is. Once you’ve danced around a few of your favourite websites courtesy of the iPad’s delightfully responsive screen, the scrolly-scrolly, pointy-clicky PC experience seems pretty laughable.

Even a good smartphone can make the PC feel clumsy; I often prefer reading emails on mine. Replying to them is out of the question, but as a viewing device it’s very pleasant and provides temporary relief from what is becoming an overly familiar and oppressive desktop computing experience. You could say the differences are largely arbitrary, but trawling emails on my phone feels like a break from work. That’s got to say something about the tiredness of the windows metaphor.

Building a great website is tough, but finishing the code and layout is only half the story. Too many sites have problems after going live because they weren’t tested properly first. Lots of things can and do go wrong, from poorly formatted code that some browsers choke on, to pages that break when opened on other platforms. If you developed your site on a Mac, what guarantee do you have that it’ll look the same on a PC, for example?

Your site is a prism for browser light. Make sure it’s not a flawed one.

Even now, when HTML structures are likely to be served as part of a CMS template system, it’s important that all the basics are in place. You need a soak test: a checklist of crucial areas that you can test are working before the site goes live. That’s exactly what we’ve put together here. Follow our tips and your site will be as problem-free as possible.

Clean up your code

Clean, glitch-free code with no stray tags or unclosed comments looks better, is easier to edit and is less likely to spring surprises on you when your site goes live. WYSIWYG web authoring tools already include features for tidying up your code. Let’s face it – some of us really need them. Dreamweaver will even format and indent your HTML following your configuration guidelines. Go to ‘Commands | Clean Up HTML’ or ‘Clean Up XHTML’.

We prefer to run static code through HTML Tidy, which is available as a stand-alone program from http://tidy.sourceforge.net/#binaries, or as a plug-in for manual code-editing tool NoteTab Light. The software deletes stray tags, adds any missing tag elements and completes open tags for you.

Meet HTML standards

Compliance with World Wide Web Consortium (W3C) standards makes your sites more accessible and usable, and also helps them to perform well on multiple platforms. You can see whether your site is compliant with XHTML and CSS standards by using W3C’s online validation tools. You’ll find the main testing page at http://validator.w3.org. This gives you a full breakdown of all the syntax and code errors in any page submitted. You can then update your code in accordance with the guidelines. Don’t be disheartened if your site fails. Some of the web’s biggest sites have XHTML errors according to the validator, including Google and Microsoft’s homepages.

There are numerous tools online that will validate your site for compliance with the relevant standards.

To use the W3C’s validation tool, go to http://validator.w3.org and enter the URL of the web page you wish to test. You can also upload code from a local machine or paste HTML mark-up into the Direct Input box. The validator can only check one page at a time.

Meet CSS standards

There’s a second service available to help you check and correct CSS scripts. It can be found at http://jigsaw.w3.org/css-validator. Again, you can point the validator to a version of the file you wish to check online, upload the code or paste it directly into a box.

The errors returned come with detailed explanations of how you can fix them. The validator will identify even the smallest of problems, including missing line terminators and brackets.

Enable resizing

Remember the early days of the web, when sites came with front-page disclaimers such as ‘Optimised for Internet Explorer at a resolution of 800 x 600 pixels’? How we groaned. Don’t forget that people are viewing your site on different platforms, with different display settings and monitor resolutions. Enabling your page to resize to any browser means that it will work better on multiple platforms, from desktop machines to handheld devices. The key is to use percentage sizes when creating <div> layers rather than specifying fixed sizes. It’s a tough habit to get into, especially if you’ve become used to creating exactly positioned layouts.

Resizer is essential for testing the flexibility of your site’s design.

First, check that your site looks good on the largest monitor size your setup can muster, then work backwards – down to 800 x 600 pixels. Right-click your Windows desktop and choose ‘Properties’. Click ‘Settings’ and you’ll be able to change your default desktop resolution using a slider. If you use Vista, choose ‘Personalise’ from the contextual menu instead. It’s even easier in Windows 7 – there should be a right-click menu item labelled ‘Screen Resolution’. Some video card control panels let you do this without venturing into Windows’ display settings.

Test on all browsers

It’s important to make sure that pages look the same in the big five browsers: Internet Explorer, Firefox, Chrome, Safari and Opera. Fire up your site in each of these and make a careful comparison. Here’s a quick tip: if you have two browsers open showing the same page, right-click on an empty part of the Windows taskbar and choose ‘Tile windows horizontally’ (or ‘Show windows side by side’ on Windows 7). This makes it easier to spot differences.

Five browsers on one system may seem like overload, but there are ways to cut that down. If you’re a Firefox user, you can install IE Tab, a plug-in that enables you to view pages using Internet Explorer’s rendering engine. There’s also Chrome View, which renders pages in Firefox using Google Chrome. In short, get Firefox.

Test on Macs and PCs

Your pages should look the same on Macs as they do on PCs running Windows, whether you have access to one or not. The best method is to borrow a Mac to test your site. If you’re developing for a professional audience, you can employ the services of Browsercam instead.

The Litmus test. Run your site through actual browsers on actual operating systems. For a price…

Litmus uses a bank of testing machines running multiple browsers on all the main OSes. For a subscription fee of $49 (£30) a month, it lets you test an unlimited number of web pages. You enter your site’s URL and receive screenshots as it appears on Macs and Windows systems running any of 24 web browsers. Most of the important ones are included, with different iterations of Firefox, IE and Chrome on Windows, and Safari and Camino on the Mac. The only current important omission we can spot is the Mac version of Chrome. $39 (£24) buys you a 14-day ‘project pass’, which is a good choice if you only have a single site to test.

Testing for free

These are trying financial times for most of us, so here are a couple of free solutions. The runaway leader is Adobe Lab’s Flash- and Flex-based BrowserLab. It’s similar to Litmus in that it gives you a side-by-side view of a given URL in a set of chosen browsers. The tool is currently in limited beta and you’ll need an Adobe user account to use the service. Once in, you enter a URL, pick a browser and platform (or choose from the default browser set), then pick your view. As well as side-by-side comparisons, there’s an ‘Onion Skin’ mode that helpfully enables you to see the output of one browser laid over that of another. BrowserLab renders pages using the main browsers on Mac and Windows.

If you’re unable to access BrowserLab, BrowserShots was once a favourite of ours and is still good for checking multiple versions of Internet Explorer on Windows. Support for Macs has waned, but there are Linux- and Windows-based WebKit browsers included. WebKit is the rendering engine used in Apple Safari, and Google Chrome uses a tweaked version.

Check your gamma

A perennial brain-ache for designers working on Macs and PCs is that, until recently, Mac displays had different default gamma settings to PC monitors. These settings determine the relative brightness of the screen. PCs have a gamma setting of 2.2, whereas Macs had a gamma setting of 1.8. We say ‘had’, because that changed with the release of OS X 10.6 (Snow Leopard), which sets display gamma to 2.2 – the same as PCs and TVs. Even so, many people still use older Macs, and there’s a disproportionate number of Mac-based designers. The result? Images produced on pre-Snow Leopard Macs can look muddy on PCs, while PC-created pics can seem washed out on older Macs. The solution is to check images at both gamma settings to make sure they look OK either way.

You can never be entirely sure of the look of your site, but it does pay to test varying gamma settings.

Adobe Photoshop has a built-in Mac (or PC) gamma preview feature. Select ‘2 Up’ in the Save for Web dialog, then set an image to render using the setting ‘Macintosh (no colour management)’. It’s arguably more important that Mac-based designers get it right than PC users – and if you’re a Mac owner, you can switch your display to PC gamma in the Display section of the System Preferences panel. Click ‘Colour’, choose the current profile and click ‘Calibrate’. Work your way through the Display Calibration Assistant and choose ‘2.2 Television Gamma’.

Buy a Mac

If you have a lot of sites to test, it might be worth investing in one of Apple’s diminutive Mac Minis. They start at £510 (or even less on the second-hand market), are small, stylish and make excellent media centre PCs. Load yours up with Google Chrome, Camino and Firefox and you’ll be ready to test as many sites as you need to. You don’t even need to leave your PC to do so – you can use free remote desktop software TeamViewer to access and control any application on a TeamViewer-equipped Mac from a PC, or vice versa. The machines don’t even have to be on the same LAN, because connectivity is routed over the internet.

DDA accessibility

Your site needs to be accessible to all users – that’s the law. The Disability Discrimination Act is the main legislation covering this area, and the guidelines you need to match have been laid out by the World Wide Web Consortium. Full details are at www.w3.org/WAI.

Accessibility testing will help make your site available to all potential visitors.

There are fewer online accessibility testing services available in 2010 than there were in 2000 because many of them have become commercial. For example, you can use Adobe Dreamweaver to produce an accessibility report. Go to ‘Site | Reports’, then go through the Accessibility section to select elements to test.

Fujitsu offers a free tool that does a similar job, letting you test your site locally on Windows or Mac OS X. Download the Web Accessibility Inspector from www.bit.ly/aDgNZD. There’s also the Fangs screen reader emulator (www.bit.ly/bDhCfQ). It’s an add-on for Firefox that shows you how your pages will be seen by readers, enabling you to tweak the textual content.

Speed

The need for speed never went away – you should still optimise images and link to multimedia rather than embedding it directly. This is particularly pertinent in the light of Google’s recent admission that page speed is a component of its labyrinthine page rank algorithm.

OctaGate SiteTimer is a free service that not only tells you how speedy your pages are to download, but also pinpoints exactly where any bottlenecks may occur. As pages download, SiteTimer saves data on every element, recording how long each takes to download. More recently, Google came up with Page Speed, a Firefox add-on that you can use to generate a report on your code and your web server’s efficiency in delivering it. If there’s a bottleneck, Page Speed will find it.

User experience testing

Big web companies pay lots of cash to have their sites tested by specialist usability testing agencies. They’re looking for problems with the navigation system, embedded media and the site’s overall flow. However, you can cobble together your own tests with very few resources. All you really need is a group of people, some computers, a site to test and the right set of questions. Your first task is to gather a test group together. The group doesn’t have to be large, but its makeup should correspond roughly to your site’s target demographic.

Present your subjects with variations on your site or page design. Are you unsure where the shopping cart works best, or whether that dark, hi-tech colour scheme works better than a lighter, cleaner presentation? Try the different layouts out on your group of test subjects.

Put together a list of questions to ask your test group. You could ask them to rate site navigation, look and feel and whether they could easily find what they wanted. You could also ask them specifically what they liked and disliked about each aspect of the site.

Profiting from Linux doesn’t involve an obvious winning formula. There are as many different business models as there are distributions, and you seldom find much overlap between those that are working. Instead, you find something more like the world of medieval patronage. It’s a place where the great distribution families fight for favour, sponsoring masked balls and conferences, while trying to attract geek heroes to work under their flags.

Yet despite this somewhat unconventional system, there’s no doubt that profit drives development, progress and ambition. You only have to look as far as the kernel at the heart of the system to see the proof. There may be terabytes of projected idealism in there, but a significant proportion is more prosaically driven and developed by business. When kernel supremo Greg Kroah-Hartman last collated contributions in 2008, he found some surprising statistics. For example, there may be over a thousand developers working on the latest versions, but a mere 10 individuals were responsible for almost 15 per cent of the code added to the kernel in the three years up to 2008. A further 20 individuals take that total to 30 per cent.

This is remarkable when you consider that version 2.6.33 of the kernel – released in February – more than doubles the number of lines of code found in the vanilla kernel from December 2003. That’s 13 million lines, an assemblage that has recently been estimated to be worth over £900million by researchers at the University of Oviedo in Spain.

What’s even more interesting is the list of who’s paying for these contributions. Top of this chart are independent developers, accounting for almost 14 per cent of the work, and these are closely followed by a group whose company sponsors are unknown. Third in the chart is Red Hat, followed by Novell, IBM and Intel. These four accounted for almost a third of kernel development in 2008, and there can be no doubt that each company’s motivation is far from altruistic.

If you had any doubts, note that Microsoft joined the party last July by contributing 20,000 lines of its own code to the kernel to help people running virtualized Linux from their Windows machines. Even though it’s more likely that this act was crafted to avoid legal action, rather than a flush of generosity, it still illustrates that the kernel has become a cut-throat gladiatorial arena in the fight for big business.

However, there’s one influential distribution that is completely absent from Greg’s Hall of Fame. Like the others, it’s a commercial endeavour. Unlike them, it neither makes a profit nor has a clear business model. This is despite it being the number one distro. Ubuntu, developed by Canonical, is the perfect example of what happens when Linux ideology and business meet.

Canonical is a global enterprise, funded by Mark Shuttleworth’s sale of Thawte for $575million in 1999. The charismatic figurehead combined coding skills with a penchant for space flight. He selected his early Ubuntu team by taking six months’ of Debian mailing-list archives with him on an ice-breaker to Antarctica, and choosing those whose comments and contributions he judged most worthy.

Despite its market share, Canonical is desperately trying to find a revenue stream from somewhere. It’s a sign of the sober, business-oriented times that Shuttleworth’s successor, Jane Silbur, isn’t an ex-astronaut, but ex-Vice President of Command and Control Systems at General Dynamics C4 Systems.

At the enterprise-end of the business, it’s chasing clouds by bundling an Amazon EC2 compatible server/client solution and selling support. At the user-end, Canonical has just launched its own online music store. This is a service heavily tied to its own remote storage service, which is used to download and store the tracks you buy, available only in the patent-riddled and legally ambiguous MP3 format.

Mark Shuttleworth’s parting blog post proclaimed he’ll be concentrating on “product design, partnerships and customers”, and the proof seems visible in the new release of Ubuntu. But Mark has also signalled another change for Ubuntu users. In a recent mailing list post dealing with community criticism of recent design changes, Mark wrote, “This is not a democracy. Good feedback, good data, are welcome. But we are not voting on design decisions.” These aren’t the words of a geek with his head in the stars, but of a man who has fallen to earth. And things have changed.