Web Design — Page 5

Earlier today

January 31, 2002 by Michael Boyle

Earlier today

Ed quoted a post by Christina Wodtke referring to JJG‘s article:

I’ve always held that information architecture is architecture in the information space, and must embrace content architecture (a.k.a. little or narrow IA), interaction design and information/interface design, and the architects are those who practice and excel in those arts.

Christina goes on to say that, “a lack of thoughful […] architecture results in sites that are difficult to navigate, difficult to use, unprofitable, unrealized and generally stinky.”

I agree that is often the case, but I don’t think the solution either begins or ends with IA, whether referring to the practitioner or the discipline. I think it starts much earlier, which is what I was getting at earlier today.

Ed suggested that a web designer should be a part of the solution, and on that we agree, though I would underline that a web designer is not simply a graphic designer working in Photoshop. A web designer (I prefer “developer”) works with the graphics and the code, realizing the graphical concept she or he has come up with in working HTML/XHTML/CSS etc.

For me there are four equally important tasks to complete once a web project has been given the go-ahead. Design, IA, content (or editorial) definition, and application/DB development. Further, none of those tasks can be completed in a vacuum – the job of each relies on the work of the others. Hence, for instance, the person doing the content definition must know what happens in the code, at least superficially, and the apps people have to know about what the IA is going on about.

All of the tasks have to be completed to a high level of quality, of course, whether it is one person trying to do it or a team of 10.

There’s one other person that needs to be in the mix: the project manager, or as I say sometimes, the product manager. This person has to know the web, they have to have lived in it, and has probably filled at least one of the other roles at some point in their career. This person is the one who figures out (and documents) the initial strategy (in consultation with “the business”), and who works with whomever is necessary to research things before high-priced specialists are brought in to make it happen for real. The project manager, to me, isn’t just a process person, it’s fundamentally a bridge position between the business needs that form the reason for doing a project in the first place and the more techie folks who will develop the specific elements that become the finished product.

It seems to me that the heady days of the dot-com bubble introduced a lot of inefficient processes to the web world. Most importantly, maybe, was the introduction of the idea that the “boss” didn’t have to know what the “web folks” are actually doing day to day. For me, that’s the foundational problem behind why there are so many “generally stinky” sites out there. IA is important, for sure. As are the other roles in a web project (don’t get me started about how important it is to have a real “jack of all codes” technical lead when a project has moved into a more quotidian integration or maintenance phases). But those disparate tasks, usually completed by people who quite literally speak different languages, need to be brought together by a skilled and experienced person who has a good idea of what each of them is doing. It might be Information Architects who often get pulled into that role, but it’s not strictly an IA role that they’re filling. It’s a layer away from what I understand IAs (the required tasks) to do: it starts earlier, and it ends long after. Maybe never, as long as a site is alive.

Luckily for the field of IA, it’s just that kind of project manager who knows the value of IA people, and would only consent to developing a site without one under great pain!

Ummm, it’s about both

August 10, 2001 by Michael Boyle

. The Talking Moose waded out of the mud and into the fire with his piece yesterday. It’s the most ridiculous thing the Moose, who has otherwise been a very interesting read, has ever published.

The poor Moose clearly doesn’t understand what web designers, as opposed to code monkeys or integrators, do for a living. He seems to think they need or want to code every page or something inane like that. On personal sites that may be true, but that’s just for fun.

You can’t do content management properly – or even do it at all – without a damn good designer figuring out how to make it look, and with a damn good coder to make that design work with the content management system, and without a damn good architect to make sure that it fits together well through time.

I’m just old school enough to think that all of those roles – designer, coder, and architect – are best done by a single person. But none of those interests are antithetical to using a content management system to actually make it all happen on a day-to-day basis. In fact, a CMS can’t be implemented efficiently unless those folks do good work first – otherwise, the benefit of the CMS is lost in a miasma of snippets and included code and exception-fixing.

Of course the irony is that the Talking Moose site itself is a good example of this fact. Bryan Bell couldn’t have casually changed the design of the Moose had his code (made up of HTML and CSS) not been clean and useful to begin with. Likewise, had Dave and the gang at Userland not built a weblog architecture whose function enabled the weblog form (with the calendar-based navigation etc.), Bell’s work would have been useless. And the “design” (defined strictly) would be a secondary concern had both of those things not been done well for the task at hand.

It’s absolutely about design and the kind of work people like Zeldman do and it’s all about integrating content management systems as closely as possible to the writers and other “content people” who are doing the publishing. There’s no fight here, though the Moose seems to have wanted to stir one up.

I came across

May 30, 2001 by Michael Boyle

Jon Udell’s Telling A Story – The Weblog as a Project-Management Tool through calebos.org and CamWorld in the past couple of days, and as was the case with both of them, I found the article very compelling. I’ve frankly had enough of talking and thinking about grand schemes of leveraging heavy tech in the service of getting things done. It’s far preferable, to me, to bring things to the basic level: email and a simple website. Much more than that is overkill, and mitigates against adoption of whatever tool is under consideration – which makes it (whatever “it” might be) a no-go. As the article says so clearly, the tools are secondary, and I will add, boring. It’s the work, and more importantly the people doing the work, that are important. And the quickest, easiest possible way to help that happen is the best way to try. That’s the hidden power of weblogs for personal publishing and in this context, I think.

Boy do I love

April 17, 2001 by Michael Boyle

the [electrotone] web design guide. [via Stewart, that thief]

I’m in the midst of some

February 26, 2001 by Michael Boyle

pretty big decisions – one involving starting up a consulting company with some colleagues, one involving moving to the other side of the table, figuratively speaking.

The latter brings up lots of questions though. People (designers, web developers) always complain about how clueless clients are. What if the client isn’t clueless? What if your client knows exactly what can and can’t be done, what the best approach would be, how much it should cost? What if you client has a long background in web design, web coding, content development for the web, and the like? What if I suggest that the code be done to (say) W3C standards – or at least pay attention to the current developments on that side of things?

Does that still look like a client you want to work for? Or is that still a nightmare client? I’d let you do your thing – but cut a corner, and I’ll see it. I’ll look at the code and expect it to be professionally done. Still a good client?

A fear I have is that although clueless clients are a horror, so might clued-in clients be to many web designers and web developers. Can you deal with someone who knows his stuff?