boogdesign blog

Web design, web development, standards compliance, Linux, events I went to related to that, and random things I found on the internet.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now


12:26:46 am Permalink Links for March 14th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


12:49:16 am Permalink Links for March 7th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


03:28:04 pm Permalink Adventures in Web 3.0: Part 5 - The HTML5 Canvas Element

Categories: Front End Web Development, Standards, HTML and CSS

This weekend I came across Prez Jordan's post on Julia sets, I then followed the trail back to his original post on the Mandelbrot set. I've always loved fractals, since I read Gleick's Chaos back in school, and I used to spend hours generating Mandelbrot images on my Amiga when I should have been learning CS at University. I did at one point try to write my own Mandelbrot generator, but quickly got bogged down in trying to manage enough code to get a basic UI in Workbench and gave up and went to the pub.

Anyway, Prez's post stirred my memories and inspired me to once again try to put together my own Mandelbrot generator. Except this time, instead of having to manage OS libraries and indirect addressing in C just to open a window, I would take advantage of the HTML5 Canvas element:

The canvas element provides scripts with a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

Basically, canvas creates an area on your web page on which you can then draw lines, curves, images, and text with Javascript. It allows you to do some pretty crazy things, a lot of the more spectacular early HTML5 examples used it.

Adding a canvas to the page is very simple:

<canvas id="mandelbrot" width="320" height="240">A mandelbrot fractal will appear here.</canvas>

The content of the element will only appear if the user agent does not support canvas, it's similar to a noscript block. If your browser does have support, then all the content the user sees will be drawn on with Javascript. You'll notice I specified the width and height, if I left that out it would default to 300 pixels wide by 150 pixels high, which has an interesting side effect I'll discuss below, otherwise, it's much the same as any other element. It doesn't have much in the way of default styling, and it's an inline, rather than block level, element, but you can target it with CSS rules:

