I’m going to go out on a limb now and talk about technical stuff that I don’t really know heaps about, but I think is really interesting for Information Architects and Interaction Designers. I hope that people of a more technical bent will chip in and correct any errors I make and fill in any gaps I’ve missed!
This post was inspired by what I think was the most intriguing presentation at the recent EuroIA conference in Berlin. This presentation was given by Steven Pemberton.
Now, Steven started his talk by breaking one of Kathy Sierra’s rules of presentations (don’t spend time telling people who you are and what you’ve done), but thank goodness he did, because I had no idea who he was or the amazing history that he has in shaping the web as we know it today.
Steven was sharing with a room full of Information Architects the joys of Xforms and XHTML2. A challenging task, given the range of backgrounds and expertise that Information Architects naturally have. Now… I know there were a few IAs with glazed over eyes, but for me… Steven’s talk held exciting prospects.
Let’s start with my take on Xforms.
Xform is short for XML Powered Web Form. The W3C says:
“XForms” is W3C’s name for a specification of Web forms that can be used with a wide variety of platforms including desktop computers, hand helds, information appliances, and even paper.
An XForms fan on the W3C website says that XForms are:
truly interactive, bi-directional Web of Applications, boosting structured interchange of information world-wide. This infrastructure standard significantly lowers development costs and total cost of ownership across all vertical, service and application-oriented web products – from e-commerce to e-goverment, e-finance to personal web communication.
So, in laymans terms (by my interpretation) what does this mean?
So, for example, address forms are only shown if the user indicates that they want or need to complete address details. If a form calls for partner/spouse information, these are only shown once a user indicates that they have a spouse or partner. So users only see the fields that they indicate they need to see. All users don’t have to see all forms.
Simpler forms. Less errors. Faster completion. All good.
How does this work technically? Well… unfortunately you’re at the wrong blog to work that out, but a quick look at Wikipedia (of course) shows you the downside that Steven didn’t really dwell on so much in his talk….
At the time of this writing, no widely used web browser supports XForms natively.
I don’t know much about Firefox 2.0 or IE 7.0, but from a quick review, it seems they’re into XForms. More’s the pity.
So why talk about Xforms?
Well… because they seem to me to be a great opportunity waiting to happen. And because if we don’t start talking about them and why we want/need them, then why will the browser manufacturers ever bother to support them?
Same, unfortunately, goes for XHTML2.
Steven’s talk got me all excited about the possibilities of XHTML2. It has a couple of key objectives including:
Less Presentation, More Structure – we all know that getting presentation OUT of HTML is a good idea
More Usability – for people who code, that is. Making HTML easier to write. That means making GOOD HTML easier to write. That’s a good idea.
More Accessibility – now, lots of people think that accessibility is boring or ‘out of scope for their target audience’ (that’s a whole other blog post). When Steven talks about accessibility he talks about ‘designing for our future selves’, when we all will have a shaky mouse hand and dodgy eyesight. Accessibility is boring whilst you’re young and agile, but you may live to regret thinking it too hard in the long term.
Better Internationalisation. Well… actually Steven says ‘internationalization’. I rest my case. (As an Australian this is a sore point, and there are sooooo many much worse off than I).
More device independence. Anyone who’s developed for multiple platforms would love this to be true… however, see above re: browser support, and then consider the nightmare that is mobile phones… even I think this may be optimistic. A great objective nonetheless.
Better Semantics. Now, this is the bit that I think is REALLY sexy :)
What does Better Semantics mean? Well, from what I understand it means that when I write ‘tomorrow’, it can actually mean 28 October 2006 without me spelling it out, and in a way that can be added to a calendar, or linked to other people’s ‘tomorrow’s’ that mean the same date, without me having to Google it and then link to ever single one. When I refer to a person, either by name or by a term like ‘the President of the United States’ I don’t need to explicitly explain who I’m talking about and then provide a link… but that potentially, all that additional information, or other information that I’ve already gathered, is available through that simple statement.
Now… even as I write that, I wonder how it would work. At this stage, I’m not inclined to trawl through the details, but the potential seems obvious.
As does the challenge for Information Architects. If we thought tags were problematic… then what kind of a challenge is this! How do we embrace the possibilities of a semantic version of HTML without unnecessarily constricting it OR compromising it through freedom? And, when and by whom are these semantic decisions made? By an IA, a designer or a coder?
Now, it’s completely possibly that I’ve entirely misintepreted both XForms and XHTML2. Afterall, you don’t come to this blog for the down and dirty on all things technical. But, based on what I heard from Steven, there are some interesting possibilities for the future that could be embraced sooner rather than later. And, no, this is nothing new. Afterall, Jeffrey Veen was lamenting XHTML2 and it’s lack of backward compatibility in 2003!
But I don’t live under a rock. And these things interest and potentially affect me. And I’ve not really heard much of them before.
I wonder if you’ve heard of/ been thinking of/ have an opinion on Xforms or XHTML2?
(And I very nervously hit Publish on a such-technically minded blog post… If I’m completely off base… I blame Steven. Or Berlin!)
So, I finally took some time to go back an review the state of the categories on my blog this weekend. All in all, it took me about 2 hours to get things to a state that I’m now reasonably happy with. No wonder I was putting it off… it wasn’t fun. Quite an exercise in acquiring RSI thanks to the category management interface that WordPress currently offers. But that aside…
In retrospect, I think it’s interesting that I didn’t approach this as I would a standard information architecture project. Perhaps that’s because I’ve been intimately involved with developing the content and gradually evolving the categories. For this reason, I think, it actually didn’t occur to me to approach this project methodically… which is strange. Perhaps the outcome would have been better if I had! Nonetheless, I did manage to cut the number of categories down from 29 to 19 (still too many, is my gut reaction), and that includes adding two new ones! There were a few name changes as well… some of which I’m happy with and some I think are still not quite right.
There were two types of categories that were retired. The first were categories that were just far too general, for example, I’ve had since almost the beginning a category called ‘Considering’. God knows what possessed me to create this category in the first place since everything on this blog is more or less considered. Interestingly, it’s a category that I’ve used consistently over the past 10 months of blogging… but it’s completely meaningless, so it had to go. There were others similar to this that were just too vague, so posts in this category have now been more specifically categorised and I think that most of my categories are reasonably specific now.
The other type that was retired were quite specific categories on topics that I thought I might blog more about, but that I actually didn’t. For example, I had a category specifically for typography… but that’s not turned out to be something that I write about much, so it’s gone. Similarly, right at the beginning of blogging, I’d post little reviews of books that I’d been reading on my commute to and from work. It turns out that my blog is quite focused now, and that stuff like that doesn’t really fit in… so those have moved into a ‘random’ category (I still need some freedom to blog about whatever I like!), and my ‘Bus Reading’ category is now retired.
It was an interesting exercise and I think that my categories now much better reflect what my blog is about, which for me, was a big reason for doing this (also that it was embarrassing that they were such a mess before!). But at the same time, I don’t get the feeling that people have ever really used the category navigation very much… and if they did, it was for some of the more obscure and colourfully named categories… for example, another recently retired category – ‘lusting’ (it wasn’t anywhere near as exciting as the name might suggest!)
So, although it’s been an interesting exercise to potter around my blog and put things into some kind of order…. I wonder at the end of the day if it actually makes a difference to anyone other than me!
I know, for me, that the only time I usually see a blog is the first time I visit it, or when I stop in to leave a comment. Other than that, I usually read what you’ve written in RSS format. So the only time I’d be likely to use your categories is when I first ‘meet’ your blog and am orienting myself with who you are and what you write about. From there I either subscribe or not.
Does this sound like your experience? When do you use categories on other people’s blogs? Do we actually need them? Or are they more for the benefit of the blogger than the bloggee?
OK. So I’m finally almost brave enough to send you in the direction of my very first ever podcast that I did for the Office 2.0 Podcast Jam. (Assuming you haven’t wandered over there and had a listen already.
I’ve been thinking a bit lately about this ‘cult of less‘ that 37 Signals seems to be leading and whether, in fact, it has an evil side. Well… ok, not an evil side. But is it all as good as it seems?
I started thinking this when I was listening to Peter Morville give the keynote at EuroIA the other weekend. He was pondering the ever increasing abundance of information that we have around us now, and wondering if it was helping us to learn, to make good decisions.
I wondered the same about information architecture and interaction design.
So, I’ve been thinking a bit about these web based project management solutions such as BaseCamp and GoPlan and thinking about what they *don’t* do when compared to more complex software such as Microsoft Project.
Now, don’t get me wrong… I’m not saying that there aren’t some *serious* problems with Microsoft Project but it was, for better or worse, instrumental in teaching me how to be a project manager. This is something that neither BaseCamp nor Go Plan could do.
Similarly, we’ve seen some interesting user testing lately that has shown users asking for more complexity to help enable their decision making.
So our natural response as designers, to simplify the interface, may in fact, be reducing the ability of the people using our software or websites to be able to learn, and to make good decisions.
So, that’s the crux of what I’m thinking of. What do we lose with ‘less’? And is it (always) worth it?
In agile development methodologies, pair programming is considered a key practice. Pair programming involves two programmers (in any combination of novice and/or expert) working together to write code. Advocates of agile methodologies outline a range of advantages of pair programming, and I’ve always thought that, in theory and as a relative outsider to the code writing process, it would be a great approach to development. I’ve never worked on a project where there was budget or resource available for pair programming though.
In the past 12 months or so, practitioners of the various design disciplines that I’m interested in have been talking more and more about agile methodologies and how they might apply to design processes. There’s been a lot of talk of collaborative design and rapid iteration, but I’ve not seen anyone talking much about ‘pair designing’.
In my experience, designing can often be a rather lonely activity. If you’re fortunate enough to be able to integrate real users into your design methodology then that can break it up a little. If you’re working within a team of other designers, perhaps you’ll be able to get them to review your work from time to time and give you some feedback. Working in a ‘pair design’ environment is, however, quite rare.
I’ve been fortunate enough to work on a few projects where we’ve taken a ‘pair design’ approach (in fact, I’m working on one right now), and I’ve been pleasantly surprised that the benefits that the agile advocates outline for pair programming largely hold true for pair design.
Increased discipline. Pairing partners are more likely to “do the right thing” and are less likely to take long breaks. Whilst I like to think that I ‘do the right thing’ when I’m designing solo, I have certainly found that working with another designer does heighten your focus on the task at hand and, even more importantly, lengthens the time that this level of focus can be maintained.I’ve also found that in pair design, you tend to design more away from the computer, instead using flip charts and pencil and paper, and post it notes stuck all over walls and drawings and user flows that you’ve mapped out on paper.This is good design practice but, even better, keeps you away from the distraction of email, and bloglines, and all the other kinds of distractions that you find on your computer. It keeps you focussed on the design process.This makes you design better, and makes you more efficient.
Better code. Pairing partners are less likely to go down ratholes and tend to come up with higher quality designs. I don’t know about ratholes… But I do know that when designing in pairs there tends to be a more rigorous approach taken to design decisions. This is because you have to be able to explain each decision you’re making, or design approach you’re taking AS you make it, not in retrospect. Each decision needs to be justifiable. And, because you have someone there designing with you, you get to actually discuss the benefits of each approach rather than just doing what you think is best (or worse… what you can do most easily in Visio because you have a template already set up that way…. Oh, come on. You know you’ve done it.)On the ‘going down ratholes’ issue though, if you happen to be designing with your client, then you are able to check really quickly whether the approach you’re taking has a hope in hell of being adopted by the client. This means that you don’t waste time designing something that will never be implemented, and that what you do design has a much better chance of adoption.On that note – designing with your client means that they understand the rationale behind every design decision. So, if you’re just a temporary resource on the project, you leave behind an evangelist for your design – again, making it more likely that what you’ve designed will actually survive the development phase.
Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working. For me, getting stuck into designing IS flow. But see above re: increased discipline and below re: less interruption. Both of those definitely mean you get lots more flow time, which is all good.
Improved morale. Pair programming can be more enjoyable for some engineers than programming alone.As I mentioned before, designing solo can be a lonely business. When you crack a really curly design problem, there’s no one to celebrate with… well, no one who really gets it. With pair design, you have a celebration partner. This is good :)
Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase.OK. This has been a little less relevant to me, as a consultant, but see above re: designing with your client and gaining and evangelist.
Mentoring. Everyone, even junior programmers, possess knowledge that others don’t. Pair programming is a painless way of spreading that knowledge. This is almost certainly true when you have an expert/novice pairing, but even when you have two designers with similar experience there is a lot to be learned.How often do you get to actually watch the process that other designers go through and how they approach their work? Not often, I’d guess. This is a great opportunity to say, ‘so hey, here’s how I do it… how would you do this?’ and pick up some handy new ideas or approaches or Visio tricks. (Hey, none of us know everything, do we!)
Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling. Yep. Pair designing is definitely a great icebreaker :)
Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.Now, this one is DEFINITELY true, and don’t underestimate how important this is. You can get an awful lot of design done in a couple of hours if that’s ALL that you’re doing. But how often do you actually get this much time to do nothing but the design you’re working on? In my case, not that often. Two people in a room makes you MUCH less interruptable!
One fewer workstation required. Since two people use one workstation, one fewer workstation is required, and therefore the extra workstation can be used for other purposes. Well, in our case we abandoned workstations all together and took over a small office/war room. So, I guess there have been a couple of free workstations!
Choosing the right co-designer is pretty important. I’d be loathe to pair design with someone who knew nothing about interaction design… it would be way too much mentoring and not enough designing, which isn’t practical or appropriate on a ‘project’ based design. i would however suggest that if you find a client who has people with the right skills, you do what you can to try to get them involved. This is much more likely if you’re applying other agile methods that involve rapid designing and iterating.Now, it would be unrealistic to suggest that pair design be adopted for all design projects, it’s never going to happen, and in many situations would be unnecessary.
But, if you do have the chance to work this kind of methodology into your project, then I’d encourage you to go for it. I think you’ll find it a very rewarding experience.
Have you experienced pair design? I’d be really interested to hear if you’ve had similarly good experiences, or if there are some horror stories out there!