Categories
Design family glamorous State of the Web The Essentials Web Design Web Design History Web Standards

My website is 20 years old today.

MY WEBSITE is 20 years old today. I’m dictating these remarks into a tiny handheld device, not to prove a point, but because, with gorgeously ironic timing, my wired internet connection has gone out. It’s the kind of wired connection, offering the kind of speed, ‘most everyone reading this takes for granted today—a far cry from the 14.4 modem with which I built and tested the first version of this site, shipping it (if you could call it that) on May 31, 1995.

I’m no longer dictating. I’m pecking with my index finger. On the traditional computer keyboard, I’m a super-fast touch typist. I mastered touch typing in high school. I was the only boy in that class. All the other boys took car repair. They laughed at me for being in a class full of girls, which was weird and stupid of them on at least five levels. Maybe they wanted to work in an auto body shop. I wanted to be a writer and an artist. Learning to type as quickly as I could think was a needed skill and part of my long self-directed apprenticeship.

My first typewriter cost me $75. I can’t tell you how many hours it took me to earn that money, or how proud I was of that object. I wrote my first books on it. They will never be published but that’s all right. Another part of the apprenticeship.

After touch typing at the speed of thought for decades, I found it tough learning to write all over again, one finger letter at a time, in my first iPhone, but I’m fluent today. My right index finger is sending you these words now, and probably developing early onset arthritis as a result, but I am also fairly fluent with with my left thumb when situations compel me to work one-handed. The reduced speed of this data entry ritual no longer impedes my flow. 

And since WordPress is an app on my phone, and my AT&T 4E connection never fails me, even when the cable modem internet connection is out,  today I can update my site leagues faster than when I was chained to a desk and wires and HTML and Fetch and static files—20 years ago, before some of you were born. 

I wanted to launch a redesign on this 20th anniversary—in the old days I redesigned this site four or five times a year, whenever I had a new idea or learned a new skill—but with a ten year old daughter and four businesses to at least pretend to run (businesses that only exist because I started this website 20 years ago today and because my partners started theirs), a redesign by 31 May 2015 wasn’t possible. 

So I’ll settle for the perfectly timed, gratitude-inducing, reflection-prompting failure of my cable modem on this of all days. That’s my redesign for the day: a workflow redesign. 

Boy, is my finger tired. Too tired to type the names of all the amazing and wonderful people I’ve worked with over the past 20 years. (Just because a personal site is personal doesn’t mean it could have happened without the help and support and love of all you good people.)

When I started this site I wrote in the royal “we” and cultivated an ironic distance from my material and my gentle readers, but today this is just me with all my warts and shame and tenderness—and you. Not gentle readers. People. Friends. 

I launched this site twenty years ago (a year before the Wayback Machine, at least two years before Google) and it was one of the only places you could read and learn about web design. I launched at a tilde address (kids, ask your parents), and did not think to register zeldman.com until 1996, because nobody had ever done anything that crazy. 

On the day I launched my pseudonymous domain I already had thousands of readers, had somehow coaxed over a million visitors to stop by, and had the Hit Counter to prove it. (If you remember the 1970s, you weren’t there, but if you remember the early web, you were.) Today, because I want people to see these words, I’ll repost them on Medium. Because folks don’t bookmark and return to personal sites as they once did. And they don’t follow their favorite personal sites via RSS, as they once did. Today it’s about big networks. 

It’s a Sunday. My ten year old is playing on her iPad and the two cats are facing in opposite directions, listening intently to fluctuations in the air conditioning hum. 

I’ve had two love relationships since launching this site. Lost both, but that’s okay. I started this site as a goateed chain smoker in early sobriety (7 June 1993) and continue it as a bearded, yoga practicing, single dad. Ouch. Even I hate how that sounds. (But I love how it feels.) 

I started this site with animated gifs and splash pages while living in a cheap rent stabilized apartment. PageSpinner was my jam. I was in love with HTML and certain that the whole world was about to learn it, ushering in a new era of DIY media, free expression, peace and democracy and human rights worldwide. That part didn’t work out so well, although the kids prefer YouTube to TV, so that’s something. 

