Geolocation has been around in the spec for a while, but hasn’t really taken off on the desktop as yet. It’s hugely common in mobile apps for it to ask for your location, but rarely for websites to request this information. Such information can provide localised information relevant to where the user is, and whilst hugely beneficial on mobile devices when out on the go, such information can be put to good use on the desktop as well.
One example where this is used effectively is on the Pizza Express website, where upon sharing of your location will display the nearest restaurant to where you are, and contact information for the restaurant as well as a clear call to action to book a table at the restaurant.
Such a simple use of this technology is effective and one which I feel provides a lot of benefit to the user and could be easily implemented onto more on sites. Coming up I will demo how to create a simple call to ask for the user’s location.
As well as the well-documented additions to the HTML5 spec, a number of elements have had their meanings changed to reflect the changes in the way websites are built and also some previously deprecated elements have been brought back so to speak and now have valid, semantic meaning, allowing us to use the b, i and s elements again without the need to feel dirty whilst we do so!
A list of the changed elements is listed below:
The anchor elements changes in the manner that block-level links are now valid code. This has been supported in browsers for a while, but is now valid. Also, using the name=”#id” convention is now obsolete which was typically used for in page navigation. Instead, apply this technique to it’s containing element. The target attribute is now no longer deprecated “as it useful in Web applications, particularly in combination with the iframe element.”
The media attribute is new and can be used in conjunction with CSS media queries.
The b element has changed from the presentational meaning of bold text to “offset text conventionally styled in bold”. This doesn’t appear to be a massive shift in definition but is a way of separating out content from it’s surroundings without providing any extra meaning. The em and strong attributes embolden the text but provide emphasis on the text, whereas the b element has no extra meaning and is useful in a range of situations.
The cite element refers to the title of a cited work, and not an individual as previously defined. Cite should not be used to mark up a person’s name and instead refers to title of work, ranging from a document to music to games or in fact anything that is referenced in a document.
The hr element used to be a purely presentational element which was used to insert a horizontal line on the page, though it has now been given the meaning of a “paragraph level thematic break”. This means that it can be used to break up a paragraph or to indicate a change in content – it can be used to provide a transition between content within a document and provides a link between the two.
The I element is similar in meaning to the b element in that it used to be a purely presentational element and now represents text that is offset from it’s surroundings but provides no extra emphasis. Anything that is usually presented in italics, but requires no emphasis then the I element should be used and there is no need for extra spans messing up your markup.
The menu element has changed from a “single column menu list” to specifically referring to a list of commands. Potentially more useful in web applications as opposed to traditional websites, the type attribute declares whether it is a toolbar or a context menu. If no type is defined, then it represents commands that are neither a toolbar or context menu.
The s attribute was a purely presentational method of applying a line-through to text, however this has been changed to be given the semantic meaning of “struck text”, which is text that is no longer accurate or relevant. An example of this would be previous prices on e-commerce sites, I’ve been using this element to mark these up and has the benefit of more semantic meaning and no need for presentational span elements.
The small element was also a presentational element which referred to text which was to be rendered as small. This has now changed to be given the semantic meaning of “small print” and refers to content such as copyright notices, or links to the development company of the website.
All of these elements valid code that can be used today in practice without fear and with the benefits of reducing mark up and the need for styling additional span elements which add clutter to our markup and also provides more structured, semantic meaning to our code.
There are over 100 elements in the HTML specification, and it’s fair to say that some are more used by others. Elements like div, ul and table are used on almost every project whereas some are rarely used such as kbd, var and wbr. Some of this is down to browser support and I’ll be honest in my case some down to ignorance of it’s existence.
I’ve done a bit of research into some of these lesser known elements and listed them below, and I certainly intend to use them more in projects now where appropriate.
The base element is a way to declare a base href for the document, which is then used by the relative urls on the page. There is a maximum of one base element per page and is a similar syntax to normal a elements:
The var element is used to markup variables, or text that represents a variable value. In a maths or programming concept, it represents a value which is a variable, or can be used to indicate a value which the user will mentally replace with a custom value.
The samp element is used to mark up sample output of a program. Again, more suited to web applications than standard websites, it’s used for sample output for example a demo of a process or system which generates a value or result depending on a user’s interaction.
It’s an age old argument and one that still rumbles on, but with the expansion of devices, emergence of HTML5 and CSS3 and the continual decline of Internet Explorer and older browsers, it brings it into even sharper focus. It is impossible to make a website look exactly the same on an iPad as it does in IE6 as it does on a BlackBerry as it does in Opera Mini, so why do we waste countless hours and lots of our clients money trying to make the websites we create the same in every browser?
IE is still the most popular browser, although with it’s usage now below or around the 50% mark, then we’re almost at the point where the IE argument is becoming null and void. Why should the 50% of users with the most modern browsers be punished and served an experience way below their browsers capabilities in order to please the other 50%? Is it not better to spend a bit more time and care taking full advantage of these emerging technologies in order to serve an experience and design which is appropriate to the device and makes full use of it’s potential? Yes, the older and less capable browsers won’t be as slick and polished but when designed effectively then the message is still communicated in a clear manner and nothing is lost as the user is still able to access the content, still able to purchase the items they want to buy and do everything else they came to do on the website.
The way fonts are rendered across the range of devices and operating systems immediately rules out any possibility of sites looking exactly the same everywhere and with the new CSS3 properties allowing us to create shadows, borders and rounded corners with only a few lines of CSS, as well as transitions, transforms and animations then we have even greater power at our fingertips. These emerging techniques mean we now have the ability to tailor the designs and experiences we create to the browsers and their capabilities, so users get the best possible experience for the browser that they’re using. If we start at the bottom and take the opinion that websites must always look the same, then we give ourselves an artificial ceiling meaning that we rule a lot of these new techniques, and short change both ourselves and the website owner. New techniques are ruled out because “it won’t work in IE” and our markup becomes littered with empty divs and spans all so we can absolutely position a drop shadow, or even worse include even more hefty JS to a page so that corners can be rounded.
Take the time and alter the layout when switching from landscape to portrait mode on the iPhone/iPad, use media queries to target smartphone browsers, check against more basic mobile browsers as well as testing on the desktop browsers and all the usual stuff like without JS, smaller resolutions and not just check to see if they’re ok but optimise them as best you can for these conditions. The web is not a static medium and we have no control over how a user will access a site, but by optimising for the most common scenarios then we will cover the vast majority of use cases, and cover them to the best level we can.
I think we’ve truly reached the point where we should be binning this idea of everything looking the same everywhere, by taking the time to craft these different experiences then we are able to create better websites which are easier to maintain, often able to develop quicker and deliver a more cost effective solution for our clients and better experiences for our users.
As it’s been a while since I’ve written a blog post, I thought the traditional end of year post would be a good place to round up.
This year has been quite eventful, as I started the year as a full-time student working part-time from home and ended it out of education and working full time with a different employer. As I’ve written before, I wasn’t entirely happy with university and my original plan was to finish the academic year and consider my options over the summer, deciding whether to carry on or seek full-time employment. As it turned out, I was lucky enough to be offered a position with a company here in Dundee and I can honestly say I do not regret leaving uni one bit. I’ve learnt far more in 6 months of work than I did in 2 years of university, and am thoroughly enjoying it.
Something else I’d like to improve greatly is my actual design skills, and spend a lot more time crafting in Photoshop and then implementing in the browser. Or design in the browser but either way I’d like to become much better at designing interfaces from scratch. One way to do this would be to create a psd on a regular basis and to brush up on design theory etc so that I know what I’m doing, and able to improve.
As well as improving on my skills as a designer/front end developer, I’ve a couple of personal projects that I’d like to work on throughout the year, nothing big or extravagant but something where I can flex my muscles a bit and put into practice some stuff in a real live project. I’d like to have something up in the first quarter of the year but we’ll see how I get on.
I’m looking forward to 2011 and hopefully it’s as good as last year.
Last week I inadvertently started a debate at work about how much HTML5 we can use/get away with in client work, with me firmly in the camp of using as much as we can and the HTML5 shiv should be leveraged to serve layouts to IE. For me the advantages outweigh the supposed pitfalls, and by continuing to be restrained by older browsers, including our old favourite, then we’re not only not doing our jobs properly, we’re letting our clients down.
(*Note this is a general argument, not taking into account site specifics such as stats etc.)
For me it’s not a question of whether we use HTML5 (or some of the newer CSS3 declarations), but how much of it we use?
Not even a year since the last re-design, it’s that time again. Whilst I liked the previous design at the time, it wasn’t too long before I started getting the itch to re-do it again. I wasn’t entirely satisfied with the design after a while and recently found the time to re-do it again, keeping the same loose structure and style but updated slightly and less cluttered I think.
For a good while I wanted to include as much information as possible and the site didn’t always have room to breathe and there was limited amounts of whitespace, but this time I’ve tried to space things out better and provide more whitespace to display the most important elements of the site clearly. The same structure is kept as before but just slightly altered to show off the content a bit more.
The site is built using HTML5 and CSS 3 wherever possible and as such looks better in the good browsers and should gracefully degrade in the not so good ones (hello Microsoft!). IE6 I didn’t bother wasting my time with this time, very few people visit this site using that browser and it wasn’t worth my time. Instead, I served it the excellent Universal stylesheet from Andy Clarke. The site works fine in IE7 and IE8 although it doesn’t have all the bells and whistles that it should have. I also upgraded to WordPress 3 and have been playing about with the new custom post types, I’m not quite there with it yet but should have them fully set up and working soon.
I also created a custom iPhone stylesheet which displays the site in a basic manner at the moment, which will improve over the next few weeks as I learn more about creating a specific iPhone stylesheet and improve on the usability and experience of viewing the site on an iPhone. At the moment, content is displayed but it needs more work to improve on the basic layout it currently has.
There’ll still be more improvements and tweaks to the site over the next few weeks as I don’t think it’s perfect and there are areas I need to work on, but I felt it was ok to release and work on the relatively small tweaks over time.
I’m currently in the process of re-designing this site and part of this process means updating it to utilise the latest HTML5 and CSS 3 elements where possible, and as a result of this I’ve used the time element in all dates such as post date and also other dates.
The format of the time element for dates is as follows:
<time datetime="2009-11-13">13 November 2009</time>
The datetime attribute has to contain an ISO 8601 date although the value can contain any date format you wish. When using this with the dynamic nature of wordpress, the following format produces a valid output for post dates: