Slashdot Mirror


The Design of Sites, Second Edition

Joe Kauzlarich writes "The 'pattern' book has become a familiar genre for frequent readers of technical manuals. The idea is to sift through mountains of architectural or design schemes and then to categorize and catalogue the most frequent ideas and present their strengths and weaknesses. This type of book has been a success in software engineering, but can it translate to website design, where designers have everyday and frequent access to other designs? At worst, these books provide a common industry vocabulary (assuming it was read by everyone in the industry). How many people knew what a factory method referred to before Erich Gamma's Design Patterns was released? At best, as in the case of that 'original' software design patterns book, mountains of complex ideas are archived into a single reference and will sit within arm's reach for the rest of your life. So, is the web design discipline full of patterns that evade common sense?" Read below for the rest of Joe's review. The Design of Sites, Second Edition author Douglas K. Van Duyne; James A. Landay; Jason I. Hong pages 982 Pages publisher Prentice Hall rating 6/10 reviewer Joe Kauzlarich ISBN 0131345559 summary Catalogue of Website Design Patterns

Initially, I was amazed by the sheer scope and the amount of work that must've been put into this book. Almost 1000 pages — and not just a bunch of screenshots either. Most of the book is well-organized text. The screenshots are full-color, as is everything else in the book. Each section has a different-colored bleed, making it easy to locate the chapter you're looking for. Furthermore, the patterns are extensively cross-referenced throughout the book, and references appear in colored marginal bullets. Even the table of contents has descriptive section headings and a small summary of each section. The design of the book itself gets an eleven out of ten. The book itself is a living catalogue of technical reference design patterns. Kudos to the book's designer on this one.

As far as content, the book describes 117 distinct patterns in 13 categories. This includes patterns related to marginal topics such as mobile devices, accessibility and content creation (i.e. copywriting 101). Like most pattern books, it's a good idea to initially browse the book before using it as a reference so that you'll know what to look for when you need to pick it up again. On my initial browsing, it seemed to contain nothing particularly surprising — this has been the case with many great pattern books such as Martin Fowler's Refactoring or another of his books, Patterns of Enterprise Application Architecture, so I was not going to discredit it on this basis alone: a pattern book's true value shows itself when you're stuck on a problem and turn to it for a moment of shining clarity. Let's see if The Design of Sites lives up to this promise...

Trial #1: a business website that is not e-commerce, but a 'glorified yellow pages' type of site. I have a lot of information that needs to be accessed not only in its hierarchical organization, which can go to three levels deep, but should also guide the reader on what should be read next: a separate 'linked-list' that 'jumps' branches in the original hierarchy.

Given this amount of content and this double-organization, we wanted each page to present access to the site's information without overwhelming the reader. I open up the book to Part A, 'Site Genres', to locate the particular genre of website I'm working on. I find it: 'Valuable Company Sites.' I read some good information on layout. I see a paragraph titled 'other patterns to consider,' which points me to pattern B1, 'Multiple Ways to Navigate.' A-ha! The book's exceptional design allows me to locate pattern B1 in 3 seconds flat. It is hear I realize the true value of the book: there are no 'right' answers in design, only guidelines:

" ...we have identified two things that drive customers to action: intention and impulse (these can be thought of as goal and trigger, or need and desire). Neither intentional nor impulsive behavior is inherently good or bad, but a site that omits intention-based navigation might feel shallow and quirky, and one that omits impulse-based navigation might seem boring."

Good advice. Though I already have a hierarchical organization (intentional browsing) and recommended organization (impulse browsing), which gives users options on what to read next, I now have an idea of what sort of balance I want in the areas of navigation.

This was not exactly a mind-blowing discovery, but it did give me some confidence in the choices I eventually made and, furthermore, gave me valid reasons for making those choices, in case the client or a team-member were to question those choices later on.

Trial #2: Working on a website for a freelance graphic designer, I encounter a problem whereby each image in the portfolio can be categorized either by project/campaign or by design-type. For example, a logo, a business card, poster and website are all part of a single campaign, but we also want the ability to list all logos from separate campaigns. Again we have an organizational dilemma, but this time for a different type of site and a fundamentally different type of dilemma.

