Archive: February 8th, 2006

So, now it’s time for Q&A. By the way, nobody has cried Bingo. Also, get 20% off all Rails books using the code: web2020.

First, an announcement from Steve Olechowski from Feedburner. He’s launching an open API for FeedFlare.

Onto the panel.

Question: “Many web apps are very specialised. Is the future of the web about focused tools?”

Cal: Yes. Small tools loosely joined. But who knows what Web 3.0 will bring?

Steffen: Everything should be integrated: addresses, events, emails. They all have timestamps.

Ryan: How do we solve the identity issue?

Cal: Microsoft Passport (joking). Microsoft is working on something better.

David: The problem is over-rated. Most people use the same password. There’s your identity.

Joshua: Do we need the whole username/password paradigm anyway? Don’t confuse authentication with identity.

Tom: The problem is with multiple registrations. Loads of forms to fill in, like 30 boxes.

Question: “Given that Ajax allows user interaction comparable to desktop apps, should Ajax apps be designed like desktop apps?”

Joshua: I think we’re going to see desktop apps that look more like web apps, especially with the new Microsoft equivalent to SVG.

Tom: There’s a profound difference between the silo of the desktop and the Web, which is addressable.

Steve: There are a whole class of users now who are used to the Web, more than desktop apps.

Ryan: Then surely we are moving towards a model where either the browser becomes the platform or your platform becomes the browser. For instance, in Opera 9, you can build on the browser.

Tom: The boundaries will blur.

Steve. Paradigm shift. Zing.

Question: “How do you decide on a pricing model to monetize your product?”

David: I like what Ryan said in his talk: what would you yourself pay? People will pay more for a service they like, even love.

Shaun: I set up a barrier for entry so that savvy users get through. A price point helps.

Question: “How much re-engineering did you have to do to scale up?”

Cal: Flickr is still in beta. We refactor every half hour.

David: Beta is bullshit. Everything is beta. Web apps are never done.

Question: “Frequent and early releases seem to be a mantra of new products. How do you know when you’ve got enough to launch with?”

David: If you can use it every day, if it’s useful, release it.

Steve: You get a lot of good feedback by releasing early.

Ryan: How do you predict how many users your app will attract?

Steve: You can’t know.

David: No idea.

Joshua: I did del.ico.us on the side. I think VCs are useful for connections, not just funding.

David: Building a business with the money you’re getting in from the business has never been easier.

Question from the floor for Steffen: “Were you influenced by map.search.ch when making Google Maps?”

Steffen: Actually, I didn’t do all the Google Maps stuff. Speaking of maps, if you want to build an interactive web application and think about how to do it, it’s a natural evolution.

Question from the floor: “There’s nobody here from Microsoft. What are they up to?”

Apparently, they’re scaling back on their RSS promise in Vista.

Steve. Paradigm shift. Zing.

Question from the floor, related: “With IE7 and Vista on the horizon, is Web 2.0 happening because of a technological shift or paradigm shift? Zing.”

Tom: There’s always dominant metaphors. A few years ago it was computers, then networks. Now it’s on the web: social networks, connected services, and so on. But Web 2.0, whatever the hell that means, isn’t technology dependent.

Steve: For me, Web 2.0 is about very atomic applications. It’s taken us years to figure out how to use XML well.

Tom: Every few years, we rediscover what was so good about the Web to begin with… like good URLs (I think Tom is bang on the money). We also have successful poster children, like Flickr.

Question from the floor: “A few years ago, the buzzwords were web standards. Today, nobody said accessibility (he’s wrong, by the way: Andrew Shorten mentioned it). So, when building Web 2.0 apps, what are your experiences with accessibility?”

Ryan: Oh, shit.

Tom: Spirals. Ajax. Confusion. Awkwardness. A drive for standards combined with envelope pushing. We’re heading for a transition point.

Ryan: The simple answer is: of course, accessibility is important but in the real world, blah, blah, blah.

