Slashdot Mirror


Web ReDesign: Workflow that Works

Steve MacLaughlin wrote this review of Web ReDesign: Workflow that Works , a book which transcends its title to address much more than workflow, and more generally than just on the Web. Steve promises that your copy will soon be tattered and marked -- and that's a good thing. Web ReDesign: Workflow that Works author Kelly Goto & Emily Cotler pages 253 publisher New Riders Publishing rating 9 reviewer Steve MacLaughlin ISBN 0735710627 summary Practical wisdom for Web creators on consulting, design, development and more rolled into a single readable volume.

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!

7 of 129 comments (clear)

  1. Play it again Sam by jsin · · Score: 5, Interesting

    I think it's funny that we think our problems as web developers are new. It is easy to parallel the problems we have writing software with any other industry that involves engineering and marketing, how arrogant of us to beleive that we are any different.

    I suggest picking up any systems design and analysis book from the '70s for starters if you're looking for guidance as a developer, and if you need a bigger-picture view, read up on the industrial revolution.

    1. Re:Play it again Sam by EnderWiggnz · · Score: 4, Interesting

      one of the biggest problems in commercial software development is the idea that your group is the first ones to come across this particular problem, and that you have to weave your solution out of whole cloth.

      the programming field has left its "arts" phase a long time ago - as in - everything is new, so everything is a work of art. This is when most software people were graduating with Computer Arts degrees.

      It is currently at the end of its "scientific" phase, computer science degrees are the norm. This basically means that we are able to repeat what we're doing, and are beginning to make processes out of it, and to make some solid foundations.

      The next phase will be an engineering phase, where we refine the scientific techniques to be finely, highly efficient production processes.

      at least, i think...

      --
      ... hi bingo ...
    2. Re:Play it again Sam by fusiongyro · · Score: 3, Interesting

      A couple things about your argument...

      The next phase will be an engineering phase, where we refine the scientific techniques to be finely, highly efficient production processes.

      This was basically Bertrand Meyer's argument in Object Oriented Software Construction. Because object-oriented software lets us make everything into components, soon everything will already be implemented in these components, and then we'll have nothing but catalogues of components. Making software that works will be a matter of selecting the proper objects from the huge set of existing objects, not writing new objects (except glue code, I suppose).

      One counter-argument to this is the fact that this paradigm never really took off. Even now, with COM, COM+, CORBA, XPCOM, Kparts, etc. the complexity of large scale reusability is such a large barrier, people would rather reimplement the stuff. The good CORBA book is larger than The C++ Programming Language. This is not a win for small developers, learning developers, or hobbyist developers.

      Secondly, think about the personality types that are attracted to a given profession. Granted, computer science proper is mostly mathematical. But coders, developers, BS degree-bearing computer scientists, and information technology majors are not engineering types. If you've heard of the Meyers-Briggs test, you might notice that programmers and their ilk are all *highly* intuitive people. Engineers are not intuitive, they are much heavier on the logic side of things. I don't see this changing anytime soon.

      Third, I just don't see the early days of computer science as being very artsy. Most computer science programs today sprang from mathematics programs yesterday, barring a few strange exceptions like CMU. Fortran and assembly are not exactly expressive languages. Lisp is, and there is still a coterie of functional Lisp/Schemers out there.

      Algorithms tend to be conjured up in the dark via black magic or intuition. How did C. A. R. Hoare invent Quicksort? There's no formula for making algorithms. But by the same token--if it were artistic, there would be more than the rather small number of sorting algorithms we have.

      Plus, if you track programming languages, we seem to be tending towards more expressive languages and less towards stricter languages. FORTRAN has a lot of bizarre limitations, but as we all know, Perl will try very hard to execute line noise. Modern languages are starting to support function currying again, bringing us back to the Y-combinator and other idols of functional programming. We're in the midst of a bit of a strange renaissance with dozens of usable operating systems and hundreds of languages. Ever heard of CHILL? Every installation of GCC on Linux compiles four languages: C, C++, Objective C and Chill.

      If this is getting a bit fuzzy, compare it to the trends in music of late. In the beginning, there was classical music, which was composed by many but only geniuses are truly remembered for it. This was the case for an extremely long time, compared to the trends of just the past 50 years. Then, with the advent of rock and roll, everything we used to know is thrown out of the window. But I could make a very good argument that since the 50's, there have been alternating periods of individualism versus genre-ism, stagnation versus creation, and combination versus invention. Take the 50's: there was basically one sound, and everybody was doing it. The 60's roll around, and suddenly rock is moving in a million directions again. The name of the group or the genre becomes more important than the person behind it. Then, in the 70's, we return to the persistance of a few simple genres with the name of the individuals being more important. Singer/songwriters and so forth.

      The essential problem with taking this perspective on either computing or music, is that it doesn't take into account the exponential increase in the amount of producers and consumers of the product (be it music or information technology). If I try and sell you my alternating-decade theory of musical progress, what was the dominant music form in the 90's? For that matter, what programming environment is most prevalent today? You're tempted to say object-oriented, but what fraction of GNU/BSD applications are actually written in something besides C? At my school, exactly one course teaches you object-oriented principles in the computer science department, and it is the survey of programming languages class. However, the new IT program certainly takes it into account more. But which programming languages are actually the most prevalent these days? About the only thing you can do is rank them in order of usage:

      Structured (C) > Object-Oriented (Python) > Functional (Lisp) > Logical (PROLOG)

      Computing no longer is centralized enough to have a single ideology. There is no process going on which is holding computer science to anyone's prediction anymore.

  2. Book's web site fails to validate as standard HTML by peter+hoffman · · Score: 3, Interesting

    The companion web site of the book (at www.web-redesign.com) fails to validate as standard HTML when tested by validator.w3.org. What else needs to be said?

  3. Web Professional? by imrdkl · · Score: 1, Interesting
    Isn't that an oxymoron? I mean, aren't lots of these folks now back in school, perhaps learning about what happens on the other 1023 priveleged ports?

    I dont mean to slight anyone, but hasn't enough hype been published, fortunes lost, BMW's repo'd, and trees killed for this kind of thing to loose it's glitter yet? Sheesh, if not, drop by my house and I'll let you pick from my dusty, unused, and outdated-after-one-week library.

  4. Comment removed by account_deleted · · Score: 4, Interesting

    Comment removed based on user account deletion

  5. Don't under estimate the value... by kpooley · · Score: 2, Interesting

    Don't under estimate the value of having the simple processes laid out. We tend to take for granted that a well designed software dev. cycle will turn out well designed software. But often management has no clue. On one hand books like this provide external validation of your insistance that a process be followed. On the other hand you also get a nice happy set up vocabulary/phrases and logic to use when convincing a client to stick to the track. I have always loved " Practical Software Requirements" but I have yet to work with anyone who will see requirements documentation through before they start plopping logos into fr-page along with 7 zillion add-on extensions which only work with v4.67123 of browser X.

    If nothing else this book appears, in the picture at least, to have that rare blend of surface area and heft which makes it perfect for wacking the pointy haired dweeb across the noggin...when all else fails.....