Again, I turn to the first section 'Site Genres' to locate the type of site I'm working on. It's not exactly a business site, but more of an on-line portfolio. The closest seems to be pattern A9, 'Stimulating Arts and Entertainment.' When I turn to it, I discover I was correct: the authors discuss the 'art gallery' site, though it doesn't exactly cover the aspect that I'm looking for. So I've encountered the book's first notable omission: nothing along the lines of an 'online portfolio' or 'interactive resume' genre of site design, which would encompass all creative freelancer sites as well as the usual rock band websites, etc. They differ from the 'Valuable Company Website' in that personal expression and design creativity take center stage. These sites have a general similarity in aesthetic in that they purposely avoid the business-like design. You won't see many pull-down or left-side navigation menus on a standard band website. The menus are typically integrated into a central graphic of some sort and this puts heavy constraints on the web designer while trying to effectively organize information without sacrificing the expressive purposes of the site.

The book offers no obvious guidelines for dealing with this sort of problem and here's why: it doesn't take into account the various constraints imposed by the client nor does it attempt to offer reconciliations between the design and the underlying organization of the data.

In my trial #2 we had the thumbnail images organized in two ways, either by design-type (poster, logo, business card) or by campaign ("Going Out of Business Sale", "Grand Opening", "Johnson's Automotive Website"), both organization-types having fairly equal weight. How do we allow the user to switch between organization types and keep the site consistent? The book doesn't touch these types of questions in a direct way.

The book offers a comprehensive aggregate of guidelines for user-interface patterns, User-centered, and 'psychological' perspectives. It covers most of the bases: content creation, page layout, organization of component elements, web application design, hints of 'Web 2.0' patterns, and ideas for functional pages such as searching, content submission, 'Marginal' topics like localization and accessibility that you may not want to buy a separate book for but, nonetheless, need to know about. It has a great overall design, easy to use as a reference and easy on the eyes, a long and detailed exposition on the utility of polling and seeking advice from your target audience, including sample forms to present them with. It is overall, very well-written and hardly a sentence wasted.

While 99% of the patterns themselves are common knowledge to most users of the internet and to most decent web designers, it is the expository text that forms the real meat of the book and contains the wealth of insight. This is by far the book's value. Posing as a patterns book is misleading; this book is really just a very good general guide to web design. As a pattern book, it's flawed, because almost every 'pattern' is just a guideline for effectively presenting information, not an elusive insight or 'trick of the trade' in itself, such what as Erich Gamma's (et al) original 'Design Patterns' brought us. There are mountains of outstanding tips and bits of advice throughout the book, but if you've already achieved a decent level of competency in design, then you're not going to be using the book very often and when you do, you might not get the depth of advice you're seeking.

On the other hand, the book gives beginner-to-intermediate-level designers everything they need to get started or fill in the gaps. The Design of Sites would also make an outstanding text book and is likely to be one of the best general guides to web design on the market.

I'll give it a 6 out of 10, judging a book on its utility as a design patterns books (just as you would give The Illiad a possible 2 out of 10 if Homer presented it to me as a historical text and I expected as much). As an introduction to web design, it easily deserves at least 9 points out of 10.

You can purchase The Design of Sites, Second Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