Steffen: You can make inaccessible pages by throwing text-as-image online. You can make Ajax apps accessible because it’s basically text.

Question from the floor: “With all these web services living on top of each other, are we going to have licenses that live on top of each other? Services that rely on other services: what are the legal ramifications?”

Joshua: People used to build stuff before there was even an API. The API is like a contract, but not a legal one. We’ll see more stuff connected with no legal binding whatsoever.

Tom: I don’t agree. If you’re building a business on someone else’s APIs, you have to know that it’s secure and solid. You need some kind of terms of service, even if it’s not lawyers talking to each other across a table. Nobody has thought about this issue much.

Question from the floor: “There seem to be two kinds of web apps: up-front payment or ones where you must wait for critical mass. How do you strike a balance?”

Tom: It’s easy to spot the ones that need a critical mass: they’re the social networks.

David: I don’t think ad revenue is a good model. I think it’s better to provide value directly.

Follow-on question: “If Flickr charged from the start, would it be as successful as it is today?”

Cal: Probably not. As Tom said, with social software, you need a critical mass.

Ryan: That’s it.

This is going to be a reality check about Ajax from within Google. Let’s strip away the hype.

First, the name, as mentioned before, is bad but… it’s better than no name. It boils down to Client Side Scripting (but the acronym CSS was taken). If you’re doing client-side scripting on the Web, that means JavaScript.

Steffen says paradigm four times. Buzzwordtastic.

With Ajax, sophisticated user interaction is now possible. Also, state can be persistent because the page isn’t reloading. Server Side Session State was created by lazy programmers and it causes a lot of trouble. It expires, always at the wrong time. It’s okay for one server, but doesn’t scale well for server farms. Steffen’s got a real thing about SSSS. For him, that’s one of the best things about Ajax.

Web applications are like pop music compared to the opera of real software engineering.

What’s in Ajax: CSS, DOM and JavaScript.

CSS layout is the equivalent of a politician’s election promise.

The Document Object is the programming interface to a web document. It’s all about the nodes, baby. He doesn’t like the naming conventions of the DOM. nodeName, nodeType and nodeValue are prefixed with the term “node” but parentNode and childNodes are suffixed. There’s nothing in the DOM script about how to handle partially rendered documents. Ah, it’s the old onload problem.

JavaScript is the central technology. It had a bad reputation - deservedly so, says Steffen. The fact that semicolons can be omitted is a nightmare.

The situation sounds bad but look on the bright side: what doesn’t kill us makes us stronger.

Seamless integration (between client and server logic) is trumpeted as a good thing. But think about your clothes: seams are actually a good thing — they give form.

Cross browser incompatibilities force you to create good robust libraries. Now he’s reaching.

He’s off an a rant about browser inconsistencies with event handling.

Okay, now that he’s done dissing JavaScript and the DOM, he’s going to rehabilitate them. JavaScript is really a pretty darn nifty programming language. It’s been described as Lisp with C syntax.

Steffen would get on well with Douglas Crockford.

Now he’s talking about how great closures are for function scope.

But here comes Ryan, stage right. All he needs is a long hook to drag him off. Steffen is rushing now through his final points.

“Don’t build a framework! The browser is a framework!”, he cries as Ryan drags him off.

Ryan will talk about how to build a web app on a budget.

You don’t have to be big anymore. Remember boo.com? You don’t need that kind of silly money.

Why now? Why hasn’t it happened before? Broadband is one factor. People are also more comfortable with web apps: they aren’t freaked out. Hardware is dirt cheap. Open source software is even cheaper.

What is Enterprise? Let’s say mass market or 1000+ users.

What is Dropsend? It’s a service providing a way of storing and sending large files online. It has 9,500 users in less than 2 months. There are desktop apps that use the Dropsend API.

The most important thing, he says, is making sure the idea is financially viable. Would you pay for it? Be cautious about your projections. It’s a guessing game. Can you get by on 60% of your realistic projections.