My internet failure—I mean the one where an internet connection is supposed to be delivered to my apartment via cable—gets me off the hook for having to create a visual tour of “important” moments from this website over the past 20 years. No desktop, no visual thinking. That’s okay too. Maybe I’ll be able to do it for for this site’s 25th anniversary. That’s the important one, anyway. 


Hand pecked into a small screen for your pleasure. New York, NY, 31 May 2015. The present day content producer etc.

Categories
State of the Web Web Design Web Design History Web Standards Websites

20 Years Ago Today: Bill Gates Wakes Up And Smells The Internet.

3817151597_dbf72316b3_b

TODAY marks the 20th anniversary of Bill Gates’s famous letter about the web, and my first website, batmanforever.com, created with Steve McCarron and Alec Pollak for Donald Buckley of Warner Bros and optimized for Netscape 1.1.

Gates’s memo to employees, published this day twenty years ago and entitled “The Internet Tidal Wave” accurately identified the web as a threat to its kingdom of binary desktop software, and set Microsoft on course to “own” the browser, thereby holding back the threat for about fifteen years. A transcript of Gates’s memo is available at petri.com, along with a mixed bag of then-and-now analysis. (Hat tip to Alan K’necht for the link.)

Today, of course, Microsoft embraces open web standards, while companies that didn’t exist at the time of the memo (like Google) or were insignificant competitors seemingly on their way to the grave (like Apple) enjoy the godlike position Microsoft once held—and used every trick in the book to hold onto.

The Batman Forever site was much shorter-lived and far less influential than the Gates memo, although we did manage to introduce web design ideas like animated entrance tunnels and metaphor-based navigation—things we later abjured. My partner Steve got out of web design and is a VP Creative Director director at Publicis. My partner Alec stuck with web and software design, but from the agency side. I stayed in web design, and I even still call it that…although I also sometimes just call it design. Our first web client Donald Buckley is a huge deal at Showtime.


“Jeffrey Zeldman Presents” turns 20 on May 31.

Categories
Big Web Show Design Education Standards State of the Web The Big Web Show Web Design Web Design History Web Standards

Progressive Enhancement FTW with Aaron Gustafson

IN EPISODE ? 130 of The Big Web Show (“Everything Web That Matters”), I interview long-time web standards evangelist Aaron Gustafson, author of Adaptive Web Design, on web design then and now; why Flipboard’s 60fps web launch is anti-web and anti-user; design versus art; and the 2nd Edition of Aaron’s book, coming from New Riders this year.

Enjoy Episode ? 130 of The Big Web Show.

Show Links

A Bit About Aaron Gustafson
Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
Responsive Issues Community Group
Easy Designs – Web Design, Development & Consulting
Web Standards Sherpa
Code & Creativity
WebStandardsProject (@wasp) | Twitter
A List Apart: For People Who Make Websites
Genesis – Land Of Confusion [Official Music Video] – YouTube

Categories
Best practices Blue Beanie Day Web Design Web Standards

Diversity and Web Standards

ON THIS year’s Blue Beanie Day, as we celebrate web standards, we also celebrate our community’s remarkable diversity—and pledge to keep things moving in a positive, humanist direction.

Racism, sexism, misogyny and other forms of foolish, wrongful pre-judging have no place in our beautiful community. As hard as we work to make sure our websites work for everyone, let’s work twice as hard to be certain we are just as open-hearted and welcoming to our peers as our designs are to our users.

Categories
books Publishing Responsive Web Design State of the Web Web Design Web Design History Web Standards

Evolving Responsive Web Design

In What We Mean When We Say “responsive” and Defining Responsiveness, Lyza Danger Gardner and Jason Grigsby cut to the heart of a disagreement I had three years ago with Ethan Marcotte, the creator of Responsive Web Design and author of Responsive Web Design, a book I published in 2011.

Ethan told the world that Responsive Web Design required, and was defined by, fluid layouts, flexible images, and media queries. All three elements had to be present. If they weren’t using all three, you might be doing something interesting, but you were most definitely not doing Responsive Web Design.

Ethan invented all of this. Without him, we would likely be arguing whether it was time to consider 1280 pixels the new default fixed width for all desktop websites, and sending anything that wasn’t a desktop browser to a function- and content-limited “mobile site” whose URL began with the letter m. Ethan is a brilliant, multi-talented innovator; I am but the shadow of a hack. And yet, before he began creating his book, midway through the writing, and even a year after I published it, I continued to urge Ethan to rethink #RWD as “a bigger idea”—a concept rather than a single set of techniques.

