Designed by Happy Cog and launched today, The Amanda Project is a social media network, creative writing project, interactive game, and book series combined:
The Amanda Project is the story of Amanda Valentino, told through an interactive website and book series for readers aged 13 & up. On the website, readers are invited to become a part of the story as they help the main characters search for Amanda.
The writing-focused social media network is designed and written as if by characters from the Amanda novels, and encourages readers to enter the novel’s world by joining the search for Amanda, following clues and reading passages that exist only online, and ultimately helping to shape the course of the Amanda narrative across eight novels. (The first Amanda novel—Invisible I, written by Melissa Kantor—comes out 22 September.)
The site developed over a year of intense creative collaboration between Happy Cog and Fourth Story Media, a book publisher and new media company spearheaded by publishing whiz Lisa Holton. Prior to starting Fourth Story, Lisa was was President, Scholastic Trade Publishing and Book Fairs; managed the publication of Harry Potter and the Deathly Hallows; and oversaw development of The 39 Clues. Before that she spent nearly a decade developing numerous bestselling, franchise-launching series at Disney.
Happy Cog‘s New York office developed this project. The team:
Equally vital to the project’s success were Fourth Story’s leaders and partners, including:
Lorraine Shanley, Principal Advisor
Ariel Aberg-Riger (website, Twitter), Creative Development & Marketing Manager
JillEllyn Riley, Editorial Director
Dale Robbins, Creative Director
David Stack, Director, Digital Partnerships
Melissa Kantor, Writer
Peter Silsbee, Writer
Polly Kanevsky, Art Director
Sam Gerstenzang, Technology Consultant
Today’s launch is not the end of our relationship with Fourth Story Media. The Amanda Project will continue to evolve, and Happy Cog will remain an active partner in its direction and growth. We thank our brilliant collaborators and congratulate them on today’s milestone.
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
Design is for people
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
Shrinkage and seduction
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
What were once vices are now habits
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
The future of the future of standards
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.
It’s time we came to grips with the fact that not every “document” can be a semantic “web page.” Some forms of writing just cannot be expressed in HTML—or they need to be bent and distorted to do so. But for once, XML can help. Joe Clark explains.
To make accessible design an organic element of front-end development, we must free our thinking from the constraints we associate with accessible design and embrace the inclusion principle. Margit Link-Rodrigue tells us how.
When Apple chose KHTML rather than Mozilla Gecko as the basis for its Safari browser, some of us in the web standards community scratched our heads. Sure, KHTML, the rendering engine in Konqueror, was open-source and standards-compliant. But, at the time, Gecko’s standards support was more advanced, and Gecko-based Mozilla, Camino, and even Netscape 6 felt more like browsers than Konqueror. Gecko browsers had the features, the comparative maturity, and the support of the standards community. Apple’s adoption of KHTML, and creation of a forked version called Webkit, seemed puzzling and wrong.
Yet, thanks largely to the success of the iPhone, Webkit (Apple’s open source version of KHTML) in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. Had Apple chosen Gecko, they might not have been able to so powerfully influence mainstream consumer opinion, because the fully formed, distinctly mature Gecko brand and experience could easily have overshadowed and constrained Apple’s contribution. (Not to mention, tolerating external constraint is not a game Apple plays.)
Just how has mobile Safari, a relative latecomer to the world of standards-based browsing, been able to make a difference, and what difference has it made?
The platform paradox
Firefox and Opera were wonderful before any Webkit-based browser reached maturity, but Firefox and Opera were and are non-mainstream tastes. Most people use Windows without thinking much about it, and most Windows users open the browser that comes with their operating system, again without too much thought. This doesn’t make them dumb and us smart. We are interaction designers; they are not.
Thus, the paradox: even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a comparatively poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. If you knew enough to want Firefox and Opera, those browsers delivered features and experience that confirmed the wisdom of your choice. If you didn’t know to want them, you didn’t realize you were missing anything, because folks reading this page sweated like Egyptian pyramid builders to make sure you had a good experience despite your browser’s flaws.
The power to convert
Firefox and Opera are great browsers that have greatly advanced the cause of web standards, but because they are choices in a space where most people don’t make choices, their power to convert is necessarily somewhat truncated. The millions mostly don’t care what happens on their desktop. It’s mostly not in their control. They either don’t have a choice or don’t realize they have one, and their expectations have been systematically lowered by two decades of unexciting user experience.
By contrast, the iPhone functions in a hot realm where consumers do make choices, and where choices are badges. Of course many people are forced economically to choose the cheap or free phone that comes with their mobile service. But many others are in a position to select a device. And the iPhone is to today’s urban professional gym rat what cigarettes and martinis were to their 1950s predecessors. You and I may claim to choose a mobile device based on its features, but the upwardly mobile (pardon the pun), totally hot person standing next to us in the elevator may choose their phone the same way they choose their handbag. And now that the iPhone sells for $99, more people can afford to make a fashion decision about their phone—and they’ll do it.
Although there were great phones before the iPhone, and although the iPhone has its detractors, it is fair to say that we are now in a Mobile 2.0 phase where people expect more than a Lynx-like experience when they use their phone to access the internet. Mobile Safari in iPhone, along with the device’s superior text handling thanks to Apple and Adobe technologies, is changing perceptions about and expectations of the web in the same way social networking did, and just at the historical moment when social networking has gone totally mainstream.
Oprah’s on Twitter, your mom’s on Twitter, and they’re either using an iPhone or a recently vastly upgraded Palm or Blackberry that takes nearly all of its cues from the iPhone. Devices that copy the iPhone of course mostly end up selling the iPhone, the same way Bravo’s The Fashion Show would mostly make you miss Project Runway if you even watched The Fashion Show, which you probably haven’t.
Safari isn’t perfect, and Mobile Safari has bugs not evident in desktop Safari, but Webkit + Apple = secret sauce selling web standards to a new generation of consumers and developers.
Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009
The earliest websites were minimal in the extreme, but without the style and flair to make a virtue of their simplicity. 37signals and Kottke pioneered the combination of simplicity with deft design sense. Cardigan made it art.
Although it is never popular, never the dominant trend, rarely wins design awards, and almost never earns acclaim from designers, design stripped down to its essentials is always a good idea, and especially on the web, where every byte counts. We salute the old and new practitioners of minimalist web design, and solicit your thoughts on pioneers or present practitioners who combine a minimalist aesthetic with significant design chops.
[tags]design, webdesign, minimalism, history, web design history[/tags]
Web standards curriculum
WaSP InterAct is a “living, open web standards curriculum.” Put together by an amazing group of dedicated educators and industry experts, the curriculum is designed to teach students the skills of the web professional—and ease the burden of colleges and universities, struggling to develop timely and appropriate curricula for our fast-moving profession.
Schools that teach web design struggle to keep pace with our industry, and those just starting their curricula often set off in the wrong direction because the breadth and depth of our medium can be daunting. The WaSP InterAct curriculum project seeks to ease the challenges schools around the world face as they prepare their students for careers on the Web. … Its courses are divided into six learning tracks that provide students with a well rounded foundation in the many facets of the web design craft.
The group offers its resources to all who need them (to reuse adapt), and it seeks your content and ideas.
That’s important because I don’t add a co-author to any book, let alone this book, lightly. In asking Ethan to help me bring the awesome to this substantially revised and rewritten edition, I chose not only on the basis of expertise and writing ability, but also on sheer karma.
In his new role, Ethan joins a SuperFriends™ line-up including technical editor Aaron Gustafson (Twitter), another honey of a guy, and truly one of the smartest, most innovative, and most knowledgeable voices in web standards, and editor Erin Kissane (Twitter), whose mastery of the subtlest details of voice consistency alone makes her the finest editor I have ever been blessed to work with. Behind it all, there’s Michael Nolan (Twitter), New Riders’ sagely seasoned acquisitions editor and a designer and author himself, who first took a chance on me as an author back in nineteen ninety humph.
Designing With Web Standards, 3rd Edition is coming this year to a bookstore near you. I thank my brilliant crew for making it possible. Onward!
Michael Lopp shares lessons on how to separate office politics from truth when leading a team, and Lyle Mullican explains how the key to faster, more empowering user experience may begin in better database design, in Issue No. 285 of A List Apart, for people who make websites.
[tags]A List Apart, alistapart, database, design, team, building, leading, michael lopp, lyle mullican, webdesign, webdevelopment, development[/tags]
A new answer to the IE6 question?
In “Universal Internet Explorer 6 CSS,” Andy Clarke proposes a novel approach to the problem that has vexed standards-based designers since time immemorial (or at least since we could quit worrying about Netscape 4).
After a brief but thorough tour of current IE6 solutions and their limitations, Andy unveils his zinger. He proposes to serve IE6 users a set of universal styles completely unrelated to the design of the site in question. Not unlike Arc90’s awesome Readability plug-in, the styles Andy has designed concern themselves with typographic hierarchy and whitespace. Here’s the theory: make the page easy to read, make it obvious that somebody designed it, and the IE6 user will have a good experience.
(By contrast, block styles from IE6, as some developers suggest, and that user will have a bad experience. Most likely, in the absence of styles, the user will think the page is broken.)
No hammer fits all nails, and no solution, however elegant, will work for every situation. But if we’re open minded, Andy’s proposal may work in more situations than we at first suspect. Where it works, it’s what business folk call a “win, win:” the visitor has a good reading experience, and client and developer are spared tedium and expense.