Acquisition, my ass! Don’t bet on it. It’s a dumb business model. It’s not a sure thing.

As for all this “is this another bubble?” talk: bollocks.

Onto the budget. Every project is different. Here are the stats for Dropsend:

• £5,000 for branding and UI design by Ryan Shelton.
• £8,500 for development from Plum Digital Media.
• £2,750 for desktop apps.
• £1,600 for XHTML/CSS.
• £500 for hardware.
• £800 a month for hosting and maintenance from BitPusher.
• £2,630 for legal stuff.
• £500 for accounting.
• £1,950 for miscellaneous stuff (travel, etc.).
• £250 for a trademark.
• £200 for a merchant account.
• £500 for a payment processor.

Total: £25,680 (hmm… did £500 go missing somewhere?).

When you’re building a team, don’t go for the rockstars. Go for the quiet guys; they’re cheaper. Ask friends for recommendations. You could try outsourcing but it didn’t work out for Ryan when he tried outsourcing to India.

Now, what about scalability?

Ryan recommends buying just enough hardware to launch. Basecamp launched with just one server, for instance. Wait to see if your app is successful before you throw a lot of money at it.

Build scalability into the architecture of your application. Think about it ahead of time so you don’t have to take everything offline for a week. Plan, but don’t obsess.

How do you keep it cheap?

Don’t spend money unless you have to. Don’t buy stationary. Ryan got Dropsend stationary for £1,000. That was dumb.

Don’t get new shiny machines: just say no to Macs, says Ryan.

And no luxuries! You don’t need that company car. Before you spend £25, ask yourself if you have to. No froo-froo features in your app either. Bah! Humbug!

Pay people with percentages of your company (or pizza), advertise on your blog, use IM instead of phone calls, sell your body… he didn’t really say that last one.

Shop around. The first quote he got for hosting was huge.

Pessimism has its place. You will go 10% over budget: plan for it. You will go 3 months over schedule: plan for it. Put it into your cashflow and see if you’re still in business.

Holy crap! Lawyers are expensive.

• £1,00 for terms of service.
• £800 for freelancer contracts.
• £15 for a privacy policy

Cheap software is your friend. Get a £200 linux box for your dev server.

Don’t spend any money on marketing initially. Use blogs and word of month. Build viral shit into your application so it tells people about the service. Writing is a great way to raise profile. So is selling your body.

What about venture capital? You might need it if you need to scale or expand very quickly. But, these days, you need a really, really good reason to go to a Venture Capitalist.

To summarise:

• Don’t spend money unless you absolutely have to.
• Barter for services (sexual favours, for instance).
• Cut features so you can build quickly.
• Be realistic, even pessimistic about cash flow.
• Plan for scalablity, but don’t obsess.

Ajax and Flex share a lot of Web 2.0 themes. They both create engaging experiences with compelling user interfaces. They share the same standards: HTTP, XML, ECMAScript.

Andrew from Adobe says Ajax is limited by the browser environment. There aren’t many UI components. Developers must test across lots of browser/platform combinations.

Flex gets around that by circumventing the browser and targeting the Flash player. Flash has become a real platform. It’s still used as an expressive medium but also more and more for video. It’s also good for end to end communications: training, meetings, etc.

Flex is a framework, unlike the Flash authoring tool which is fine for movies and timeline-based stuff. Flex is for developers. You use MXML, ActionScript, CSS and a library of classes (UI containers, controls, drag’n’drop, etc.).

Here’s a live demo of something he cooked up this morning using the Flickr API.

You can view source!

After demoing a few pure Flash examples, he brings up Measure Map which mixes Flash and Ajax.

The Flex SDK is being made available completely free of charge. The Enterprise Services server is free for a limited number of uses; enough for small businesses. The Flex Builder IDE will cost less than $1000.

Ajax may be enough for you. Flex is an alternative if you are frustrated by the browser.

