Every now and then I come across a new product or technique that causes a lightbulb to come on – suddenly I know I will never code the same way again.

Landmark events over the years might include the realisation that PHP is a proper programming language (although I did keep Perl up my sleeves for the odd task), how to use Subversion to version control a website (must write that one up sometime), reading Zeldman’s “designing with web standards” …

Not quite in the same league perhaps, but I’ve finally got around to having a good play with jQuery, and doesn’t that open up whole new fields of possibility?

Having ‘bought into’ Standards there has always been an internal conflict with any superfluous markup that has to go on a page for eye candy or other frippery, such as the dreaded rounded corners problem. Suddenly, there is a simple way to tinker with the DOM to make such effects possible, without having to put anything more in the base code than a few calls to JavaScript includes. But it sounds too good to be true. It can’t be legal can it?

I suppose the answer to that is that there isn’t one answer – it all depends how you wield the tool. If you disable JavaScript and the page still ‘works’ – then all jQuery is doing is adding some glitz and if it’s keeping the markup etc. cleaner and more semantic then that has to be a good thing.

But what is the definition of ‘works’? It depends what the page is meant to do. It could be an informative page so ‘works’ is can you access the content in the correct context and get appropriate meaning from it. Or it might be a bit of functionality – a form or a blog or whatever.

With the power comes responsibility, and the temptation to run riot and get all inappropriate. I’ve seen some pretty dubious examples of the use of jQuery – putting ‘back to top’ links on a page, or altering anchors if they link to external resources – that starts risking Accessibility and potentially usability. Use of AJAX without a non-js method of doing the same thing – form validation and submission for instance. Face it you could use it to construct a whole site on the fly if you wanted. But that would be a Bad Thing in my book unless there was exceptional reasoning behind it and some sort of mitigation for non JavaScript users.

I’m sure I will be making a lot of use of jQuery in the future, but I will be keeping a close check on myself to make sure it’s appropriate. For reference, here’s a simplistic view of how I tend to approach a new build currently:

• Analyse what the page is about and prioritise requested / identified features in a sort of MoSCoW list
• Design html structure to represent it, check it makes sense in text browser
• Analyse ‘look and feel’ requirements and design css / JavaScript to implement them
• If necessary adjust html to make the presentation layer easier / possible, but as little as possible (argue negotiate with client / designers as appropriate)
• Never forget a print stylesheet, and probably nowadays it would be good to consider mobile devices
• Do everything server-side to deliver the page and handle any actions the page produces
• Complete content population & coding
• Test degradation from latest browsers with everything turned on through old browsers, text browsers, phones, anything I can get my hands on until I get bored- ensuring ‘must have’ features work in all, ‘should have’ and ‘could have’ work in as many as is feasible.

As posted earlier, I’m going back to my roots after 6 years in the relatively comfortable life of an employee of a large agency, and specifically as someone who has had a sabbatical from mainstream development whilst managing a team of developers.

Now I’m back on my own again I’m reviewing my skills and experience, the current state of the industry and best practice, and sorting my tools and techniques out ready to get busy (hopefully).

It’s amazing how much has changed in the intervening years and yet how much is the same. Packing up my desk and hunting down the books I took to Soup, many are well thumbed from regular use despite their age they are still relevant. I’ve also been compiling a wishlist on Amazon of titles bought for the company library that I will want to get copies of, but to be honest there aren’t many essentials – good references for PHP, MySQL, CSS, Apache, JavaScript etc. But even then can be found online – it’s much easier to type http://uk.php.net/explode to remember what order to pass parameters to explode() for instance than to find the book – but I digress.

I’ve been rebuilding a few sites I first built oh-so-many-years-ago – one was even still using Dreamweaver Templates <hangs head in shame> – but they are still doing the business for the owners and all they want is a quick design refresh and a bit of new content. “Oh, and while you’re at it could you just add a news section we can update ourselves?” So the quandary begins – how much do you reuse and how much do you rebuild, and what technologies do you use?

Perhaps unlike many working by themselves on ‘smaller’ sites, my recent background has exposed me to all shapes and sites of web content delivery technologies, from full on Enterprise level Content Management Systems such as Vignette and Stellent, other commercial ones like RedDot, or open source ones like Drupal or Joomla! or in between like Expression Engine, and then of course there’s all the custom applications that get written for specific applications, or reusable frameworks and libraries that can give advantages in rapid deployment / development.

And then there’s the platform to build on – once is was a choice of flat html (with some help from Dreamweaver perhaps) or Perl (or the new kid PHP) or ASP. Now there’s all the Java based technologies, Python based (I still reckon Zope should have become more mainstream) ASP.NET, Ruby on Rails, and of course my old favourite PHP is going from strength to strength. And it doesn’t stop server-side, with the advent of AJAX and frameworks such as jQuery, so much more can be done on the browser.

