Back in 2007-8 I was involved in online web accessibility a lot – building websites with good web standards, semantic code and accessible features as part of some contracted work and my own business work. At that time I would probably say that I had an edge over many web developers (and may still have today) in the amount of knowledge and practice that I had.
Over the last 12 months I have been spending more time developing websites using HTML5 – I want to be as knowledgable as I can, but not through reading a lot and following blindly, but by practical application.
Rather than just using the HTML5 boilerplates and frameworks out there, I elected to work out what was really needed in each case – especially as there were various degrees to which I wanted to implement HTML5 and the fact that it is still an evolving standard.
XHTML was doing just fine…
The DAAP website (http://www.daap.org.uk) was one of the last websites I built using XHTML. I liked the restrictions and the semantics in XHTML as it suited the type of projects I had worked on and my passion for accessibility.
Looking at the website it may not have a stunning look, but it is far superior in it’s visual appearance and clarity of navigation than it ever was. There is a mild sprinkling of jQuery to help optimise on space (news and events panels on the home page) and CSS3 to allow for elements to have gradients without the need for background images.
Accessibility was enhanced using skip links (simply press TAB to navigate without the use of a mouse) and a stylesheet switcher for the visually impaired as well as offer the excellent accessible YouTube player developed at http://icant.co.uk/easy-youtube by the great Christian Heilmann.
Step in HTML5
The beauty of HTML5 is that converting the DAAP website to HTML5 only involves changing the doctype and the meta charset. Nothing breaks. But, with the addition of, say, modernizr.js some extra enhancements could take place. But for the scope of this website it isn’t necessary.
The thing about being a web developer is that you do a job, the client is happy and you are rarely asked to come back and update the whole website. So your previous website development almost acts like a map of your coding development.
Not all my code will be as tidy as I would like, but I do like to think I have added commenting where necessary so that someone after me can at least find stuff. If I had the time, I would pick through everything and line up all the tabs.
After some changes at a long-standing client who I did a lot of work for, most of the front-end was taken in-house, so I decided to go contracting. This led to quite a lengthy (5-6 month) contract with a leading fitness club in the UK.
I was responsible for the front-end of a touchscreen interface, website (desktop) and mobile website which were all built using what I would call loose HTML5. The touchscreen was a closed environment, the website was targeted at IE8 and above and the mobile websites, well they all used modern, standards compliant browsers anyway. So there was very little need to use either a HTML5shiv or modernizr.js in the project – the benefits of using HTML came in the UX of form elements, where mobile devices that would detect the type=”email” or type=”tel” would change the appearance of the touchscreen keyboard.
A proper start?
I had a short break of a few weeks after the contract and built a greenfield website in HTML5 proper. The website was a new build for the Yorkshire Music School – Saltaire (YMSS) and can be found at http://www.ymss.co.uk
I only use the HTML5shiv in order to get IE to behave with the code for this project, however in a newer release I am likely to add modernizr to help enhance some aspects of the design when it gets a responsive makeover.
But even with only the HTML5shiv and nothing else added, the website works as expected and has a more semantic code structure in-line with HTML 5. Once again, it would seen that the gloss of HTML5 will come into it’s own in the responsive context on mobile devices…and it is no wonder that there is some noise towards designing for mobile first.
So a good start, as far as I was concerned, and something that can be built upon without leaving a nasty taste in the coders mouth. Which is likely to be my own as the client is happy for me to look after the maintenance of their website and the design of all their printed material.
My latest online CV.
I guess my latest online CV (http://www.visutech.net/cv), although constantly changing, encompasses more of the direction of development I am taking. HTML5 and responsive design from the onset.
Having designed for the desktop, and having designed for mobile only – the responsive route was more of a case of – “which end do I start at?”.
In this case I opted for the desktop first, simply because I perceive that most of the views would be on the desktop of recruitment staff in an office – which the stats supported. So a big lesson, check the stats first, but also think about future trends.
As it happened I sketched down on paper what I perceived to be the different ways I would represent the content before I wen into the built (some ideas are yet to be developed, I have a limited amount of time I can dedicate to my own websites). I had a view of what to do for a desktop, a tablet landscape/portrait and a smart phone, landscape/portrait.
I am fairly happy with the results and looking forward to taking the design forward.
There was an interesting article I read about the crayola.com website and how they went about creating the new responsive design. I did what we tend all tend to do, looked at the website on the desktop, looked at it on a tablet (in my case an iPad) and on a smaller smart phone (my iPhone). I realised that they only had 1 breakpoint. And that was at the mobile size.
In effect a tablet like the iPad will scale the page normally to fit the width, and the text size (in the case of their large text design) was still legible enough. Only when the size got down to that of a smart phone did it change in layout.
So there are cases where you may need to trim back the breakpoints if the design allows.
There is still plenty to practice and many more decisions to make, especially with a few projects I have on the go, but the excitement I have and enthusiasm for deploying more websites with HTML and CSS3 is as exciting as it has been for a while. I only wish that there was more agreement between the browser manufacturers on some of the implementations, such as type=”date”.