I’m no genius. What I meant by “bigger idea” was limited to the notion that we’d one day be able to create responsive layouts with different techniques—so let’s not restrict the concept to a particular execution. I wasn’t thinking about other meanings of responsive, wasn’t considering problems of responsive content, and so on. I’m not that forward-thinking and it was three freaking years ago, come on.

I lost my gentle argument with Ethan, so the industry is having it now. And that’s just as it should be. Everything worked out for the best. Here’s why:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.

We’ve only become ready to think about things like “responsible” responsive design, adaptive content, and a standard approach to responsive images now that we have built our share of first-generation responsive sites, and encountered the problems that led to the additional pondering. Baby steps. Brilliant baby steps.

Some commenters want to use initial-capped Responsive Web Design to mean responsive design as Ethan first defined it, and lowercase responsive design to mean an amorphous matrix of exciting and evolving design thinking. Lyza says soon we’ll stop saying Responsive altogether, a conclusion Andy Clarke reached three years ago.

Me, I like that Ethan stuck to his guns, and that the classical definition will always be out there, regardless of how web design evolves thanks to it. Kind of like there’s HTML 5, a defined and scoped W3C specification, and HTML living standard, an evolving activity. Our industry needs roots and wings, and, lucky us, we’ve got ’em both.

Categories
Big Web Show ethics Standards State of the Web The Big Web Show W3C Web Standards

Big Web Show ? 109: Bring Me The Head of Tim Berners-Lee

2aa4b628a29d2b8c1f2b7742a6d8dcb0

IN BIG WEB SHOW ? 109, Robin Berjon and I enjoy a calm, rational conversation about EME, DRM, the MPAA, and the W3C. Enjoy.


The episode was sponsored by Squarespace. Links mentioned:

Categories
Standards State of the Web Web Design Web Design History Web Standards

It’s 2014. Is Web Design Dead?

IN A RECENT article on his website, Web Standards Killed the HTML Star, designer Jeff Croft laments the passing of the “HTML and CSS ‘guru’” as a viable long-term professional position and urges his fellow web design generalists to “diversify or die.”

The reason the Web Standards Movement mattered was that the browsers sucked. The stated goal of the Movement was to get browser makers on board with web standards such that all of our jobs as developers would be easier.

What we may not have realized is that once the browsers don’t suck, being an HTML and CSS “guru” isn’t really a very marketable skillset. 80% of what made us useful was the way we knew all the quirks and intracries of the browsers. Guess what? Those are all gone. And if they’re not, they will be in the very near future. Then what?

From my perspective, the web standards struggle consisted of two phases of persuasion: first we convinced browser makers that it was in their interest to support current HTML, CSS, and JavaScript specifications completely and accurately; then we evangelized the accessibility, findability, and portability benefits of lean semantic markup and progressive enhancement to our colleagues who made websites and their clients.

Evangelizing true compliance, not mastering workarounds for compliance failures, was always the point. Evangelizing was key. Browsers weren’t going to stay standards compliant if nobody made use of that compliance; likewise, W3C specifications weren’t going to advance unless designers seized hold of technologies like CSS to push type and layout on the web as far as they could go—and then complain that they didn’t go far enough.

It took a village of passionate browser engineers, designers, front-end developers, and generalists to bring us to the web we have today. Does the movement’s success mean that many of those who led it will become jobless, like Bolsheviks after the Russian Revolution?

Jeff Croft is correct when he says “the goal of the Web Standards Movement was for it to not have to exist.” But we should take this a step further. The goal of the web standards movement was to remove needless complexity and absurdity from the process of creating websites so we could focus our attention where it should be: on design, content, and experience. Evangelizing standards to browser makers and our fellow designers was not a career path, and was never intended to be—any more than aiding a wounded buddy turns a soldier into a physician.

Interestingly, once web standards made the web safe for design, content, and experience, the web’s capabilities—and, thus, the work required to create certain kinds of websites—started becoming more and more complex. To help cut down on that complexity, some front-end developers began sharing chunks of code (from Eric Meyer’s CSS Reset to Mark Otto’s Bootstrap) which paradoxically set in motion another level of complexity: as Jeff Croft points out, familiarity with these and dozens of other tools is now expected of job applicants who could once get hired on nothing more than a solid understanding of HTML and CSS plus a little JavaScript.