43 comments

  1. if you want insight into web page design... by AltGrendel · · Score: 4, Informative

    ...check out the web pages that suck web site. There's a lot of good advice there and who knows, your site may be listed there.

    --
    The simple truth is that interstellar distances will not fit into the human imagination

    - Douglas Adams

    1. Re:if you want insight into web page design... by BlueParrot · · Score: 1

      ...check out the web pages that suck web site. There's a lot of good advice there and who knows, your site may be listed there.
      Sure, but is there a way to nominate that site for having a completely broken DHTML interface with pointless animations? Also, if you are writing a page about other pages that suck, it should at least validate...
    2. Re:if you want insight into web page design... by JAS0NH0NG · · Score: 1

      Part of the reason we wrote our book The Design of Sites was in reaction to things like "web pages that suck." There's a lot of information out there about bad web sites, but not as many practical examples and details on how to create good ones.

    3. Re:if you want insight into web page design... by klenwell · · Score: 1

      Sure, but is there a way to nominate that site for having a completely broken DHTML interface with pointless animations? Also, if you are writing a page about other pages that suck, it should at least validate...

      Really, that site sucked enough itself that I didn't even have to look at any of the sites it listed.

      --
      Innovation makes enemies of all those who prospered under the old regime... -- Machiavelli
    4. Re:if you want insight into web page design... by AltGrendel · · Score: 1

      I case you haven't figured it out, it's deliberate.

      --
      The simple truth is that interstellar distances will not fit into the human imagination

      - Douglas Adams

    5. Re:if you want insight into web page design... by Doctor+Memory · · Score: 1

      Really? I've visited that site two or three times, and each time I got the impression that the site designer was a cranky ten-year-old that needed a nap. Sure, there are some seriously hurting web sites out there, but he's got so many little nitpicks that virtually no site with any content to speak of could pass as a "not sucky" site. And then he just throws out "Oh, this site doesn't pass the test either", like I should pay attention to somebody who points out other sites' flaws but can't be bothered to make his own site conform? Why not just admit that you don't know what makes a good site, can't design a good site yourself, and stop being an attention whore? Oh, right -- ad revenues. Never mind...

      --
      Just junk food for thought...
    6. Re:if you want insight into web page design... by Fallingcow · · Score: 1

      So, it's supposed to render with an error that appears to be the result of having a pair of divs that are too wide stuck in a fixed-width container, which causes everything under the header to render
      in
      a
      line
      down
      the
      page
      rather than side-by-side, causing the main content to appear outside of what I assume was meant to be its background and instead on a dark grey one that causes that black text to be nearly unreadable? And causes the footer copyright info to pop to a spot near the top of the page, next to the menu (which has displaced the content such that it follows it, mind you) which is in turn partially overlapping the header?

      Looking at the others, yeah, they suck, but I don't look at any of them and say, "hey, his code is broken!" Also, it lacks any mention of what is wrong with the page, unlike those other examples. The (apparently intended) design on the page I'm seeing isn't actually bad, it's just got broken CSS, I'm guessing.

    7. Re:if you want insight into web page design... by SamSim · · Score: 1

      Also, I don't know whether it's supposed to be ironic, but the site itself is an excellent example of a web page that sucks. I mean, look at the sidebar which descends a full screen further than the main content column, for example.

  2. Theres only one principle of web design : KISS by unity100 · · Score: 2, Informative

    Keep It Simple, Stupid - for those of you that still didnt know

  3. GoF is a classic, of course.... by tcopeland · · Score: 1

    ...but it's interesting to see Stu Halloway's thoughts on design patterns. I heard that he once gave a talk where he said something to the effect of "The 'Design Patterns' book should have been named 'Ways to Work Around C++ Language Limitations'".

    1. Re:GoF is a classic, of course.... by Bill+Dog · · Score: 1

      He must be either a dynamic typing zealot or a C++ hater. The GoF book, for those who don't know, has its examples in C++ and Smalltalk. I vaguely recall there being an occasional comment stating when one of either the class or object version of a pattern had an implementation in C++ but none was required in Smalltalk, due to its choice of typing approach.

      --
      Attention zealots and haters: 00100 00100
    2. Re:GoF is a classic, of course.... by kendor · · Score: 1
      I've found studying GoF-esque design patterns to be enormously useful for my learning, with two cavaets. First, the GoF book was NOT the best book for my learning, and I doubt it should be the first that people glom on to: more on this in a bit. Second, I rarely apply patterns directly.

      For me the study of design patterns could be named, "abstracting your programming: better and smarter" or "useful ways to think about programming" or "OO is not overrated: the right way to use the object oriented paradigm." The benefits of patterns are indirect but real: thinking about the patterns helps you think about your own work in different ways.

      The best patterns book I've found is the Design Patterns Explained by Shalloway and Trott. The second best book about patterns allegedly isn't about patterns but I think maybe it is: McConnell's magnificent Code Complete. Yet another great patterns-book-that-isn't-about-patterns-but sorta is is Beginning C# Objects: From Concepts to Code. I'd pick up any of these books before I picked up GoF again, but that may reflect where I'm at: maybe GoF requires l337 h4Axors ski11z to fully appreciate. I dunno: the discussion of the Bridge pattern in c4 or c5 of Design Patterns Explained seems as deep as anything to come out of the Gang of Four.

      My humble opinion is that design patterns that come out of OO and programming are fundamentally different than what designers (I am one) are trying to call "design patterns" these days. Web site design does express "patterns" but those patterns are fundamentally different than what is meant by "design patterns" in the land of programming. Methinks there is some confusion about what is meant in each case by "design" and "pattern," as well as a desire to pick up the buzzword de jour. Not convincing. -KF

    3. Re:GoF is a classic, of course.... by Nazlfrag · · Score: 2, Insightful

      The GoF wrote a terse and succinct technical manual. Most books don't contain such a density of concepts and information. There's not really enough examples given to make it all click together, so additional reading would be good. All of the books you recommend are excellent. I'd advise reading them alongside GoF though, not before. Additionally, find some code, real world implementations beat book examples any day.

  4. Patterns are 'best practices' by mikedeanklein · · Score: 1

    'Patterns'/best practices can be applied to anything...walking your dog, owning kids, etc.

    1. Re:Patterns are 'best practices' by Anonymous Coward · · Score: 0

      Owning kids?

    2. Re:Patterns are 'best practices' by Anonymous Coward · · Score: 0

      Owning kids?

      Some people never practiced enough to beat people their own age at Counter-Strike.
  5. step 1 by brunascle · · Score: 2, Insightful

    step 1: dont let web designers touch the HTML markup. their job belongs in the CSS file. all the designers should be doing to HTML is adding class= or wrapping stuff inside and tags.

    dont destroy the content just to to make it look pretty in IE.

    1. Re:step 1 by Anonymous Coward · · Score: 0

      I'd rather spend my time improving the website (or enjoying my free time) than trying to arbitrarily shoehorn a web design in to CSS.

      Keep it simple stupid.

    2. Re:step 1 by kiso · · Score: 2, Insightful

      unfortunately, this is not the case in the real world. you spend time writing a pure XHTML+CSS but: 1. The client wants eye-candy effects, look&feel or page design which cannot be implemented with pure XHTML+CSS. do some workarounds. 2. One of the popular browsers does not support one or more CSS selectors, do some workarounds (more often) so, unless the browsers stop interpreting the standards their own way, it's easier to come up with a quick & dirty HTML markup with tables and stuff, which will work and look as needed. the web browsers currently are too permissive - they try hard to render a lot of broken HTML+CSS which is spoiling. because they need to sell, need to dominate the market. make them all restrictive and people will start optimizing/rebuilding their pages.

    3. Re:step 1 by foniksonik · · Score: 1

      step 2: don't let programmers touch the html markup. their job belongs in the class files defining functions and database queries. All the programmers should be doing is writing business logic that outputs the desired raw data.

      don't destroy the markup with endless looping table structures because that's all you know how to code for... and it's easy.

      step 0: hire an interactive director to create wireframes and a functional spec for both the designers and the programmers to follow. Then all will go smoothly until the very end, at which point the client will change their mind and chaos will ensue.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    4. Re:step 1 by Bogtha · · Score: 2, Interesting

      On the contrary, web designers should be messing with the HTML, as they are the ones most qualified to do it. I suspect you are using "web designer" as a synonym for "graphic designer", but they are really two separate roles.

      A graphic designer should be responsible for how a website looks. He needs certain domain-specific knowledge, so that he doesn't do anything silly like assume that words take up a fixed amount of space, but he should be concerned with how things look and not touch code.

      A web designer should then take that look and translate it into code. This involves writing both the CSS and the HTML, talking to the designer to get him to give him the graphics layered/sliced in particular ways, and so on. The web designer is responsible for the front-end, how the interface operates.

      The web developer should then take the static pages that the web designer created, and "make them work". Turn them into templates, add business logic, pull data from the database, etc. The web developer is responsible for the back-end, how the application works.

      I've worn all three hats from time to time, but the ideal situation is to have different people focusing on the different aspects. It's rare to get somebody qualified in more than one area, and when you let them into other areas, they tend to screw up. The bigger the business, the more people you add on the edges — further afield in the graphic designed direction is branding/marketing, and further afield in the web developer direction are DBAs and sysadmins. But dead centre is the web designer writing the code that makes an interface operate.

      --
      Bogtha Bogtha Bogtha
    5. Re:step 1 by bit+trollent · · Score: 2, Insightful

      step 2: don't let programmers touch the html markup. their job belongs in the class files defining functions and database queries. All the programmers should be doing is writing business logic that outputs the desired raw data.

      Uhhuh. And what about interactive software? You know, where a repeater displays data which can be modified and used in a variety of ways. Should you still stick the developer in his little cubby hole of ouputting raw data?

      And why is it you want to stick the dev in his hole? Because you don't like tables?

      I've got news for you. Who gives a shit if there are tables in your html? Only wankers! This isn't rocket science people. This is the art of displaying data and pictures and interactive elements on a page where they belong. Thats it.

      Well written HTML or any other code has less to do with adhering to rules for their own sake than with creating things which look correct and are easily maintainable. I code to get things done. Not to conform to your wankary.

      If you want to avoid html tables like they were a SQL injection vulnerability that is fine by me. My work just gets done faster and with less bizzare rendering bugs by comparison. Just don't tell me that the only way for me to display data and whatnot is with an unnecessarily complex scheme that limits flexibility rather than extends it.

    6. Re:step 1 by ThePromenader · · Score: 1

      Web designers should do a good long bout of coding before they sit down to design a site - it would save everyone in the team a lot of trouble. Also, a bit more attention should be paid to ergonomics - web browsing remains instinctive (big red button marked "here"! Oh, click click! Underline == link! Just what is that menu doing and where will it take me?) and design should be steeped more in that than... design itself.

      I agree with the above - good design is a mix of all web trades (namely design (layout) and server-side mechanics), and each should know each other's at least to a trifling degree... or undertake the horrible, horrible task of doing it all themselves. At least it will be an education in the end.

      --

      No, no sig. Really.

      ThePromenader
    7. Re:step 1 by foniksonik · · Score: 1

      SO when I want to create a horizontal list out of your table of data and now I can't because it's stuck in a table instead of an unordered list which lets me decide how to display it I should thank you for your maintainable code?

      Or when it comes time to debug why content isn't lining up correctly on a page and I have to muck through some spaghetti code of if/else madness with endless tr,td constructs and colspans that don't do anything anymore... or when you've decided that some application really should be a 3 column YAP site and you've hardcoded in a bunch of crappy menus in tables or whatever it is rather than using a proper MVC pattern and a template engine, what should I do then?

      Please, just write the logic and document how to use your API. I can implement the rest in whatever format I choose.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    8. Re:step 1 by bit+trollent · · Score: 1

      SO when I want to create a horizontal list out of your table of data

      Change the templates in the repeater.

      should thank you for your maintainable code?

      Yes.

      Or when it comes time to debug why content isn't lining up correctly on a page and I have to muck through some spaghetti code of if/else madness with endless tr,td constructs and colspans that don't do anything anymore

      Your post is basically a rant against the same kind of bad programming that I also complain about. The same code would suck if it used css instead of tables.

    9. Re:step 1 by yurigoul · · Score: 1

      I agree! Of course I use tables, it all has to do with Murpheys law: if anything can go wrong it will at some point. If I have to do xhtml + css the zen garden way i might get a beautifull site but they are using a lot of energy in finding tricks to render their sites in all browsers the way they want them to and those tricks may or may not work in future browser releases. But i can do most of it if not all while using tables and a minumum amount of energy to get it rendered correctly in all browsers for years to come.

  6. The patterns of site design by also-rr · · Score: 4, Funny
    • Still done in HTML 3.2.
    • Still done in HTML 3.2 but with tables for layout.
    • Still done in HTML 3.2 but with tables for layout... and heavy on that new fangled BLINK tag.
    • Done completely in Flash.
    • Done mostly right, but with all the actual information in Flash.
    • Incorporating a browser check that sends !ie to a holding page.
    • Navigation missing.
    • Navigation broken.
    • Navigation an active X control.
    • Split over 17 pages of two paragraphs (and nine ads) each.
    • Correctly coded in XHTML+CSS with graceful fallback. (NB: Never seen in the wild.)
    1. Re:The patterns of site design by JAS0NH0NG · · Score: 1

      You have a lot of good points and anti-points (ie things to avoid) with respect to practical implementation of web sites. However, I think it doesn't quite capture the essence of user interface design patterns. What you have is more of guidelines, which are useful, but don't provide actual examples of what to do.

      Another way patterns differ from guidelines (and something the GoF missed) is that they should be hierarchical. Take a look at Christopher Alexander's original book on design patterns, and you'll see that he starts with large regions, continues on to cities, to neighborhoods, individual buildings, and rooms. Such a structure helps people simultaneously see the micro view as well as understanding how it fits into the macro view of things.

    2. Re:The patterns of site design by Marxist+Hacker+42 · · Score: 1

      You missed (and this is somewhere below HTML 3.2) Done entirely in huge, uncompressed Bitmaps that take forever to load even at broadband speeds.

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    3. Re:The patterns of site design by MP3Chuck · · Score: 1

      Web 0.1, perhaps? ;)

    4. Re:The patterns of site design by Marxist+Hacker+42 · · Score: 1

      Pretty close. This advice actually came from a ZNet article circa 1995- back when incorrectly compressed pictures and improperly coded img tags could cause a page to be rendered so slowly that nobody actually ever got to the content- the modem would drop carrier first.

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    5. Re:The patterns of site design by bigdavesmith · · Score: 2, Interesting

      All this brings up a good point, and one I'm currently having to address. How do you tell someone who is not a web designer (small business owners, from my experience) that their website is bad, or has problems, when the web is such a collection of bad examples? 'But Everybody Else is Doing It!'

      I'm a student doing some web work for my university. Nothing major.
      Anyway, my boss (who is an awesome guy, but not a web designer), the person who threw the site together originally, used Dreamweaver, and for some reason made every link an individual Flash file, so our pages aren't being indexed correctly by Google. When I said that it was a problem, his response was that 'I'm not the only one using Dreamweaver, find out what we do to make it work'.

      How do you tell someone in a situation like this: 'No, it's just wrong, and if you want it to work, you're going to have to pay me to redo it' when the rest of the web is just as bad?

  7. Re: The Design of Sites by stevey · · Score: 1

    It is hear I realize the true value of the book: there are no 'right' answers in design, only guidelines:

    Interesting sounding book, I might take a look.

    But for future reference "here" not "hear".

  8. Sounds like PimpMyWebsite by HOTTILA.COM · · Score: 1

    A touch of pink might be ok :)

    --
    Strive to be happy...
  9. well by Anonymous Coward · · Score: 0

    well, you failed grandly

  10. Design of Sites Website by mh1997 · · Score: 1
    How come when I go to http://www.designofsites.com/index.htm, the book shown is the first edition, yet the link at the bottom of the review is for the second edition?

    The book looks very good, and I will purchase it today, but you'd think that the author's website would have been updated, you know, to make the design of the site....

    1. Re:Design of Sites Website by gsmalleus · · Score: 1

      You didn't see the link to the book on Amazon that was included with the summary?

    2. Re:Design of Sites Website by Anonymous Coward · · Score: 0

      How come the site falls into the same trap as countless other sites and links to a PDF doc called 'ch01.pdf'? If you think there's a chance in hell that next week, when I get around to reading the PDF, I'll remember what that filename refers to, then you obviously don't have a downloads folder full of files called useful things like 'prog.pdf' (for the half dozen different festivals on this summer). How many platforms still impose 8.3 filenames? Would it kill the site developer to call the PDF something useful? Or do they just assume that theirs is the only site on the internet where I might actually download a linked document? Do they know, or just not care, that useful information can be added to the PDF meta tags?

      Sheesh!

  11. I picked.. by Nazlfrag · · Score: 1
    Extremely Valuable Highly Professional Big Company Sites, I'm bound to get rich!

    So, they wrote a book about how many templates are there in Dreamweaver.. what the hell does that have to do with programming, GoF or design patterns?

  12. Ajax Design Patterns by Michael Mahemoff by at_$tephen · · Score: 1

    I think Mahemoff does an excellent job on "Ajax Design Patterns". He is clearly well schooled in the traditional design patterns of Gamma et al and does an excellent job using a similar spirit vis a vis Ajax. He covers an impressive number of sites, many of whom I would never have heard about if it were not for his diligent research. He has a catalog of the specific patterns he covers such as Ajax App, Ajax Stub, Browser-Side Cache, and Data Grid. However, the actual book is organized in five main areas beginning with a great intro to basic Ajax (the section "Anatomy of a Server Call" is particularly good). After the intro the other areas covered are (1) Foundational Technology Patterns (including web remoting); (2) Programming Patterns, with a great intro to web services and clarity on what qualifies as a Restful service and why it is popular + DOM + code generation; (3) Functionality and Usability Patterns (widgets, page architecture, visual effects, etc); and (4) Development Patterns (diagnosis, testing). He spends a great deal of time discussing the tradeoffs in the performance of Ajax calls and even has a link to a back of the envelope calcs of the latency of ajax calls. It's filled with all sorts of neat Ajax tricks to optimally give the illusion of continuity as the user browses over a large dataset (eg in maps). Lots of technologies are covered in sufficient detail and really anyone with enough interest can understand it. This is just a solid programming/engineering book period. When I read a book like this I am awed at the power of the individual to organize. I would have taken ages to dig up Ajax related stuff here and there (and even in many books I perused), but when I found this book I was like, "Ok, I've found my guide!". You can't go wrong buying this book. At each step he brings attention back to the underlying pattern and when one understands the pattern , one is freed from the details just as the Gamma et al authors intended. So, fellow coders, this may be another book to add next to your desktop coding bibles (Gamma et al, etc...). Enjoy....