The title of this talk, Why Johnny Can't Syndicate, has two antecedents.
First this book, from 1955, by Rudolf Flesch, who wanted educators to ditch the Dick and Jane pablum they were feeding kids and empower them to read classic literature instead -- things like Andersen's Fairy Tales, the Arabian Nights, Mark Twain. Children can read anything, he said, if you give them the right conceptual tools. The critical one he identified as missing, and in need of being taught, was phonics.
Then there's this, from 1999. Whitten and Tygar published an evaluation of the usability (or not) of PGP, which stands for Pretty Good Privacy, a software tool used to digitally sign and encrypt documents.
Here's the question they asked:
"If an average user of email feels the need for privacy and authentication, and acquires PGP with that purpose in mind..."
If an average user acquires PGP? Seriously? That's never happened, it never will, and not because PGP is hard to use, although it is.
The reason is that people lack intuitions about public key cryptography -- its properties, its effects (or potential effects) in the world.
I once interviewed Phil Libin, who's now CEO of Evernote but was then founder of Corestreet, a company with a really clever scheme for validating digital certificates. In our interview Phil made this remarkable statement:
"The basics of asymmetric cryptography are fundamental concepts that any member of society who wants to understand how the world works, or could work, needs to understand. They are as fundamental as the basics of supply and demand and monetary inflation."
Really? I mean, I agree, but how could you ever teach that to most people? Here's what Phil said:
"If you stand in the street and ask people 'Why can't the government just print as much money as it wants?' -- you'll get a rough explanation of supply and demand and monetary inflation in many casese."
Nobody held those intuitions when Adam Smith first came up with them, Phil said, but now most people do. I'll leave discussion of Paul Krugman and the trillion-dollar coin for somebody else's lecture, because I'm even less of an economist than Jon Stewart.
But I can talk about intuitions people do and don't hold about networked information systems. And like Rudolf Flesch, I think there are patterns and principles we should be teaching people -- and I mean everyone, not just those who study computer and information sciences.
Some people use the term computational thinking to describe these principles. It was popularized in a 2006 manifesto from Jeannette Wing. (I interviewed her also.) At the time she was head of computer science at Carnegie Mellon, then she went to the National Science Foundation, recently she joined Microsoft Research. She uses the phrase computational thinking to suggest that the intellectual tools of computer science -- things like abstraction, composition, refactoring, and separation of concerns -- add up to, in her words, "a universally applicable attitude and skill set that everyone, not just computer scientists, would be eager to learn and use."
I agree. And I want to help people learn and apply that attitude and those skills.
Another source of inspiration was Mark Surman, who's executive director of the Mozilla Foundation. In 2008 he gave a talk called "A city that thinks like the web." Mark said that the web's open standards and its architecture of participation is a model for cities too.
I agree. And I reckon that for most people, web thinking might be a friendlier and more appealing proposition that computational thinking.
So I asked myself what kind of exercise could engage people in web thinking on a civic scale. The answer that came back was: reboot the community calendar.
Here's a mosaic of event posters that I found on kiosks and shop windows one day in Keene, New Hampshire, where I live. When I put them all together I saw that the database people had collectively built this way far more comprehensive than what was available in the newspaper's print or online editions, or on the chamber of commerce website, or anywhere else. Except, of course, it wasn't a database. It was just a bunch of posters. You couldn't go online, navigate to Friday January 18 at noon, and see everything that was happening.
What would it look like if you could? Well, here's a step in the right direction.
This is a very different kind of community calendar. It's based on the idea of data syndication, and it invites people -- and cities -- to think like the web. Nobody puts information onto this calendar directly. It syndicates feeds from many sources around the city.
This model involves technical principles like structured data, standard exchange formats, indirection, the publish/subscribe communication pattern. It also involves principles that are technical but also social and political: decentralization, naming, authority, and provenance.
There's an easy way to explain the model: it's RSS for calendars. If you're even slightly technical that's all you need to know. You get that the blogosphere is woven together by a data exchange standard, RSS, that enables any blogger to publish items not only for people to read but also for computers to syndicate. And you'll get the idea that iCalendar, the Internet standard for calendar exchange, could enable us to form an ecosystem of calendar data feeds that works just like the blogosophere, which is to say:
- People and groups publish to their own authoritative online spaces, and subscribe to those of other people and groups
- Everything is published in two ways: as text for humans to read, and as data for computers to harvest and exchange
- Data feeds syndicate to apps on people's computers and smartphones, but also to services that aggregate and refine
That's how I want to reboot the calendar web. I'm doing it in selected cities, including Ann Arbor. And I'm doing it for three reasons:
1. I want to solve an important unsolved problem. It's 2013, we should be able to tell one another what's going on easily and effectively, and we can't. That's lame.
2. I want to engage people in an activity that involves web thinking. What they'll learn will apply more broadly than just to calendars.
3. I want to demonstrate Microsoft's cloud platform, Windows Azure, in an interesting way. The calendar syndication service I've built, which I call the Elm City project, runs on Azure, and aims to show how that platform can scale out to support robust community calendars in many cities and towns. It's also, by the way, an open source project. Here's the github page:
I work with a team at Microsoft that aims not only to promote the cloud platform, but also to surprise people by doing cool stuff that you might not expect Microsoft to do. Like building an open source, open data calendar syndication engine, and helping the under-appreciated iCalendar standard live up to its potential.
Since it's an open source project, by the way, contributions are welcome. The needs include coding, web design, information architecture, curation, and public outreach. If you're interested in any of these things I'd love to hear from you.
I've built syndication hubs for various places including Ann Arbor, Boston, Portland, Seattle, Providence, Toronto, the Monadnock region of New Hampshire, and the Hampton Roads region of Virginia. And I've populated these hubs with all the iCalendar feeds I've been able to find -- or in some cases, synthesize. (Facebook calendars, for example, don't provide standard iCalendar feeds, so I use the Facebook API to synthesize those feeds.)
The results are fairly robust. I found 300 feeds for Ann Arbor, 600 for Seattle, 800 for Boston. Here's a picture of everything I found for Ann Arbor on the day last September I did a workshop at the public library.
It's a lot. In Ann Arbor and elsewhere, these calendar hubs can know more about what's happening than any individual source because they merge information from many sources. But they don't know nearly as much as they could. Why not? Most web calendars still aren't available for syndication.
Dave Askins, the editor of the Ann Arbor Chronicle, is the first media partner I've found who's willing to try to change that by flipping the existing model on its head. In the existing model, which prevails almost everywhere, you promote an event by emailing the information to a publisher, or by registering on their website and typing your stuff in. You do this once per event and also once per publisher because there's often more than one place you want your stuff to appear.
I call this the Submit Your Event dilemma. Here are some local examples.
And here's why this is a dilemma. Imagine that you want to publish a web page, but to do it you can't just put it up on your own site, you have to take it to somebody else to post on their site. If that were the web's architecture of participation, we wouldn't have a web. But that is the architecture of the calendar web. And it's why we don't really have a real calendar web yet.
There are loads of web calendars, it's true. Most groups and organizations do publish calendars to their own websites, blogs, and Facebook pages. They do it so people will find out about their events, and attend them. And sometimes it happens that way.
But if they want their calendars to show up in other contexts, they have to play the Submit Your Event game and manually transfer their data, one event at a time, into each of those other contexts.
What's the alternative? Publish a calendar data feed. More specifically, use a calendar app or service that does two things at once. First, it publishes a human-readable version of the calendar to your web page, your blog, or Facebook, for people who visit those places. Second, it also publishes a corresponding machine-readable iCalendar feed. The feed enables people to subscribe directly to a calendar, in their desktop- or cloud-based calendar apps, or on their phones, and get automatic reminders about events. The feed also enables a calendar to show up automatically in other contexts -- like the Ann Arbor Chronicle -- without having to retype what's already on the site.
What apps can do this? Look no further than Google Calendar. Or Hotmail Calendar, which I mention partly because I'm a Microsoft guy but mainly to make a point about standards and interoperability. Both the Google and Microsoft cloud-based calendars meet all my requirements: they manage calendars, they publish human-readable widgets into web pages, and they also publish iCalendar feeds that will work with any standard calendar program or syndication hub.
So, for example, here's a calendar page on the City of Ann Arbor's site:
They've embedded a Google Calendar on the page. It corresponds to an iCal feed at some alternate URL, which Dave Askins captured and added to the Ann Arbor Chronicle's calendar hub. So now this morning's Winnie the Pooh event, published by the city on behalf of the Leslie Science and Nature Center, shows up automatically in the Chronicle's calendar:
What's not to like?
Well, a couple of things. For starters, let's consider the provenance of this event. The Leslie Center isn't the City of Ann Arbor, it's a non-profit, with its own website, and here's the calendar page on that site:
And for that page, there is no corresponding calendar feed. The Leslie Center's site is served up by a content management system called NeonCRM, which describes itself as "a connected, multi-channel, cloud-based CRM database for nonprofits." And yet, when you publish a calendar using NeonCRM, you don't get a corresponding data feed that enables that calendar to syndicate around the web.
I'm sorry to tell you that this is the rule, not the exception.
Now if you poke around, you might be fooled into thinking that the Leslie Center's calendar is syndicating around the web, because look, here it is on Facebook.
And here it is on a site called NatureFind, which promotes nature-related events.
But these echoes of the event aren't examples of syndication. It's the Submit Your Event dilemma again.
The Leslie Center's own calendar page is, or anyway should be, the authoritative source for the event. So of course they posted the event there. But then somebody had to post again to Facebook, and again to NatureFind, and again to the city's site, where, finally, there's a feed available that can syndicate to the Chronicle and elsewhere.
It's nice that the Winnie the Pooh event can show up automatically in the Chronicle. But Dave Askins would rather syndicate it directly from its authoritative source -- the Leslie Center. And the Leslie Center would want that too, if folks there knew it were possible to post events to their site that would syndicate to Facebook, NatureFind, the city's website, the Chronicle, and elsewhere.
Part of the challenge I face is that, for various reasons, the Leslie Centers of the world don't know that's possible.
Consider NeonCRM. Why would a content management system that enables its customers to publish calendars, with the goal of widely disseminating those calendars, not provide them in the Internet standard format for calendar exchange?
I'm not singling them out. As I said, this is the rule rather than the exception. As I've worked on calendar hubs in various cities I've run into a bunch of content management systems that do web calendars without feeds. They include Constant Contact, Virtual Towns and Schools, SchoolWorld, ChamberMaster, HighSchoolSports, and Granicus.
The City of Ann Arbor, by the way, is a Granicus customer. The company offers a legislative management suite, called Legistar, that the City uses to manage its official schedule. Here's that schedule on the City's website:
Maybe you can guess the punchline. There is no iCalendar feed! So while the Chronicle would love to syndicate this calendar, it can't. Legistar does offer an RSS feed, but that's not the same thing, it's actually a category error -- a very common one I'll discuss in a bit.
When I ask these vendors why they don't support standard calendar feeds, they all say the same thing: "Customers aren't asking us to do it."
Given the benefits to customers -- you only type your information once, it syndicates automatically into other contexts, you know that any changes will automatically ripple through the network -- the question I ask myself is: "Why aren't customers demanding this?"
It's a classic chicken-and-egg problem -- and more specifically, a classic network bootstrapping problem. People don't expect to participate in ecosystems of calendar feeds because, for the most part, those ecosystems don't yet exist.
Why not?
Partly because, although iCalendar has been an Internet standard since 1999, and it's baked into familiar products like Outlook, Google Calendar, and Apple iCal, it hasn't been implemented very reliably at the margin.
My service sees feeds from hundreds of calendar-producing systems. Predictably they form a long tail distribution:
Google Calendar is far and away the most popular. But out on that long tail you see all kinds of things. One of my favorites is "Kennedy Space Center Launches by Chad." What I've found, though, is that a lot of feeds from these boutique producers don't work well, or even at all.
In response to this problem I launched a companion project, the iCalendar Validator, inspired by the RSS/Atom Validator created years ago by Sam Ruby and Mark Pilgrim.
One of the things that helped the blogosphere boot up was the simplicity of RSS. Anybody could, and a lot of us did, whip up RSS feeds for all kinds of data sets, and that grassroots proliferation of feeds created network effects. But the low threshold for participation also resulted in a lot of junk. So Sam and Mark built the validator, which combined an RSS parser with a ruleset based on the RSS spec and a lot of practical experience with real-world feeds.
Here's what it says about my WordPress blog's feed. The feed it's valid, but there are a few things that WordPress could tweak to improve it.
The iCalendar Validator works the same way. It's a collaboration between me and Doug Day, who also wrote the open source iCalendar library that the Elm City service uses. (When I say we collaborated, by the way, I mean I had the idea, and Doug Day did all the heavy lifting, with a bit of help from me around the edges.
The iCalendar Validator is an open source project too, by the way, it needs some work, and we'd love to have help. If you're interested, or know somebody who might be, please do contact me about that.
So, here's what the iCalendar Validator says about the Ann Arbor Public Library's calendar feed. It's squeaky clean! That's rare, though. In most cases the iCalendar Validator, like the RSS Validator, reports some deviations from the specification, and offers advice on best practices.
If the iCalendar ecosystem is going to thrive, it's crucial that folks like Chad at the Kennedy Space Center can whip up calendar feeds for all kinds of time-ordered datasets, and know those feeds will work with a wide range of other iCalendar apps and services.
But broken feeds aren't the root of the problem. The brokenness is widespread, and persistent, because for the most part, nobody's using calendar feeds. I run into this all the time. Here in Ann Arbor, for example, the Arts Alliance has a website with this calendar:
The good news is that their web publishing system uses a component, called JCalPro, to produce an iCalendar feed alongside the calendar page you see here. The bad news is that the feed is broken. Something's misconfigured in the server, the feed comes out malformed, it just doesn't work.
Here's the even worse news. Nobody at the Arts Alliance knew there was a problem. Why not? First, nobody there knew that the system was even supposed to produce a valid iCalendar feed. And until Dave Askins came along and tried to use it, nobody had noticed it was broken or reported the problem.
This looks like a technical thing, and in a way it is, but more fundamentally it's a human thing. People and organizations don't expect to participate in networks of data feeds. I think we need to raise that expectation, I'm trying to do that, and along the way I've come to some conclusions about why people almost universally don't expect things to work this way.
I think it boils down to this. We've been walking around on planet Earth for more than a million years, experiencing the physics of the real world. In all that time, things have always worked the same way. If you're making a collection of shells, and I want to add my shell to your collection, I have to bring it to you, and give it to you, so you can put it in your bucket of shells.
About 20 years ago something new became possible. If you're making a online collection of items, and I want to add an item to your collection, sure, I can give you a copy, and you can put it in your online bucket. That's how we've always done it, and it's how we mostly still do it.
But the web's physics are different. Instead of handing you a copy, I can hand you an indirect reference -- a link that connects your bucket to my bucket. Now we both have the use of the item. And this arrangement has other nice properties. Mine is the authoritative source. If I change it in my bucket, your bucket sees the change too. And yours isn't the only other bucket it can be in. It can show up in other peoples' buckets too. But I still control it. And when I change it, everyone sees the change.
Here's a little exercise I do in workshops to drive home this point. I'll need some audience participants. OK, here's your bucket, and here's yours, and here's mine. I'm going to take this shell out of my bucket and put it in your bucket. Congratulations! Now it's in your collection. I don't have it, and neither does she, but we can go to your bucket to see it.
OK, now here's another shell in my bucket. This time I'm going to leave it there. But I'm going to link it to your bucket and also to her bucket. Just by saying so. Just by declaring that there's a relationship among our buckets that involves this shell.
For those of us in the computer and information sciences, that virtual connection is just as powerful as the physical one. In fact it's more powerful because in a syndication network things can seem to move around, and can be available in many contexts, while remaining tethered to their authoritative sources.
But that's an intuition we've developed because we use indirection every day. When we write software we decide whether to pass parameters by reference or by value. When we build web information systems we weave them together with links. We do this stuff all the time, so we take it for granted.
What I've learned working on this project is that you can't take it for granted. Most people lack intuitions about the properties of indirection, and they lack a bunch of other intuitions too.
For example, the concept of structured data is utterly foreign to most people -- including most well-educated professionals. That's why, to this day, a lot of calendars up on the web are PDFs. The high school in my town still does it that way.
When I talked about this with the principal there, I realized that for him, a PDF file wasn't essentially different from an HTML or XML or iCalendar file. To him these are all just computer files with different filename extensions, basically interchangeable.
But of course there's a huge difference. Some formats, like HTML and PDF, are for people. Others, like XML and JSON and iCalendar, are for machines. I wish my town's high school, and other schools, understood -- and taught -- the difference between structured and unstructured information.
You'll be glad to know, by the way, that the Ann Arbor public schools are a shining example of doing the right thing the right way, and I saluted them in a blog post. Every school in Ann Arbor has a web calendar that syndicates:
The Slauson Middle School is highlighted here because they get extra credit for self-categorizing their feeds. Here's the Slauson calendar:
Notice how they're using multiple instances of Google Calendar to separate sports, music, and clubs. This is a great strategy for both internal and external reasons. Internally it invests authority in the right people. There's no bottleneck at the desk of some poor web calendar clerk. Instead of playing the Submit Your Event game, the sports and music and club staffers can manage their respective calendars -- as they naturally do anyway -- and then syndicate them to the school-wide calendar.
From there the events can syndicate externally to community-wide contexts. A concert at the middle school is, after all, part of the musical life of Ann Arbor. It should be able to show up automatically on a community-wide calendar, and what's more, it should be able to show up in the right category: music. And it can, because the Ann Arbor schools are thinking like the web.
Among the "broadly applicable skills" that Jeannette Wing said everyone ought to learn and apply, she listed the ability to use appropriate representations, and to separate concerns. Here we see those skills being applied in the wild. It's a great example that I wish schools everywhere would emulate.
Nowadays I include a slide like this in workshops:
I do this because people don't intuit that you need a structured format, like iCalendar, to reliably represent an event's title, location, date, time, and timezone. That's partly because people falsely intuit that computers can figure that stuff out by looking at the unstructured text on a web page or in a PDF file.
But computers can't do that. In general we need to structure the domains in which they operate. And that's another core principle everyone needs to understand.
Notice, by the way, that RSS shows up here in the human category, not the computer category. That's because although RSS can be used to exchange structured data, it rarely is. In almost every case where I've found an RSS feed on a calendar page, its contents are the same unstructured stuff that shows up on the web page. That means you can't automtically and reliably extract dates, times, and locations. So while it's a kind of feed, it's not the kind that enables calendar syndication. That's why, when people point me to their RSS feeds for that purpose, I call it a category error.
About a year ago, in a blog post, I boiled down the principles I'm talking about here into this list of seven ways to think like the web.
It's my version of Jeannette Wing's principles of computational thinking, as filtered through my experience working on the Elm City project. In that post I showed how participation in an Elm City cale ndar hub -- as a contributor or a curator -- helps people learn and apply these principles.
Here's the big picture for calendars. Every group and organization has its own, and publishes it on its own website or blog or Facebook page. It's available as HTML for direct constituents to read when they visit those sites, and also as iCalendar feeds that can syndicate directly to their computers and phones.
Nothing's categorized here, this is just an undifferentiated set of feeds, the same way the web is an undifferentiated set of pages.
But the curator of a hub can define views over that set of feeds, by applying tags like music, health, or sports.
Today, in Ann Arbor, there's just one hub: the Chronicle. And that might be enough for Ann Arbor. In a bigger city, though, you could end up with a set of hubs, each specializing in a cluster of categories.
The model scales out even farther too. In Connecticut I'm working with some state government people who want to consolidate the tech/business scene statewide. Suppose you're a startup in Hartford that's hosting a hackathon. If you only put it on your web calendar, and socialize it on Facebook, you'll only reach those immediate constituencies. That won't get you onto Hartford's community-wide calendar or into Connecticut's statewide tech/business hub.
If you also provide a feed, though, and if the city and state are participating in syndication networks, you can join those networks and syndicate to those contexts.
Right now, for Ann Arbor, there are more than 4000 events on the Chronicle's calendar. That's a lot, but it only scratches the surface. Most of the web calendars out there that can't yet syndicate. Here's just one example:
Tomorrow afternoon, MakerWorks is offering a class on using its CNC embroidery machine. (I've been down there and seen that machine, by the way, it's really cool.) It doesn't show up in the Chronicle, though, because the Maker Works site doesn't yet provide a feed. And it doesn't show up on other community calendars -- ArborWeb, AnnArbor.com -- because to put it there Maker Works would have to retype what it's already typed up for its own site. In most cases that's way too much friction, people just won't do it.
This is the dark matter and dark energy of the calendar domain. If we lit it up we could easily promote, and easily find out about, every bird walk, every frisbee game, every middle school concert, every lecture, you name it. We could subscribe directly to feeds about things we care most about, and we could visit a comprehensive community calendar to find out about things we hadn't thought of.
This would be an economic boon to the city, as well. Consider this item from the Chronicle:
U.S. News and World Report says that Ann Arbor's vibrant cultural scene makes it an attractive place to retire. With a truly comprehensive calendar that knew about everything going on, it would be even more attractive, and those folks have more disposable income than students. I bet there's a retired person who would love to spend 50 bucks on a CNC embroidery class, for example.
OK, enough about calendars. I said that this model applies in other domains, so let's look at some variations on our theme.
There's been some recent controversy in my town about a couple of dams. One contains the Robin Hood reservoir you see in this picture, the other one is on the Ashuelot river at West Street.
A couple of years ago the city received letters of deficiency from the state about these dams. Since then there's been debate about both of them. Do we really have to spend $600,000 to remediate the Robin Hood dam? Should we remove the West Street dam or upgrade it?
Documents relating to these issues live in various places, including the state's website, the city's website, and the newspaper's website. There are also some conversations swirling around on blogs, Facebook, and Twitter. When you're trying to reason about public issues like these, you'd like to be able to gather all the related materials. But the usual way to do that involves a now-familiar pattern. Somebody declares one bucket to be authoritative, and everyone else has to put copies of their stuff into that bucket.
I proposed an experiment based on a protocol that's worked well at technical conferences for a long time, and more recently at some kinds of conferences I've attended. This is the protocol. As part of the introductory housekeeping, you announce a tag for the conference. Everybody understands that if they attach that tag to their conference-related Flickr photos, and blog posts, and social bookmarks, then the conference organizers -- or the attendees, or anyone else -- can gather all that stuff together. There's no privileged bucket. There's just an agreement to interconnect a lot of different buckets in a particular way.
I was surprised, and pleased, when the City of Keene decided to give this experiment a try. Here's their intro to the Keene Tagging Initiative.
Here they suggest a couple of tags to coordinate discourse about a couple of issues. The tag for the West Street dam conversation, for example, is weststdamkeene.
The city likes this idea because it wants to encourage discussion of issues, but doesn't want to own that discussion. If people write about issues on the city's website, the city has to moderate the comments. Then maybe the city becomes liable for retaining them as part of the public record. They like the idea of a more loosely-coupled approach: a syndication network that enables people and groups to state their positions on an issue in their own online spaces, and then enables the city -- or anyone else -- to gather those statements from their various sources.
I love that the city and the newspaper agreed to use the same tags, so that documents about the dam project on the city's site, and articles about the project on the newspaper's site, can be reliably found and brought together, as we see here.
That's possible because both the city and the newspaper use content management systems that enable them to tag certain things with weststdamkeene. But it's an unusal string of characters, so it's aso effective in an open web search, as we see here, where Google and Bing find related items all over the place, including my blog.
Now to be honest, this hasn't caught on in a big way. But Ann Arbor's a hipper place than Keene, so maybe give it a try here and see what happens.
Here's a different scenario for data syndication: health care. A year ago a family member was in a car accident and landed in the hospital. Fortunately we're insured, and everything's OK. But I'm still trying to untangle the bills.
The players in this game include several insurance providers (auto and health) and several health-care providers (the hospital, the clinic). None of them talk to one another. They send messages through me, and those messages are pieces of paper, or digital images of pieces of paper: faxes, PDFs.
In their separate systems of record the data is all structured, of course. It could form a syndication netwrok. Every player in this game could be an authoritative source for their own items, and an authorized router for other players' items.
I'd like to syndicate all the bills, x-rays, medical records, and appointment calendars directly from their various sources into a cloud-based service that receives and relays these things on communication channels that I name and authorize. Then I'll be in a much better position to make sense of this mess. The healthcare providers, for example, don't know which of the bills they send me relate to the accident. Nor do the insurers know that about the bills they receive.
Businesses love to talk about having One View of the Customer. But we customers typically engage with many businesses in the course of what is, from our point of view, one business process. It's a decentralized game with many players, and the only referee is the customer. Only we can create the One View that we need. Today we have to do it the hard way. We sit in the middle of a pile of papers, we make phone calls, we take pictures of documents and send them to people who bury them in their own piles, you probably know the drill.
I want things to work differently. I want to manage my affairs by syndicating, tagging, and republishing data feeds. Now I grant you that's a tall order. It presents all sorts of technical challenges. But trust me, those are solvable, I don't worry about that. I worry more about the human challenge. We won't get the right kinds of solutions unless customers demand them. I want to raise expectations about what's possible so that people will demand them, and I want to teach people how to be web thinkers so they'll demand the right kind of solutions.