HTML “gurudom” was never a career path for anyone, aside, maybe, from a couple of talented authors. Same thing with CSS trickery. Doing black magic with CSS3 can get you a slot on a web design conference stage, but it’s not a career path or proper goal for most web designers.

Fascinatingly, to me, anyway, while many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding on the part of those who created the site; all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

This doesn’t mean “go be an HTML guru.” It does mean cherish the lessons of the recent past, and share them with those who missed them (or missed the point). Wisdom is not a job, but it is always an asset.

Never fear, web design generalists: many companies and organizations require your services and always will—from universities still seeking “webmasters,” to startups seeking seasoned folks with multiple areas of understanding to direct and coordinate the activities of younger specialists. But if jack-of-all web work is feeling stale, now may be the time to up your game as a graphic designer, or experience designer, or front end developer. “Diversify or die” may be overstating things a bit. But “follow the path you love” will always be good advice.

Categories
Blue Beanie Day The Essentials Web Design Web Design History Web Standards

Blue Beanie Day is Coming!

A sea of blue hats

ALL IT TAKES is a toque and a dream.

Join your fellow web designers and developers around the world on Saturday, 30 November 2013, as we march in virtual solidarity in support of web standards.

The countdown to this worldwide celebration begins today, with the opening of the Blue Beanie Day 2013 photo pool on good old Flickr.com. Read more at the new official home of Blue Beanie Day online, bluebeanieday.tumblr.com.

Categories
Design software State of the Web The Essentials The Profession Usability User Experience UX Web Design Web Design History Web Standards

The Lords of Vendorbation

Vendorbation
ven·dor·ba·tion
/?vend?r-?b?-sh?n/

noun : Unusable web-based intranet software foisted on large populations of users who have no say in the matter. For example, the “dynamic” website for your kid’s school, on which you can never find anything remotely useful—like her classroom or the names and email addresses of her teachers. Merely setting up an account can be a Borgesian ordeal minus the aesthetics.

Tried updating a driver’s license, registering a name change after a marriage, or accomplishing pretty much any task on a local, state, or federal website? Congratulations! You’ve been vendorbated. In ad sales? In publishing? Travel agent? Work in retail? Y’all get vendorbated a hundred times a day. Corporate America runs, not very well, on a diet of dysfunctional intranets sold by the lords of vendorbation.

Terrible food kills a restaurant. Terrible music ends a band’s career. But unspeakably terrible software begets imperial monopolies.

Wholesale contractual vendor lock-in between vendors of artless (but artfully initially priced) web software and the technologically unknowing who are their prey (for instance, your local school board) creates a mafia of mediocrity. Good designers and developers cannot penetrate this de-meritocracy. While they sweat to squeeze through needle’s eye after needle’s eye of baffling paperwork and absurd requirements, the vendorbators, who excel at precisely that paperwork and those requirements, breeze on in and lock ‘er down.

Vendorbation takes no heed of a user’s mental model; indeed, the very concept of a user’s mental model (or user’s needs) never enters the minds of those who create vendorbatory software. I say “create” rather than “design,” because design has less than nothing to do with how this genre of software gets slapped together (“developed”) and bloated over time (“updated”).

Vendorbatory product “design” decisions stem purely from contingencies and conveniences in the code framework, which itself is almost always an undocumented archipelago of spaghetti, spit, and duct tape started by one team and continued by others, with no guiding principle other than to “get it done” by an arbitrary deadline, such as the start of a new school year or the business cycle’s next quarter.

Masturbation, or so I have read, can be fun. Not so, vendorbation. It is a nightmare for everyone—from the beleaguered underpaid lumpen developers who toil in high-pressure silos; to the hapless bureaucrats who deserve partners but get predators instead; from the end users (parents, in our example) who can never do what they came to do or find what they want, and who most often feel stupid and blame themselves; to the constituents those users wish to serve—in our example, the children. Will no one think of the children?

Cha-ching! Like a zombie-driven un-merry-go-round spinning faster and faster as the innocents strapped to its hideous horses shriek silently, the vendorbation cycle rolls on and on, season after bloody season, dollar after undeserved dollar, error after error after error after error in saecula saeculorum.