I understand and buy into Standards Compliance, Accessibility, Search Engine Optimisation, Usability and all the other buzzwords. I’m able to gather requirements, write specifications, manage projects and carry out quality reviews. I’ve been involved in projects that have been great successes, and others that have spectacularly failed, enough to know how to avoid the pitfalls.

But does all that knowledge and experience help in my current situation and perhaps give me an advantage over someone only just starting in the industry? It’s a mixed blessing because although I rarely have to say “I have no idea how to do that or what’s involved”, the opposite is also a problem because I know of perhaps too many possibilities and alternatives, and how things could be done ‘properly’.

As a little aside, I’ve often observed that any sort of development or design or construction or problem solving that is done in a constrained environment is likely to have a much more creative and pleasing outcome than if done with the luxury of infinite possibilities – it makes you focus and think and consider relative merits of alternatives with a clearer vision of the ultimate goal rather than being dazzled or distracted by niceties.

So how have I tackled these rebuilds? Well the Dreamweaver Templates site is hopefully a textbook example of how to use PHP to make a relatively simple brochureware site more maintainable. The templating features of Dreamweaver (ah yes, I remember them well!) have been replaced with PHP includes – so common elements like html <head>, top level page layout, navigation etc. are all shared. A ‘page’ is represented by a PHP file which sets variables such as page title, navigation state, calls the relevant includes for the top of the page, have the body content hard coded, then calls the footer includes. The one dynamic page is the news section which calls content from a MySQL database, with a little utility script allowing the client to manage news stories.

Why didn’t I use my first project as a freelancer again to flex my muscles and show off all my skills? Because the requirements didn’t need it. This application is beautifully simple, very easy to host and maintain, blisteringly fast, and hopefully will go another five or six years before its next rebuild. Any half competent developer could look at the source and figure out how to make any changes within minutes of getting access to the source. And it only took a couple of days to complete – including me trying to come up with some sort of new visual design and I’m no designer!

This approach has been used by me and my team for many years with great success, from small 6 page site to large corporate sites for FTSE100 companies. If it meets all key requirements what’s the advantage of making life more complicated? Admittedly the finer details of how to implement it have changed – using css for layout rather than tables for instance, good clean semantic markup, secure against XSS and SQL Injection (hopefully) and obscuring email addresses from spambots, with a sitemap.xml and Google Analytics tagging, and it’s all under version control …

I’m starting planning a much bigger site that needs more content management, and have reviewed several frameworks and applications to make life easier, but have still settled on the approach above with one small change – using Smarty to separate logic from presentation, and moving more of the content into the database. But it’s still clean, simple, fast and reliable.

KISS – if it’s getting too complex it’s probably wrong.

Ongoing discussions with a colleague about the most appropriate way to deliver websites that are mobile friendly, led him to send me a link to a blog posting in the Opera Community: ‘Open Standards, One Web, and Opera‘. He reckons this demonstrates his view that you should build a standards compliant site, and leave it to standards compliant browsers to adapt. For the record my view is that whilst this approach may work most of the time, better experience can be given to the visitor if you tailor the code being delivered by the server to suit device capabilities.

Summarising the main argument of the piece:

We believe very strongly in 2 main principles:

1. One Web — first coined by the W3C, the one Web principle is what it implies — there should be one single Web that can be accessed by any Web—enabled device, not different content for different devices — this is unsustainable, and a maintenance nightmare — having to maintain several versions of the same content can be really frustrating. The “one Web” is made possible by…
2. Open standards. Technologies such as CSS and HTML are open — they are free for anyone to use and get involved in the evolution of, and because they are also standards, pages created using them should be viewable on any device by anybody, as long as user agent vendors follow the standards. Most vendors, including ourselves, are making a pretty good job of this these days, mostly (hint — there is still a bloated giant out there that has trouble with standards, despite controlling over 70% of the browser market. We won’t name any names…) Proprietary standards, that is, standards that are not free for anyone to use and lock you in to having to use a single/few company’s products, are bad for the one Web, and are often inaccessible (that is, not usable by users with disabilities) and expensive to develop with.

I can’t and won’t argue against either point – I believe in them too, but that doesn’t mean I necessarily agree with the implication that ‘one web’ implies ‘one website’ – i.e. one set of code that gets delivered to all devices.

That’s getting a bit close to ‘lowest common denominator’ where you don’t use particular techniques or features if not supported by all devices you’re building for, or another risk is that you’re abandoning a chunk of your audience for the sin of not using a standards compliant browser (that could be 90%+ of your potential audience!)

Where in those two principles does it say you can’t adapt code a bit to suit device capabilities – and before I get screamed at for suggesting multiple sites / thousands of separate templates / layouts etc. note the phrase ‘a bit’ – and use some of the power going spare in our modern day servers? A pragmatic approach rather than dogmatic.

‘One Web’ is about content – reading what the W3C say about One Web in their Mobile Web Best Practices:

“One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation.”

i.e. The content should be the same, but the way it’s being presented could be adapted to suit the device.

