In this weeks show we talk to Jackson Wilkinson about Agile and answer your questions on web design courses and showing off development work.
News and events
The Target accessibility settlement
Previous we reported that the retail chain Target was being taken to court over the inaccessibility of its site. Many hoped this would be a landmark case that would clarify whether the Americans with Disabilities Act applied to the web. As with the Disability Discrimination Act in the UK the wording is open to interpretation.
Well after 2 years of legal battle Target has agreed to pay $6 million in compensation and correct the accessibility problems on the site by February 2009.
Some are complaining that the case has failed to achieve all it could. They argue that although $6 million sounds like a lot of money it is small change for Target. What is more, they argue, Target has admitted no ‘wrongdoing’ and the case has done nothing to clarify the law.
These are legitimate points but I prefer to take a more positive view. This has been a significant embarrassment for Target and although $6 million is a small figure it is substantially more than they would have paid to address the problem from the start.
Finally, as Matt May points out on the WaSP website, this case may not clarify the law, but that does not matter. As web designers, our role should be to educate clients about the importance of accessibility rather than campaign for tighter legislation. In my opinion the benefits of accessibility are considerable and if presented correctly do not need laws to enforce them.
Long live IE8. Goodbye IE6?
This week saw the release of IE8 Beta 2 and I have to say that things are looking good. Quirksmode says it is shaping up nicely and Sitepoint has even asked whether web designers will switch from Firefox back to IE (the overwhelming answer was no!).
If you build websites and have yet to take a good look at IE8 then now is the time. I suggest you start with Microsoft’s own ‘readiness’ documentation for developers. This talks about all of the new functionality. You may also want to look at their separate documentation which lists the new CSS properties supported.
As IE8 teeters on the brink of release there is a growing movement to stop support IE6. With 37Signals, MobileMe and now even Facebook effectively dropping support for IE6 it would seem the tide is turning. There is even now a site dedicated to the demise of IE6. On it the author writes…
Internet Explorer 6 will be SEVEN years old on August 27th. It came out a few weeks before the Twin Towers fell. It came out before the Nintendo GameCube. It came out before the first iPod.
Makes you think doesn’t it.
OS form elements
Paul Stanton sent me a link this week to a great tool for you designers out there.
When I am working on a design for a site in Photoshop, one pain in the ass is creating form elements. You have to open a browser, find the form element you want, screen grab it and then edit it to remove all of the background elements. Its not a big job but it is annoying.
If I had any sense I would keep a library of all these form elements. However, somehow I have never gotten around to it. Fortunately I don’t have to now as there is a great site which provides them all for me.
The site is called the Designers Toolbox and includes web form elements for IE, Firefox and Safari under both Windows and Mac. They can be downloaded in PSD format and even include browser windows at various resolutions.
Blogging software reviewed
Finally, it wouldn’t be boagworld if we didn’t plug at least one Smashing Magazine story each week. Damn them and their compelling content!
This week they have published a review of 10 blogging applications including…
- Movable Type
- Nucleus CMS
The subject of blogging software, or content management systems in general, is a controversial one. This post alone has generated 137 comments, mainly consisting of people promoting their own personal preference. People are passionate about the system they use and often it can be hard to get a balanced evaluation. This makes selecting a system that is right for you difficult.
This post does a fair job at providing some subjectivity to the discussion. It addresses the pros and cons of each system and indicates the kind of site the system would be best suited for.
It is not a comprehensive guide, but is useful if you want to see what is out there.
Interview: Jackson Wilkinson on Agile
Paul Boag: So I’m pleased to have joining me today Jackson Wilkinson. Good to have you on the show.
Jackson Wilkinson: How’s it going Paul.
Paul Boag: Very well indeed. Just for those people that don’t know of you can you kind of give people a little bit of background so that they kind of know the angle you’re coming at things.
Jackson Wilkinson: Sure. I’m a user experience strategist at Viget Labs which is outside of Washington DC in the US. We’re essentially a full service web consulting shop. As a company we do design and development mainly in Ruby on Rails. We also do sort of the pre-product, pre-development strategy, that’s a lot of what I am involved in. We also do marketing. So specifically I attack working on the web from that angle of improving and setting the user experience at a product level before hand and then usering it in to usually the design phase after that. I tend to dabble in a lot of things. I was formerly a developer and have also been a designer here and there and try to keep my hands dirty in a lot of different areas.
Paul Boag: Cool. So I mean the reason we’ve got you in to talk today is to talk a little bit about the idea of agile developement. Particularly how it kind of applies not to the developer side of things that a lot of other people have talked about but you know to the design side of things, to the design community. But before we get into that let’s take a step back and start off by explaining to those that don’t know what agile development is. Could you kind of give us a potted summary of agile development.
Jackson Wilkinson: Sure. I think the short form answer to that is that, agile is basically a process for software development, typically software development, that is the opposite of your typical waterfall process where you have this big planning stage up front. You decide what every screen’s gonna look like. You decide how every feature is going to act and so on an so forth. Instead the agile proccess focusses on short rapid bursts of development which are usually called iterations, and essentially you’ll work on your product for somewhere between two and four weeks at a time implementing little bits of functionality so that you have a completed product every two weeks or so. The idea is that you’re able to adapt to change. You know if you decide that requirements need to change two months into the project that’s not a big deal because it only affects this two to four week period of development. You don’t have to go back and redo everything that you’ve already done. I think that’s pretty much the short form version there.
Paul Boag: Okay. That’s good. So in what kind of projects is this normally used on? You mentioned software development but what other kind of things?
Jackson Wilkinson: Well the proving ground so far, agile’s pretty new in so far as development processes can be new. It’s proving ground has largely been on the web. So web apps and web products have really been the biggest place where agile has been used but that’s not to say that that’s the only place where it has been or where it could be. Many larger products, many end user pieces of software. Largley ones that affect developers or that affect designers have been used and have been developed in an agile way. Definitly if you’re thinking sort of the 80/20 rule the vast majority of agile development has sort of been on the web for web apps. That tends to push those boundaries anyway, that web industry.
Paul Boag: So this has been, this can be used on larger projects? It’s not limited to smaller more self contained things then?
Jackson Wilkinson: Sure it certainly can be used on larger projects. It really depends on the structure and the climate at the development shop where this is happening. If you’re a really large shop that has lots of beauracracy and lots of stake holders and your client needs to get approval from 5 different places then this notion of quickly changing rapid development, quickly developing specs and the rapid pace of development is probably not as conducive. But when you’re in an evironment that has senior level developers who have a lot of autonomy and everybody tends to trust each other to roll with the punches, or you just have a lot of trust in your entire team then an agile process can work on any kind of software. Whether it’s a two month project or a two year project.
Paul Boag: Interesting. I mean from what I’ve heard of agile development before it’s a technique that’s growing in popularity amongst developers. You seem to think that some of the elements of agile development can be applied to designer’s as well. Tell us a little bit about that.
Jackson Wilkinson: The main reason why I’ve been thinking about this lately and why a lot of others have been thinking about this lately is that certainly as developers work on web apps they interface with designers a lot. If you’ve got this notion of a two week iteration then, maybe an example of an iteration might be that you’re working on a sign up process or you’re working on a registration process for one iteration. Then you go on to, you know if you’re making a social network for quilters, then you’ll add in social networking features after that or something along those lines. If you’re only constraining your work to those two week batches then often times the designers will be basically in this position that they will be forced to hustle to meet the development schedule. That’s not necessarily conducive to the design process as we normally think about the design process. That’s kind of how I came to thinking on this topic and how a few others have as well. The challenge really is to take some of those elemental notions of the agile process and to try to shape the design process around them so you can best use them to your advantage. A lot of times that means if you’re a user experience type of person or an information architect you’re planning process probably won’t be 4 to 6 weeks long or even longer with lots of user interviews. Instead you’re focussing on the law of diminishing returns where you’re talking to a couple users and getting there feedback and doing a little work on some interfaces and testing them out and moving on from there or as a designer you’re working on 5 or 6 screens at a time. Sort of in the silo of what’s going to be happening on the next iteration and then those get implemented. As you see what’s worked you constantly are improving your interface and improving your design as you see these things implemented. You’re in fact taking feedback from what’s already happened and using that feedback either from internal users or external user tests or even just what the developer’s and your friends and other designers are saying about it as it gets implemented. You’re pushing that back into your own process to in fact build a better product for the next iteration and do a better job there.
Paul Boag: How does that work from a kind of, you know the broad overview point of view? You know, as somebody that’s designed interfaces for fairly large and complex sites that would go beyond the two or three week or whatever cycle. You do so many different things with the different templates that you produce. What you do on one set of screens may affect what you do on another set of screens further down the line. If you’re working on all the individual iterations or silo’s of work is there not a danger that problems get ignored because they’re outside of the current cycle of development? Is that making sense?
Jackson Wilkinson: Well that certainly makes sense. That’s a challenge that a lot of folks new to the actual process experience where your essentially thinking we’re done with this piece of the product we’re totally going to ignore it from now on. That’s really one misconception and mistake a lot of folks make. Instead you should be thinking that part of each iteration is going to be addressing observations and addressing things you’ve discovered about the work you’ve already done. You’re third iteration is probably largely based on developing new features or developing new parts of your application. At the same time you’re going back and making tweaks and making changes to the work that you did in your first and second iteration based on testing or things that you’ve discovered about it or changes you have to make based on things that you know now that you didn’t know then. That way it definitly keeps everything moving. It keeps the whole product getting better at the same time.
Paul Boag: But isn’t that end up requiring a lot of re-work? You know you kind of are constantly doing things over and over again?
Jackson Wilkinson: Ideally it doesn’t require that much re-work no more than you would spend that time in a waterfall process determining what exactly you want in the first place. Certainly the agile process kind of comes with this belief that mistakes aren’t necissarily a bad thing and that you kind of embrace the notion that you may be wrong but you embrace that notion thinking that you’re going to be quickly making decisions and quickly making your best judgements about something based on what you already know. The time that you’ve saved by quickly making those judgements will completely of set and hopeful you’ll still be in the black when you have make a couple of changes down the line.
Paul Boag: So it’s basically doing away with the laborous documentation and the specing up of a project at the beginning and okay you loose some of that when you have to then re-work stuff but overall you end up, as you say, in the black.
Jackson Wilkinson: That’s the idea. That’s the hope. It seems to work out pretty well for us. It doesn’t always work with every type of client or every type of project. If it’s a client who isn’t a really adaptable to change on a regular basis or something like that. The notion that you’re not going to have this big spec doc up front may be a little unsettling for them but hopefully on an agile team you have a client, whether it’s internal or external client, that is buying into your expertise and really trusts your process and knows that your going to end up with really what works best in the end.
Paul Boag: There are differences between how this process applies to a designer rather than a developer. Are there changes and tweaks that need to be made?
Jackson Wilkinson: Yeah. In the end changes and tweaks tend to happen pretty equally to both the development of the site and the design of the site. Essentially if you’re a designer who is taking responsibility for the entirety of the interface and you’re designing that inteface completely, then you’re going to basically be making changes that could affect the developers as well. That’s something that designers need to keep in mind. They need to work very closely with developers to understand what the changes that they’re suggesting imply and really you make changes based on the time available in this iteration and what really is going to be most effective to change in the time you have available to you.
Paul Boag: So you have to be quite strict about these time scales from the sound of it? You were saying there that you only make the changes that you can within the current iteration before you deadline runs out. Am I understanding that correctly?
Jackson Wilkinson: Yeah, one of the biggest challenges there is knowing what size changes you want to bite off of this project. So you’ll have this mountain of changes that you eventually want to make and a lot of the project management involved is figuring out what you’re going to place in the next iteration. Doing as much work as you can on those bits and then reassessing at the end and hopefully having a new product or a new potential release, even if it’s not quite ready for release, a potential release finished at the end of that end of that two week block to evaluate everything you know at that point.
Paul Boag: I mean I can imagine there’s a lot of people listening to this that may be a little bit nervous about the idea. They’ve come from a very kind of waterfall driven mentality, where you know you pass things from one person to another. On the other hand they concede the potential in it and are maybe interested in finding out a little bit more. Where do suggest people start if they want to experiment with agile development? How do you do begin?
Jackson Wilkinson: Well I think that capital A agile proponents would probably say that you really need to dive in. I’m not sure that I buy that. I’m more perhaps a post-agilist, in thinking that you really need to just do what works. What works for you might be different than what works for somebody else. If you’re really ingrained in a process that has a lot of aspects of waterfall, has a lot of upfront planning, then you know you still can do a lot of the agile things to dip your toe in. The first thing that I might suggest doing is that even if you have a long planning process upfront where you determine the full scope of work. You determine even many of the streams and many of the design elements that are going to be implemented. Still break those goals up into two to four week iterations. At that point you still have the comfort of the planning that you’ve done ahead. If you concentrate on creating a self-supporting product within two or three weeks then you’re half way along that train. You can see how that goes. You’ll probably find that after you’ve gone through a couple iterations you’re thinking about things you’d want to change back in the planning section. That then maybe that’s okay at that point. You’re realizing how this self driven process works. As you become more and more comfortable then take away some parts of the planning. Maybe put the visual design to be a piece of the iterative structure while you’re still maintaining the feature scoping and the wire framing up at the front end of the project. Dip your toe in it first and then your whole foot and then maybe eventually you’ll be in up to your waist.
Paul Boag: So mean there must be resources out there? Lets send people away from this interview with something constructive to do. Where should they be going to learn more about this? What’s the next step they can take?
Jackson Wilkinson: Sure. If you’re a designer there isn’t necissarily a lot that addresses agile in the design case right now. Most of the agile books and the agile resources that you’ll find tend to deal mostly with a strict development structure. Certainly if you’re simply interested in looking at things and what the agile process is in general then you can look for books that deal with extreme programming or agile. You’ll find countless numbers of them. I’ll certainly give a list to you Paul so you can put them on the website afterward. Beyond that there are a few websites that deal with the agile design process. Emily Chang wrote a post call the agile web design manifesto. It’s a couple years old now but most of the concepts still remain. Where you’re kind of marrying this notion of design with agile development. She offers some good suggestions and especially the comments that follow her post are super useful to look through. If you’re involvedin IXDA which is an interaction design group. There are numerous discussion’s on there mailing list about how agile processes fit in to. The whole notion of the message boards is probably a good source in this case. I’ll certainly be happy to forward along a list for everybody to check out.
Paul Boag: Excellent. Thank you very much for your time. That’s really interesting. We’ve kind of touched on agile development very lightly on a number of occasions but we haven’t really looked at it in any kind of depth I guess, or kind of broken down what it is and how it works. It’s great to have you on show. Thank you so much for your time and I look forward to looking through that list.
Jackson Wilkinson: Yeah. Absolutely thanks for having me. I really enjoyed it.
Thanks goes to Curtis McHale for transcribing this interview.
Courses on web design
Jonathan asks: I am looking to get into web design and was wondering if there are any colleges or courses you could suggest. However, I do not have any A Levels.
I get questions like this fairly often, but tend to avoid them for two reasons. First, I went to college 15 years ago and so am out of touch with what is available (web design courses didn’t even exist!). Second, this is a country specific question, as nations have different educational systems.
However, because it is a popular question I will address it. There is certainly some generic advice I can give:
- Look for practical courses – I did two courses between school and work. The first was a BTEC and the second a degree. Although the degree was supposed to be a more advanced course, the btec was far more useful. That was because it taught me hands on skills that I still use. My degree on the other hand was very academic and abstract. Where possible choose a vocational course.
- Focus on web design – I receive a lot of CVs from people with computer science or art degrees. This tells me two things. First, when they selected their course they didn’t know specifically what career they wanted. Second, that if I hire them I have to train them. I would prefer somebody who specifically wants to be a web designer and already has a good grounding in the basics.
- Consider an apprentice scheme – If you have not performed well in the education system, consider an apprentice scheme instead. You will learn considerably more working for a web design company than doing an academic course. You will also get paid at the same time! Even if you cannot find an apprentice course in your country there is nothing to stop you arranging this yourself. Find a friendly web design agency willing to take on a trainee and also attend a part time or evening course.
- Learn business skills – Web design is not just about design and development. You need to understand business principles as well. You will be required to manage your time and potentially other people. Also, if you decide to become a freelancer you will need to understand sales, marketing, tax, invoicing and many other aspects of business management.
Showing off development work
Teifion asks: As a designer you can show off your work in a portfolio. As a programmer I cannot. What is the best way for developers to show off their work?
There is no doubt that it is harder for a developer to demonstrate his skills than a designer. However, it is not impossible. Let me suggest 4 approaches you could use:
- Sandbox – Have an area of your site where you build prototypes of functionality. It is a chance for you to experiment and show off your skills. Even large organisations take this approach. For example Google Labs showcases development projects which are far from finished.
- Blog – A blog gives you a chance to expose some of the code that lies behind your work. It also demonstrate your knowledge and techniques. Many developers shy away from documenting their work in this way. However, it is an effective promotional tool when seeking employment.
- Case studies – If a blog feels too much like an ongoing commitment consider writing occasional case studies. This works especially well if you have commercial work to showcase. A case study should not only demonstrate your coding skills, but also your ability to interpret a brief and formulate a solution.
- Screencasts – If writing fills you with dread, why not produce a series of screencasts. Screencasts allow you to show your code in action. You can demonstrate work and also show the process used to develop that approach.
You should not limit yourself to just one of the options above. Ideally look to combine approaches to effectively communicate your coding ability.