Think it’s bad now? Wait till the lords of vendorbation start making their monstrosities “mobile.”


Doff of the neologist’s toque to Eric A. Meyer, whose cornpensation helped crystalize what to do with the bad feelings.

Categories
An Event Apart architecture Best practices Chicago cities Code creativity Design Designers glamorous IXD Mobile mobile Multi-Device Standards State of the Web Usability User Experience UX Web Design Web Standards Working Zeldman

Chicago, Chicago

An Event Apart Chicago—a photo set on Flickr. Photos of the city and the conference for people who make websites.

AN EVENT APART Chicago—a photo set on Flickr. Pictures of the city and the conference for people who make websites.

Notes from An Event Apart Chicago 2013—Luke Wroblewski’s note-taking is legendary. Here are his notes on seven of the ten presentations at this year’s An Event Apart Chicago.

#aeachi—conference comments on Twitter.

Chicago (Foursquare)—some of my favorite places in the city.

An Event Apart Chicago—sessions, schedule, and speaker bios for the conference that just ended.

AEA Chicago 2013 on Lanyrd—three days of design, code, and content on the social sharing platform for conferences.


THE NEXT AEA event takes place in Austin and is already sold out (although a few spaces are still available for the full-day workshop on multi-device design).

A handful of seats are available for the final event of the year, An Event Apart San Francisco at the Palace Hotel, December 9–11, 2013. Be there or be square.


Categories
A List Apart Accessibility Apple Layout mobile Standards State of the Web Web Design Web Design History Web Standards

A List Apart Issue No. 367: Apple’s Vexing Viewport

In A List Apart Issue No. 367, Peter-Paul Koch, Lyza Danger Gardner, Luke Wroblewski, and Stephanie Rieger explain why Apple’s new iPad Mini creates a vexing situation for designers and developers who create flexible, multi-device experiences.

Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal. This agreement has never been more important.

That’s why it hurts when a device or browser maker does something that goes against our agreement—especially when they’re a visible and trusted friend of the web like Apple. Read Vexing Viewports and contribute to the discussion.

This issue of the magazine also marks the departure of Jason Santa Maria as creative director after seven years of brilliant design and support.

Jason’s elegant redesign of A List Apart and its brand in 2005, together with the master stroke of bringing in Kevin Cornell as illustrator, brought the magazine new fame, new readers, and new respect. Over seven great years, his attention to detail, lack of pretension, and cheerful, can-do attitude has made working on ALA a pleasure. Jason was also a key member of the strategic team that envisioned ALA’s upcoming content expansion—about which, more will be revealed when the site relaunches in January.

Jason will continue at ALA as a contributing writer and as designer of A Book Apart (“brief books for people who make websites”), of which he is also a co-founder.

Categories
Code CSS HTML Web Standards

In Defense of Descendant Selectors and ID Elements

Except when I occasionally update Designing With Web Standards, I quit writing hands-on, nuts-and-bolts stuff about CSS and HTML years ago. Publishing abhors a vacuum: other designers and developers took my place. For the most part, this has been a good thing—for them and for our industry. The best writers about code have always been those who spend 25 hours of every day up their necks in it, as I used to. While folks like me migrate into strategic or supervisory roles (providing us with new places to innovate and new things to write about), a new generation of code crafters is making new discoveries and sharing new teachings. Ah, the magical circle of life.

But amid the oodles of resulting goodness, I find occasional stinkers. Take the notion, now concretizing into dogma, that id should almost never be used because it has “too much specificity,” and that class names are always preferable. Respectfully, I call bunk.

To my knowledge, this notion comes out of Nicole Sullivan’s brilliant Object Oriented CSS, an approach for writing HTML and CSS that is designed to scale on sites containing thousands of pages, created by dozens of front-end developers over a period of years, generally with no rules or style guide in place (at least no rules or style guide until it is too late). On sites like these—sites like Amazon or Facebook that are hosed from the get-go thanks to too many cooks and no master chef—the use of structural id and descendant selectors can be problematic, especially when inept coders try to overwrite an id-based descendant selector rule by creating ever-more-specific descendant selector rules.