canvas { 
    -moz-box-shadow: rgb(0,0,0) 0px 2px 3px 3px; 
    -webkit-box-shadow: rgb(0,0,0) 0px 2px 4px; 
    box-shadow: rgb(0,0,0) 0px 2px 3px 3px;

So, we now have an empty rectangle with a nice drop shadow, how do we actually draw something? To draw on a canvas you need to get the context object, which in turn gives you access to all the drawing methods:

var canvas = document.getElementById('mandelbrot');
if (canvas.getContext){
    var ctx = canvas.getContext('2d');
    ctx.fillText('Hello World', 50, 50);

To draw a Mandelbrot we need to be able to plot single pixels across the whole element. There isn't a plot method, canvas isn't really intended for pixel by pixel manipulation, but we can pick a colour and plot a one pixel by one pixel rectangle:

var canvas = document.getElementById('mandelbrot');
if (canvas.getContext){
    var x=1, y=1;
    var ctx = canvas.getContext('2d');
    ctx.fillStyle = 'rgb(255,0,0)';

So now you know enough about the canvas element to write a Mandelbrot generator, for the rest we can just steal code off the internet &amp;#58;&amp;#41; Here's what we're aiming for (warning - don't click on the link on a slow computer, it'll take several seconds to render):

An image of the Mandelbrot set, generated in the canvas element with Javascript

Going back to Prez's post, his code is in Python, but it's fairly straightforward looking and easy enough to translate into Javascript. I took the Complex number library from "9.3.6. Example: Complex Numbers" of JavaScript: The Definitive Guide, 5th Edition and then used it to reimplement the Python function:

function mandel(c) {
    var cols = ["rgb(255,0,0)", "rgb(255,165,0)", "rgb(255,255,0)", "rgb(165,255,0)", "rgb(0,255,255)", "rgb(0,165,255)", "rgb(165,0,255)", "rgb(0,0,255)"];
    var z = new Complex(0,0);
    for (var i = 0; i <=20; i++) {
        z = Complex.add(Complex.multiply(z,z), c);
        if (z.magnitude() > 2) {return cols[i % cols.length]}
    return "rgb(0,0,0)";

The function returns a different colour based on how many iterations it takes for z to exceed 2 in magnitude when combined with the input value c in the formula z * z + c (if it doesn't exceed 2, then it is in the Mandelbrot set, and so it's black). The input value is the pixel position on our canvas element except translated into a complex number - where the x axis is the real component and the y axis the imaginary one - ctx.fillStyle = mandel(c);. Check the Wikipedia page for full details of how the Mandelbrot set works, I worked out most of the details through trial and error once I had it functional.

I mentioned the default size for a canvas element above, this is 300px by 150px. As an experiment I removed the width and height attributes from the element itself and set the size of the canvas in CSS:

canvas { 
    width: 45%;
    height: 45%;

You can view the results here (again, watch out if you have a slow computer). The browser renders the canvas, then scales the results to fit the CSS dimensions. So, if you want your canvas to take up a particular portion of the page (eg. half of it), you need to set the dimensions of the element with Javascript based on the pixel width of the page.

Moving on to Prez's second post, which inspired this whole adventure, where he looks at the Julia set. The Julia calculation is very similar to the Mandelbrot one, except instead of starting with z = 0 like the Mandelbrot it starts with z = t, where t is a complex number. The obvious place to get t is the existing plane of numbers on which we've drawn our Mandelbrot set. A canvas is an element like any other, so simply attach an onclick event to it and then work out the value of t from where the click event fired. Here's the Julia set for real 0.4249, i -0.2666:

An image of a Julia set, generated in the canvas element with Javascript

You can take a look at the final Canvas Mandelbrot/Julia Generator here. In performance terms, doing a calculation to render each individual pixel is a pathologically bad case for canvas - it's not something you'd normally do, you would make use of the higher level drawing controls instead. As it stands it does make an interesting performance comparator between browsers. I tested it in Firefox 3.6 (about 2 seconds to generate each image on my machine), Google Chrome 5 beta (about 1 second for each image) and Opera 10.50 (about half a second for each image), it ought to work in Safari too but I didn't try it. I did a version which used Explorer Canvas to try and see how long IE took, but it kept hitting the script timeout before it was even one third of the way through.

Tweet this!
2 feedbacks »PermalinkPermalink


12:13:58 am Permalink Links for February 28th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


12:19:20 am Permalink Links for February 21st

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


04:57:10 pm Permalink London Web Meetup: Accessibility in the Days of jQuery, Flash and AJAX

Categories: Usability & Accessibility, Front End Web Development

Review: London Web February: Accessibility in the Days of jQuery, Flash and AJAX at Wahoo Sports Bar, 14 Putney High St, Putney, London, SW15 1SL 19:30 to 21:30

This week, accessibility has been a bit of a theme for me, after LWS Inclusivity on Monday I was at the London Web Meetup on Accessibility on Thursday night.

To start with, Nathan gave a short presentation on HTML5 and CSS3. It was an introductory talk, so nothing new to me, but there was a very interesting open discussion afterwards. The focus was whether we'd even be able to use this fancy new HTML5 and CSS3 stuff while IE6 continued to account for 20% (or more) of the users of any given website. The Yahoo! home page still sees a huge number of IE6 visitors, and people who worked a lot with city clients said IE6 was still the default browser for many of their customers, the recent security scares do seem to have created an impetus for change among some of the banks. There was also some discussion about whether we even need to provide a pixel for pixel identical experience in every browser, or whether we needed to have the visual bells an whistles at all - apparently a front end engineer at Yahoo! Sports turned off all the rounded corners and showed the result to a designer and the designer couldn't spot the difference. My contribution to the discussion was that as more and more people use a mobile device to browse the web, and a lot of the browsers on those do support HTML5 and CSS3, you may be able to start using these much sooner if you're targeting these users.

After a short break we moved on to Artur Ortega's demonstration of screen readers and WAI-ARIA. Artur had JAWS, the leading commercial screen reading software, and NVDA, the free and open source alternative. He also mentioned Orca, the Gnome Linux based screen reader, and VoiceOver, which comes free with Mac OSX, including the iPhone version, which Artur used (this reminded me of Sandi's comment at the end of Monday's talk - including the tools in the operating system brings wider benefits).

Artur started off with a discussion of how the needs of screen reader users differed from fully sighted users. Although web pages are two dimensional, a screen reader sees them as a one dimensional audio track. This means a screen reader user needs 'timestops' if they are to navigate the page efficiently. These can be provided, in a well structured page, by headings - a screen reader can navigate from heading to heading with a keystroke without reading all the text in between. So the first simple improvement you can do to make your pages more accessible is make sure your page uses headings in appropriate places. Another small change which can make a big difference is to indicate language correctly with the lang attribute. This is very important in pages where multiple languages are likely to appear, such as search engine results. Currently, Yahoo! is the only search engine to do this - Artur demonstrated the huge difference it made to the screen reading experience, a set of multi-lingual search results became almost unintelligible when the screen reader was in the wrong language mode. Since search engines already work out the language of a particular page and expose that information, as evidenced by them providing 'translate this page' links in the results, this ought to be a simple change to make.

Next, Artur moved on to WAI-ARIA. ARIA is Accessibility for Rich Internet Applications, web apps with heavy use of Javascript and AJAX. For a general introduction see the W3C WAI-ARIA Overview, or More Accessible User Interfaces with ARIA which I attended in December. Support for ARIA is available in IE8 (there was some, but not much, support in IE7) and Firefox 3.0 (and up), when used with JAWS 10 or later (or recent releases of NVDA). Artur showed us ARIA landmarks and the aria-required attribute as well as, briefly, ARIA live regions.

There were a lot of questions all through the talk, so we had to cut it short at the end. I think many people, like myself, were totally in awe of Artur and his ability to navigate the web with a screen reader - especially when he demonstrated doing it at 'normal' speed near the end (he'd had it set to slow mode to give us a chance to keep up during the demos). I was inspired to spend a few hours the following morning implementing aria-required on a form in my web app at work &amp;#58;&amp;#41;

Another great event, 4 out of 5. I'm not sure a bar is the most comfortable environment for listening to a presentation, it seems that few in the London web community agree with me there, though. On the plus side, unlike most the events I attend this one was within ten minutes walk of where I work, so no need to be fighting my way through London rush hour to get there. The talks themselves, and the discussion afterwards, were excellent.

Technorati tags for this review:    

Tweet this!
Send feedback »PermalinkPermalink


05:57:30 pm Permalink London Web Standards: Inclusivity with Sandi Wassmer

Categories: Usability & Accessibility, Front End Web Development

Review: LWS February: Move over Web Accessibility, inclusivity is heading straight at you! at The Square Pig, 30 - 32 Procter Street, Holborn, London, WC1V 6NX 19:00 to 20:30

I'm always interested to learn more about accessibility so, after I enjoyed last month's LWS so much, this event was a must attend. As before, Jeff live-blogged the talk and I will be covering most of the same ground, but hopefully with a different enough emphasis and perspective to make this worth reading too.

Picture of the question and answer session at the end of the talk

Sandi started off here talk by discussing the need for the new term, 'inclusivity'. Accessibility has had a lot of powerful advocates in recent years but that has resulted in a somewhat negative image and a narrow approach. The need for accessible websites has been driven into people's conciousness, but not the underlying principles. Accessibility has become,"that thing you have to do to make disabled people happy." So to make people happy developers are resorting to a checklist approach which isn't actually benefiting users. Marketers fear that implementing accessibility will devalue the brand; designers fear it will limit their design options; developers worry that it will reduce functionality. In fact, accessibility, when done right, need not cause any of these issues.

Inclusivity is an effort to repackage accessibility with a more positive spin, by returning to first principles while combining with other elements of usability and remaining practical. The focus needn't be completely on screen reader users - only 3% of the UK's registered blind people are totally blind. Providing an alternate text only version of your website is not the same thing as having an accessible website, according to Sandi the aim of accessibility should be,"an unobtrusive bridge between myself and the world." Inclusive design allows people to have a choice in how they interact with your website. The pay off to taking an inclusive approach to design can be huge: there are 10.6 million registered disabled people in the UK, 19% of the working population is registered disabled and they represent approximately £80 billion in annual purchasing power.

Inclusive design is the embodiment of seven principals, it is:

  • Unbiased
  • Flexible
  • Straightforward
  • Clear
  • Sensible about errors
  • Minimises physical effort
  • Emphasises appropriate shape and size
To embrace inclusive design you also need to attack three assumptions:
  • Disabled vs Not disabled - People are people, disability is not a binary attribute, there is a range of abilities
  • Accessible vs Inaccessible - Accessibility is subjective, there is not such thing as an accessible site, sites will always be more or less accessible to different groups of users
  • Disabled people do not appreciate design - Anyone can have bad taste, this is orthogonal to their abilities in other areas

You might worry that you will never get accessibility 'right' - Sandi offers the advice,"just do your best." You just have to keep learning - accessibility is a process, not a finishing state - and you have to use that knowledge whenever you can.

Sandi then moved on to how the design process should be structured in order to take account of inclusivity:

  • The Brief should not be brief and should include a discussion of the principals of inclusivity.
  • The Plan should include user testing (with real users) and nominate an inclusivity champion.
  • The Functional Scope is where the real world will impinge, how much and what type of user testing does the budget allow?
  • The Technical Scope has everything nailed down, at this stage you just need to make sure everyone is communicating so that the overall goals are not compromised by a simple misunderstanding.
  • Learning, Designing, Testing, Tweaking and repeat as often as necessary (or you can afford).

Next Sandi discussed the relationship of inclusivity with web standards and best practices. The key misconception many people have about WCAG is that last letter - they are guidelines, not rules. The difference is that while rules are inflexible, they can only be complied with or not, guidelines are a relationship, they guide you on the way to discovering the best interface for your users.

Usability has much crossover with accessibility, though unlike accessibility there are no legal requirements to make your site usable. With usability you're asking yourself how specific users are going to accomplish specific goals in a certain context and evaluating your solution according to its effectiveness, efficiency and (user) satisfaction.

Web standards form the foundations of good accessibility, but they are just the beginning. Having your page pass the W3C validators doesn't guarantee it will be accessible.

The two most popular strategies for delivering good accessibility are progressive enhancement and graceful degradation. Sandi said that while progressive enhancement is a strategy, graceful degradation is an afterthought. Progressive enhancement is the way to go because it allows you to build your web site in layers and so make available a good experience to everyone.

Finally Sandi discussed why user testing is important, even if you have excellent market research and analytics. Consider three users: Peter, George and John. All are marketers in their mid-thirties, with 2.4 children and are demographically identical. They are all using Firefox on the same brand of computer, so are basically indistinguishable from the point of view of market demographics and browser identification data, however:

  • Peter is an internet lover, he's maxed out his browser with nearly every extension he could get his hands on
  • George is a luddite who only uses a browser because he needs it for work, he's turned Javascript off because he heard, some time ago, that it was dangerous to browse the web with it enabled
  • John is technically savvy, like Peter, but is visually impaired and so uses a screen reader

Clearly these three users have very different needs, and yet you're only going to see the difference between them if you do user testing.

After a wrap up, where Sandi re-iterated the need to always keep learning, we moved on to the question and answer session. There were a few questions which stood out for me:

  • Providing mobile access, is this accessibility, inclusivity or usability? - All of the above! Sandi's advice was to just try your best, not all content needs to be available on all devices. While the holy grail may be a site which is completely accessible on desktop and mobile, budgetary constraints will probably limit you before you get there.
  • How can we get the message of inclusivity to banks and other large and slow moving institutions? - Bring it to the mainstream, social change is hard work but it's the path to ultimate victory. Also, challenge people's stereotypes, don't let them think of a small number of completely blind people using screen readers, get them to think more broadly. One of the audience pointed out that one of the best business cases for accessibility had been at Legal & General. Also you should consider the people with the most power at these institutions tend to be older, and while they may not consider themselves disabled they are likely to suffer from impaired vision and other ailments simply due to old age making them a ready made market if you phrase things well.
  • What's the best way to develop an accessible website, where should your concentrate the effort, on semantic code? - A problem is that technology is always changing, and assistive technology doesn't always keep up, so you can't always provide the best solution now, and often the best solution now won't be the best in the future. This is why the WCAG is not about technical solutions but about guiding you to an understanding of your users.
  • Is there ever a place for exclusive design? - No, stuff is more usable when built for everyone. For instance the Mac accessibility tools built into the OS, now everyone can use them even if they don't consider themselves 'disabled'.
Another excellent event, 5 out of 5, I'll be watching out for the next one.
Technorati tags for this review:    

Tweet this!
1 feedback »PermalinkPermalink