Its been pretty quiet on this blog for the last 6 weeks or so. I have been very busy working on an interesting, fairly complex and fairly large JavaScript application during the day and then recovering from it at night! I also had the pleasure of a lovely week away in this period of quiet.
I have also recently got my hands on a rather sexy new phone - an HTC Touch Diamond - and have spent a lot of time playing with that. Its a Windows Mobile PocketPC and its been an interesting experience, particularly Opera 9.5 Mobile which is the default browser.
Browsing on a handheld device has been a new experience for me. My phone comes with Pocket IE installed as well, but that is rather archaic. I have done all I can to avoid using it.
Opera Mobile however is a fantastic browser. Its fairly fast, pretty standards compliant and renders most pages rather well. It has also given me a useful insight into a different type of user agent for browsing the web. Its quite a different experience and its easy to see which sites are well designed and which are not.
I have taken away a couple of important lessons from my experience. Firstly, clear interface design is very important on this type of device. The browser can zoom into pages but when a page loads, it is zoomed out and most text cannot be read clearly at all. However, a site with good design is very usable as I can zoom in on just the right area. Clearly defined navigation really helps with browsing on a mobile device.
The second lesson I have learnt is that the easiest sites to use employ a liquid or semi-liquid layout. My phone has a resolution of 480x640 and if a site can flow its content to fit into either of those widths, that helps greatly. If I were designing a website today, I would definitely ensure it works in a browser width of 640 pixels!
The final lesson I have taken with me thus far is that the size of elements on screen really matters. I use my finger to navigate a website and having links tightly packed together with a small font size makes life very difficult. Having small form fields or form fields with a small font size and another link right next to or just underneath the form field can make it difficult to select the element I want to interact with. Finally, having heavily styled buttons, especially image buttons makes submitting a form harder than it needs to be, particularly if pressing enter on the keyboard does not work.
For me, the most noteworthy new aspect of interface development that I will carry with me is the importance of keyboard interaction with a form - never ever stop a form being submitted with the enter key!
There is much more to say about this phone and browsing the web using Opera, but at least for now, the quiet is no more!
Showing posts with label Accessibility. Show all posts
Showing posts with label Accessibility. Show all posts
30 October 2008
14 May 2008
Usability and accessibility
In recent weeks I have been spending much of my time at work thinking about usability, commenting on it and trying to convince others of my ideas.
This thought has been focussed almost solely around two tasks. The first of these was an interesting proposition - to demonstrate that projects previously completed using Flash could be built using JavaScript. As a useful by-product, I have been able to make some more use of JSquared and particularly my alpha build of FXSquared!
There were two particular products that I have been looking at, the first of which was a finance tool for Fiat. I spent 2 days working on this task and as such was only able to make part of this tool.
I started by building the dials which are the main control for the tool. This involved building a number of animations and some simple interactions. I then worked on the panel which flashes as the values change. Amazingly, in only two days, I was able to match all the functionality of the dials and get the values updating in the panel and get the panel to flash.
Accessibility was not an important consideration however, when reviewing the work I was able to complete, the markup I had written was valid and semantic and the product fully accessible. It was certainly no less usable than the Flash, and due to the keyboard being able to control the tools, it was perhaps more usable. It was accessible and worked without CSS and could be made to work without JavaScript very simply. It was a triumph.
The other product I worked on, was in a similar vein and was a similar success.
The original project manager on the Fiat project could not tell the difference between the two products and it was entirely cross-browser.
The point I am making here is that by writing the tool using semantic HTML and progressively enhancing the code with CSS and JavaScript, I was able to make something more accessible and more usable all at the same time.
My second key experience was joining a project that had a significant development effort behind it already. I was asked to point out where I thought the product was not usable. I found myself pointing out 8 areas that I had issue with. When I took a step back and looked at these comments I realised how each of them could also have appeared on a list of changes to make the product more accessible!
These experiences have really driven home for me how closely linked accessibility and usability are and how investing in one will inevitably be investment in the other. What a great selling point for spending more effort on these vital areas that are sometimes overlooked by clients.
This thought has been focussed almost solely around two tasks. The first of these was an interesting proposition - to demonstrate that projects previously completed using Flash could be built using JavaScript. As a useful by-product, I have been able to make some more use of JSquared and particularly my alpha build of FXSquared!
There were two particular products that I have been looking at, the first of which was a finance tool for Fiat. I spent 2 days working on this task and as such was only able to make part of this tool.
I started by building the dials which are the main control for the tool. This involved building a number of animations and some simple interactions. I then worked on the panel which flashes as the values change. Amazingly, in only two days, I was able to match all the functionality of the dials and get the values updating in the panel and get the panel to flash.
Accessibility was not an important consideration however, when reviewing the work I was able to complete, the markup I had written was valid and semantic and the product fully accessible. It was certainly no less usable than the Flash, and due to the keyboard being able to control the tools, it was perhaps more usable. It was accessible and worked without CSS and could be made to work without JavaScript very simply. It was a triumph.
The other product I worked on, was in a similar vein and was a similar success.
The original project manager on the Fiat project could not tell the difference between the two products and it was entirely cross-browser.
The point I am making here is that by writing the tool using semantic HTML and progressively enhancing the code with CSS and JavaScript, I was able to make something more accessible and more usable all at the same time.
My second key experience was joining a project that had a significant development effort behind it already. I was asked to point out where I thought the product was not usable. I found myself pointing out 8 areas that I had issue with. When I took a step back and looked at these comments I realised how each of them could also have appeared on a list of changes to make the product more accessible!
These experiences have really driven home for me how closely linked accessibility and usability are and how investing in one will inevitably be investment in the other. What a great selling point for spending more effort on these vital areas that are sometimes overlooked by clients.
8 April 2008
outline:0
There is nothing more annoying for those who wish to navigate a website using the keyboard than the extensive use of outline:0 in CSS code. For a more detailed explanation of what this is and what it means, I suggest you read this blog post.
Although I luckily do not suffer from any form of disability and do not actually require any effort to be made by a web developer towards accessibility, I do like to browse using the keyboard on occasion and this can be a highly frustrating problem.
CSS reset files such as the one mentioned in the post can leave developers without a full understanding of the nuances of the platform they are developing for. It is at least in part for this reason that I dont use a CSS reset at all.
My message to all would be to not remove this extremely useful and built-in behavior but actually to enhance it. Try navigation the London 2012 website with the keyboard (a site I led the development on) to see how nice it is to have the outline behaviour enhanced rather than removed.
Although I luckily do not suffer from any form of disability and do not actually require any effort to be made by a web developer towards accessibility, I do like to browse using the keyboard on occasion and this can be a highly frustrating problem.
CSS reset files such as the one mentioned in the post can leave developers without a full understanding of the nuances of the platform they are developing for. It is at least in part for this reason that I dont use a CSS reset at all.
My message to all would be to not remove this extremely useful and built-in behavior but actually to enhance it. Try navigation the London 2012 website with the keyboard (a site I led the development on) to see how nice it is to have the outline behaviour enhanced rather than removed.
14 December 2007
Its our job
I cant agree with absolutely everything in this article, but it certainly does make some very good points - accessibility should not be an inconvenience!
Subscribe to:
Comments (Atom)
Posts