In this particular (and rare) circumstance, where dueling developers have added rule after rule to a huge, shapeless style sheet that is more of an archeological artifact than a reasonable example of modern code, Nicole’s admonition to avoid descendant selectors based on id is probably wise. If you have the misfortune to work on a huge, poorly developed site where you will never have permission to refactor the templates and CSS according to common sense and best practices, you may have to rely on class names and avoid descendant selectors and ids.

But under almost any other circumstance, properly used ids with descendant selectors are preferable because more semantic and lighter in bandwidth.

The way I have always advocated using id, it was simply a predecessor to the new elements in HTML5. In 2000, we wrote div id="footer" because we had no footer element, and we wanted to give structural meaning to content that appeared within that div. Today, depending on the browsers and devices people use to access our site, we may well have the option to use the HTML5 footer element instead. But if we can’t use the HTML5 element, there is nothing wrong with using the id.

As for descendant selectors, in a site not designed by 100 monkeys, it is safe to assume that elements within an id’d div or HTML5 element will be visually styled in ways that are compatible, and that those same elements may be styled differently within a differently id’d div or HTML5 element. For instance, paragraphs or list items within a footer may be styled differently than paragraphs or list items within an aside. Paragraphs within a footer will be styled similarly to one another; the same goes for paragraphs within an aside. This is what id (or HTML5 element) and descendant selectors were made for. Giving every paragraph element in the sidebar a classname is not only a needless waste of bandwidth, it’s also bad form.

Say it with me: There is nothing wrong with id when it is used appropriately (semantically, structurally, sparingly). There is plenty wrong with the notion that class is always preferable to descendant selectors and semantic, structural ids.

Please understand: I’m not disparaging my friend Nicole Sullivan’s Object Oriented CSS as an approach to otherwise unmanageable websites. No more would I disparage a steam shovel for cleaning up a disaster site. I just wouldn’t use it to clean my room.

I’ll be discussing code and all kinds of other things webbish with Chris Coyier and Dave Rupert on the Shoptalk podcast today. Meanwhile, let me know what you think. And don’t forget November 30th is the sixth international celebration of Blue Beanie Day in support of web standards. Wherever you may stand on the great id debate, please stand with me and thousands of others this November 30th.

Categories
A List Apart Design Publisher's Note Web Design Web Design History Web Standards

In Search of a Genuine Web Aesthetic & Designing For High Density Displays

IN A VERY special issue of A List Apart for people who make websites, Paul Robert Lloyd asks us to put the “design” back in “responsive design” and seek out a genuine web aesthetic. And Dave Rupert shares ways to be thoughtful, not knee-jerk, about high-pixel-density displays, in Mo’ Pixels Mo’ Problems.


Illustration by Kevin Cornell for A List Apart

Categories
Acclaim Best practices Design Web Design Web Design History Web Standards Zeldman

PBS Off Book video: The Art of Web Design

Whitney Hess, Jason Santa Maria, and I discuss the past two decades of design history, framing the web’s emergence and explaining the transition from a print-based world to a digital one.

Categories
Acclaim Announcements Design people Press Publications Publishing Stories Web Design Web Design History Web Standards Zeldman

Insites: The Book Honors Web Design, Designers

“INSITES: THE BOOK is a beautiful, limited edition, 256-page book presented in a numbered, foil-blocked presentation box. This very special publication features no code snippets and no design tips; instead, 20 deeply personal conversations with the biggest names in the web community.

“Over the course of six months, we travelled the US and the UK to meet with Tina Roth Eisenberg, Jason Santa Maria, Cameron Moll, Ethan Marcotte, Alex Hunter, Brendan Dawes, Simon Collison, Dan Rubin, Andy McGloughlin, Kevin Rose and Daniel Burka, Josh Brewer, Ron Richards, Trent Walton, Ian Coyle, Mandy Brown, Sarah Parmenter, Jim Coudal, Jeffrey Zeldman, Tim Van Damme, and Jon Hicks.

“We delved into their personal journeys, big wins, and lessons learned, along with the kind of tales you’ll never hear on a conference stage. Each and every person we spoke to has an amazing story to tell?—?a story we can all relate to, because even the biggest successes have the smallest, most humble of beginnings.” — Insites: The Book


I am honored to be among those interviewed in this beautiful publication.


Insites: The Book is published by Viewport Industries in association with MailChimp.