Not all devices / browsers are equal – some have very special needs, particularly mobile ones. Even if they can render full standards compliant web pages, there are problems of bandwidth and memory. Mobile devices will perform better with nice light pages, whereas Desktop users are perfectly happy with big bloated ones.

Screen size and navigation – yes I love the iPhone’s zooming, but at the end of the day when you start to read a site or try and use the navigation, the screen is only 320×480 pixels, and a fat finger is less precise that a mouse. So the likelihood is that a navigation system that works well at 1024×768 with a mouse, might be a bit fiddly on an iPhone, let alone a mobile using a simulated mouse or keys, on the other hand something simple enough for a mobile might be really tame on a Desktop.

But which standard? xhtml is getting wider support within higher spec phones now, but it’s still widely regarded that XHTML-MP is supported by the overwhelming majority of mobile browsers. And what about old phones that prefer WML? Just because you’re sending different markup to different devices doesn’t mean that the markup used won’t be standards compliant.

In summary – ‘one web‘ – yes. ‘Use standards‘ – yes. But adapt the output a bit to better match device capabilities. If my understanding is right that’s also what the W3C is saying.

First Safari mobile on the iPhone, now Opera Mini 4, it would seem that the trend for mobile browsers is to pretend they’re a Desktop, and to persuade sites not to dumb down the presentation enabling the browser to wow us with zooming etc. they’re ignoring handheld stylesheets. However, new CSS3 features like media queries which allow different stylesheets to be included based on for example screen size.

As discussed on Unintentionally Blank a few weeks back, the reasoning seems to be to save the users from the developers who apparently all want to dish up ‘dumbed down’ sites for mobile devices.

But surely we all agree that mobile devices are not desktop devices – you use them in different contexts and have different requirements. Whilst I appreciate that not all mobile users want a dumbed down site, let’s have choice rather than imposition. And taking away tools that can have a positive benefit if used properly is removing choice.

I’ve used Joomla! a few times in the past to deliver community based sites that need a CMS but can’t justify having huge amounts of time spent on developing the site. It’s taken a few goes, getting more comfortable every time (I’m too lazy to RTFM) but I might be starting to get it.

As with many things on the web, it’s not quite like anything else and there’s a critical mass of knowledge you have to accumulate before you really understand what’s going on and make good decisions.

I’ve been asked to help out with a site for a school – in theory Joomla! should be ideal.

My biggest challenge is deciding when to use static content and when to use the section/category com_content or whatever-it’s called. Ideal for blogging, news stories etc., but not so good for more brochureware type sites.

And then there’s the menu (navigation) – there seems to be a very tenuous link between the menu and the content – often you have to duplicate a content object with a menu item, then sort it, and if you want to change the type of object a menu item links to (Link – category item for instance) or the specific object – you have to delete it and make a new one.

It’s also a shame that the core user functionality can’t restrict users to specific areas of the site – you can’t have one group edit one area and another group manage a different one.

Anyway, I’m sure there are mods and bots that can address this, but I’ve been too lazy to find them – I’m managing to get it doing what I want now.

My other half makes cakes, and like a good hubby I did her a website some time back – but like the old saying about cobblers children it should really be a bit more impressive than it is.

The main part is the gallery, and I started off with something I knocked up in an hour or so, but recently thought it needed some attention – didn’t look very good or work well, and was a nightmare to maintain.

So, the old quandary – do I start from scratch, search in vain for the perfect thing, or find something that’s close and adapt it (or put up with the failings)?

I went through a few gallery packages, and they either were to huge and clonky, or didn’t work (or I couldn’t be arsed to fiddle to make them work) or they had entirely the wrong feature set so I’d have to turn too much off. I didn’t want comments or other UGC / sharing / web 2.0 type features, I just wanted a nice simple way to display categorised groups of images with a little bit of description.

And since the images were being taken on a 6mp camera, and we didn’t want / need the full size image online, there should be an easy way to do the resizing / thumbnail generation etc.

And it should be light, and simple, and … nice.

I was just about to give up the search and write my own – I was thinking ftp images up into folders and have a very simple script that if it saw a new image would just display it, and if it found some meta-data in a text file or some such would disply that alongside. No need for databases or anything complex.

And then I found SPGM – and I found that someone had already written it. I’ve commented before on my love/hate with open source, but this is defintely on the love side. It’s just the thing, and almost exactly what I had in mind – in fact better because I didn’t have to write it.

So I install it, and it works first time, and I start thinking “OK, it’s great, but it could do with a basic tool to help with thumbnail creation and editing the meta-data” and then I read on and found that had been written too – SPGM Webministration – it was light and it worked first time and was just the thing. Two for two!

So I’ve knocked up a quick Firewoks macro to automate the process of generating 640×480 images to upload (don’t want to waste too much bandwidth by having the conversion done on the server) and 100 odd images are now online and looking funky(ish), in practically no time. And I start thinking “I wonder if there’s a tool to do that side of things too” and I check, and there is.

But I haven’t tried that one yet – no sense tempting fate.