Slashdot Mirror
Web ReDesign: Workflow that Works
There are books that attempt to impart the divine wisdom of consulting. There are books that detail best practices in graphic and usability design. There are books that detail the intricacies of software development. There are books that detail project management and surviving the technology lifecycle. But there are very few books that explain how all of these pieces work together successfully. Kelly Goto and Emily Cotler have pulled it off with masterful perfection in their new book Web ReDesign: Workflow that Works.
People, projects, technology, and clients do not work in a vacuum from one another. Process is the magnet that holds them all together. Goto and Cotler offer professionals a comprehensive "Core Process" to guide them through their Web projects. While other books may explain some of the tricks of the trade no book has really placed all of these best practices under the umbrella of a process or methodology. Perhaps that's because a lot of these processes have been closely guarded secrets in the highly competitive interactive services industry. It's almost as if Goto and Cotler are on a humanitarian mission to save clients and projects from future punishment under the hands of companies using poor or in some cases no processes at all.
Web ReDesign's Core Process is a five-step approach to producing successful Web projects. The five steps are Defining the Project, Developing Site Structure, Visual Design & Testing, Production & QA, and Launch & Beyond. And each phase is broken down further into steps and checkpoints in splendid detail. As someone who started out doing this kind of work I found myself making mental checkmarks throughout the book. "Did that. Did something like that. Man, it took me years to learn that I should do that. Where was this book six years ago when I needed it?"
Perhaps a book like this wasn't really possible until now. The profession had to go through its ugly duckling stages where individuals and companies tried to figure out what worked and what didn't. Grafting parts from consulting, marketing, project management, and software development into some freakish process monster that often resulted in turning clients into an angry torch-carrying mob. Thankfully Web ReDesign has finally arrived and it is certainly no Bride of Frankenstein. The processes are spelled out in clear language and the authors repeat certain key points in case you missed something along the way.
It's easy to get sidetracked reading Web ReDesign with all the sidebars, charts, sample forms, and interviews. But this is a good thing! The tips and sidebars along the way spell out in greater detail how to put the process into action, and what to do when trouble arises. The forms and charts are some of the most thorough ever published, and thankfully you can download most of them on the companion website located at www.web-redesign.com. Throughout the book Goto and Cotler call on experts like Lynda Weinman, David Siegel, Jeffrey Zeldman, and Jakob Nielsen to offer their perspective on a given topic. The overall design and layout work done by the folks at New Riders is phenomenal and the visual presentation of the book is really first rate.
The one big question I have about the books is its title: Web ReDesign. That's because this is a book that can be used for first time Internet initiatives just as well as for redesign projects. Perhaps the authors had some dual purpose in mind for the title: If you're doing this for the first time, you need to rethink the conventional wisdom that Web projects are a black art with no best practices. Or if you didn't use a process the first time, then you've probably learned how valuable it is to have a proven methodology to avoid repeating mistakes.
Goto and Cotler have produced a book that no Web professional, whether they're a consultant, project manager, designer, programmer, or specialist, should be without. Web ReDesign is one of those books that should be kept close at hand during projects of all shapes and sizes. It won't take long before your copy is either severely dog-eared or has post-it flags sticking up throughout it. Get your hands on a copy before the competition does.
You can purchase this book at Fatbrain. Have your own book review to contribute? Check out the book review guidelines, then write away!
A far more insightful source is Ed Yourdon's books the Mythical Man Month, and Death March.
The sooner everyone, developers, management and consumers realise that to develop good software takes time, and money, the sooner we can all start to enjoy bug-free well written reliable software.
Until then, we are stuck with the 'good enough' model.
I agree.
I spent the last year trying to find solutions to the development problems we are having by reading many "modern" books about managing projects, the trade-offs between cost and quality, and the conflicts between the developer, manager and customer perspectives and while I did find several usefull books on particular aspects (code complete, the humane interface, etc), I struggled to find something that put universal meaning to the whole picture.
At this point I began to look outside of the industry and see if I could find parallels in other facets of business. Indeed, I didn't have to look far as my first shot (the automotive industry) was an almost perfect analogy.
If you look at the early days of the automobile, there were many companies who were strapping motors to horse-carts and selling this as a solution (simular to some of the first online shopping cart solutions). These vehicles were not very efficient or safe, and seldom out-performed what they were designed to replace (horses and steam-engines), but for the eccentric few who desired to be on the "cutting edge", they did the trick, and they did prove the concept.
The next step was to improve the device itself, improve reliabilty, performance, efficiency etc. This required more expertiese and refined the list of "manufacturers" to companies who had enough engineering expertise to understand the underlying principals involved (mechanics, power, etc) and make improvements at that level. This improved the device but conversely increased the expense beyond simply the cost of the parts. The next step was to engineer the "product".
The most significant event at this stage was Ford and the assembly line, which was able to make up for the up-front investment in engineering by reducing the cost of manufacturing.
After this stage we bounce between the engineering of the device and the engineering of the product, continually refining actual features and coming up with new ways to convince people they need to buy them.
This is where I beleive software is today. I think that consumers are generally smart enought to know the difference between a quality application and a cheap one, but are willing to settle based on cost (the reason you don't see duesenburgs anymore (I'm not sure about the spelling)).
second society
actually, his site (www.opensourcers.com) does validate as HTML 4.01 Transitional according to W3C