Visit Adobe for downloads.

What is an API? A documented means of interacting with one application from another. A successful API obscures the storage format and the details of the retrieval process.

Who has an API? Everyone here today and then some.

Who is using these APIs? Who isn’t? There’s websites, desktop apps, dashboard widgets, etc.

Shaun gives ten reasons to use APIs.

1. Increase brand awareness. Early adopters are technophiles. Give ‘em an API and you’re empowering them. They’ll talk that up. It builds buzz.
2. Allow users to own their own data. You’ll feel more comfortable knowing that you can take your data with you at any time (just as Cal discussed with third-party DVD export from Flickr).
3. Build goodwill with developers.
4. A perfect excuse for a community. This ties in with the brand awareness. Acquiring and sharing API knowledge pulls people together.
5. Solving programming problems with an API can improve code quality.
6. Simplify internal reuse of data.
7. Allow others to extend the functionality of your application. People can use an API to add functionality that you’re not interested in doing yourself.
8. Alternate input mechanisms. Allows for desktop software for entering data.
9. Unanticipated applications of your data. Like the Grey Album: mashing things up in unexpected ways.
10. Turn your program into a platform. This is the key reason.

Questions?

What is Mint? Stats tracking.

What font are you using in your slides? FF Din.

What kind of API is Pepper? Plug-in rather than web service.

How quickly after releasing Mint did you see Peppers? Really quickly.

How can you make an API attractive to developers? You must have a service that is attractive. Find your own itch and scratch it, then you know the requirements of the API.

Once you release an API, how do you make changes to it? Shaun hasn’t really had to address that yet. But he talks a lot in the forums with developers.

Without ShortStat, would there have been Mint? Probably not.

How have you dealt with piracy and the fact that the code is “open” (as in viewable)? First, it was just some comments in the code. That worked for a while. Ideas are being tossed around on the blog. How about a Firefox extension that checks if Mint is installed on the website being used and, if so, find out if it’s licensed and call back to the mothership.

This one will be more geeky: code contained herein.

The silver bullet of making applications is motivation. It’s the key to productivity. We should promote motivation. Motivation comes from happiness. Optimize for happiness. But how?

David didn’t used to be a happy programmer. He liked the end result, but not the process. The key factor to happiness is beautiful code.

Your application is not a beautiful snowflake. You are not special. Most of the work you do revolves around the same mundane details as everyone else.

Convention over configuration: because 80% of what you need to do is the same as everyone else. The 20% lets you be a beautiful snowflake for a brief moment.

Beautiful code is succinct and doesn’t repeat itself. In Ruby, configuration is very, very succinct because classes map to database tables. It’s a pattern that’s been abstracted, saving explicit configuration. The same goes for the primary key: it’s the same name, “id”, for each table so there’s another convention right there. There’s another pattern for foreign keys so that’s abstracted too.

But it’s convention over configuration: not never configure. If you need to do something outside the convention, that’s fine too. The assumptions come from conventions, but the exceptions are handled by configurations.

Another convention: matching names from the server to names on the client. The first part of a URL maps to a class; that assumption derives from a convention.

Flexibility is over-rated. You’re trading flexibility for productivity. Stop chasing it so religiously. Correspondingly, constraints are liberating. It encourages consistency. You don’t have to worry about naming things and mapping classes.

Do the right thing. Developers have a little angel over one shoulder and a little devil on the other. The environment determines the size of the devil or angel. The devil tempts you, telling you to leave stuff ‘till later. The angel is telling you to test. The angel wants you to follow best practices. PHP is the devil: constantly tempting you to the quick, ugly hacks. Ruby on Rails is the angel. The angel is embedded in RoR.

In Rails, you have to go out of your way to do something ugly. Test files are automatically created. Invitations to do better are embedded. You are constantly reminded of what you should be doing.

You are also given opportunities. You are encouraged to see the correct relationships between classes/tables: those relationships are exposed.

Expectations are also embedded. You are expected to use best practice. The community questions the way things are coded: is this the best way?

Sometimes the beautiful thing is to get out of the way.

When should you use Ruby on Rails? When you feel the hurt. If you’re not annoyed by the devil whispering in your ear, you’re probably not ready yet. But you will feel the hurt. Then you’ll be ready.

Are you overburdened by complexity? Do you appreciate agility? Do you appreciate testing? Rails is for you.

Q. Does it scale? A. Yes.

Tom begins by pointing a laser at Simon and thanks Andy for calming him down. Aw, bless.

User interface: most people think about rounded corners and gradient fills. He shows lots and lots of examples. But Tom’s going to talk about higher-level stuff than that.

• What is the web changing into?
• What can and should you build on top it?
• Architectural principles for Web 2.0

Web 2.0 has way too many ingredients. Let’s concentrate on the web of connected stuff: APIs and data. The web used to be silos of information. Now it’s a huge accumalation of testicles: well, that’s what the diagram looks like. A web of data (sources and services) and how people can use them.

Here’s a mashup of Astrology and News made by Simon and Tom. Browse the news by “things that happened to Capricorns”, for example. Compare what was supposed to happen to someone with what actually did: very good for obituaries.

That’s what mashups are all about. Taking two data sources and mashing them together in a way that makes both things more interesting. You get a network effect of services.

Every service builds on top of the existing web of services and contributes to the network. No-one needs to make the same thing twice.

There is money to be made. You can use APIs to drive people to your stuff. People will do work that, in the long run, drives people to your stuff. Soon, we may see more people charging for APIs.

Here’s the question developers must ask: “How can I add value to the Aggregate Web?”

A war is about to begin about the ownership of core data: location, identity, calendaring, etc. Tim O’Reilly says “Data is the new Intel Inside”.

Ask yourself, “Can I find new ways of connecting users together?”

When you’re designing an app, start designing with data, not with pages. Design for normal users, developers, and machines.

Like the previous two speakers, Tom really emphasises the importance of readable, writable, hackable URLs. Be predictable/guessable/hackable and as human-readable as possible. Good URLs are beautiful and a mark of design quality.

Three core types of page: the core object destination page, the list view page, and the manipulation interface page. Ajax and Flash are great, but don’t break the Web. Right on, Tom!

Building on top of the core pages, you can have parallel views, for example in XML and RSS.

Tom’s slides will be available on his site.

Cal talks about less geeky stuff than Joshua.

Flickr — which turns two this week — has a lot of passionate users. Flickr was built out of passion, not for money. People say they want all sorts of things, but look at their behaviour instead (just like Joushua said).

So, what is Web 2.0? Let’s look at ten things.

1. Collaboration. Flickr started as Game Neverending, a MMORPG. That morphed into Massive Multiplayer Online Photo Sharing. Tagging is collaborative metadata. Everything’s is based around the social network.
2. Aggregation. Things on the Web used to be stored in separate silos. With aggregation, you can slice data by time, tags, even interestingness. It’s not just about the ten most recent things on a site.
3. Open APIs. Flickr and del.icio.us have had them from the start. Flickr built theirs to use themselves for their own Ajax functionality. Then they released it openly. A simple API can be read only: different ways of looking at data. Writable APIs are a step beyond. Now you’ve gone from web site to web application to web service. People can build the stuff that you don’t have the time or inclination to do. Fastr is a good example. If you don’t provide an API, people will build stuff anyway but it will harm you: screen scraping, etc.
4. Clean URLs. There’s no need to expose the guts of your app in URLs. Instead make them work in the way that users use the site. mod_rewrite (which Joshua also talked about as a black art) is very, very useful for this. People will be able to hack URLs if they’re clean. URLs cannot change. Ever. If you change your naming scheme, you must support the old scheme forever.
5. Ajax. “Asynchronous JavaScript And XML”, possibly the worst name ever. It could just be called A. It’s all about asynchronous requests. XMLHttpRequest is also badly named: there’s no need for XML. Flickr uses lots of Ajax e.g. adding tags without refreshing the page. On the client side, the technology is Ajax; on the server side, the technology is the API. On Flickr, Ajax is used for functionality that was already there (e.g. adding tags) but with fewer page loads. In some cases, it’s used for whole new experiences.
6. Unicode. Internationalisation is building in the ability to support different locales. Localisation is the translation of your application, UI, etc. into different languages. A big part of providing for internationalisation is using unicode. On the web, that’s usually UTF-8. That’s what Flickr uses.
7. Desktop integration. Or, more precisely, platform integration: it might not be the desktop. Flickr made desktop apps because file uploading is a pain on the web. Desktop apps make sense for file uploading and drag’n’drop. Think about integration with email. For instance, it’s really hard to get a file from a mobile phone to anything except an email address.
8. Mobile. Remember WAP? (audience laughs). Most mobile phones these days have browsers, like Opera, and support XHTML-Mobile which is a lot better than WML. You need to serve different content to mobile devices. Keep text shorter and snappier with less metadata and smaller images. Think in smaller chunks.
9. Open data. Provide methods for people to get data into and out of the system. Allow people to leave whenever they want; that encourages them to stay. Again, APIs do this. That’s how you can get your Flickr pics on DVD, for example: the third party product uses the API to get the pictures.
10. Open content. With many sites, when you upload something, the site owns it. With Flickr, you still own the rights. Beyond that, people can use Creative Commons licenses. Then, other people can reuse that content to create cool stuff. For example, every photo in Cal’s presentation is licensed under a Creative Commons license.

Cal’s slides are available online.

Joshua Schachter kicks off the show. He’s not going to talk about tagging, as was advertised. Instead, he’s talking about things he learned while building del.icio.us.

It’s all good advice. Check every SQL query. Use indices well. Know the ins and outs of Apache. Don’t expose your unique IDs: people will abuse that.

Don’t build every feature that people ask for: build what they really need.

Don’t do those beta sign-ups to build hype.

Attention. Decide if you want to keep things on topic or fragment into different areas of attention. Spam is attention theft. Don’t let spammers know that they’ve been caught: don’t give them meaningful error messages. Let them think that everything is working fine for them.

Tagging. It’s a user interface. A way of storing what you thought at the time. Not all metadata is tags. Don’t let people autofill tags. Some effort is required: a minimum amount but some.

Effort. Allocate your time well. Don’t spend too much time on an insignificant feature.

Measurement. Constantly check the numbers. Measure the system and how users are using it. It’s important to measure behaviour rather than claims: don’t rely on ratings, for example.

Testing. Make sure your testing corresponds to how your users are using the system. Make sure everyone is involved in the testing: if someone wasn’t there, they won’t believe the results. Don’t just give users goals: it will alter their behaviour.

Language. Speak the user’s language. Don’t make them speak your language: you will drive them away (e.g. most people know bookmarks as favourites).

Registration. Allow people to do a lot before they must register. Then they’ll know what they’re getting. People are wary of giving out their email; rightly so. It’s not enough to tell them; you must show them. Make the registration process as quick as possible and send people straight back to what they were doing before.

Design Grammar. Use conventions. Logo in the corner, breadcrumb trail at the top, etc.

Morals. It’s the user’s data, not your data. Let people take their data away if they want to.

Infection. How to promote your system. Del.icio.us didn’t spend a penny on promotion. It was all grassroots evangelism by users. “Look for viral vectors”, he said. Damn! I missed those buzzwords.

Community. Don’t talk about community unless that’s really what you’re trying to do. Del.icio.us doesn’t try to own the community (threads, flame wars, etc.). The community exists outside of the site.

He’s done. That was good, practical advice: I could put some of it into practice over at The Session.