Panel Discussion Notes

Selected Live Notes from The Future of Web Apps Summit Steve Olechowski - FeedBurner - announcing open API to Feed Flare Question: Is the future of the web primarily about solving small problems with highly focused tools? More tools, loosely joined. Small apps acting on mostly local data.. would be useful to have different tools act on the same data (Steffen Meschkat). Example of calendar, files and email messages all in same In Box. Functionality from wide variety of sources integrated/embedded into single page. Single sign-ons? Most people use same password everywhere, and apps remember passwords, so problem isn't so big (David Heinemeier Hanson). Email as identifier and authentication key mailed (Joshua Schachter). Question: Should web apps be designed like desktop apps? Consistency or pretty, unique interfaces? We'll see desktop apps designed more like Web Apps (Joshua). Something different about apps which operate in a more public space, the context is different (Tom Coates). Whole class of new user who has come to apps through the web, older paradigms less familiar to them (Steve Crossan). Network applications already there, but it's when we can assume the network connection that things will shift (Tom). Paradigm shifts return (network as computer) but each time there's more infrastructure on which to build (Steve C). Business Models and pricing: What would you pay for this? People happy to pay for something they enjoy or love (David). Determining what market can bear, barrier for entry - eliminate people who would be hard to support (Shaun Inman). Question: How much re-engineering on transition from prototype/beta to scalable app? Constantly re-building as stuff breaks (Cal Henderson). No way you can build scalable upfront without the real experience. Betas are bullshit, everything is constantly rebuilding (David). Question: How do you know you're ready to launch? Can you use that app everyday? Is it ready to use everyday? Then you're ready (David). Question: VCs or bootstrapping? Are you building for the future or an app for right now? If you're building an app for right now then it's never been easier to build a business with the money you're getting in from the business (David). Question: Web 2.0 happening because of standards being in place, or because of a paradigm shift in the way we think about things? Dominant Metaphors come up, seeing this re-emerge, social networking, connecting services. W2.0 not tech dependent (Tom) We now have atomic apps that can work well together (Steve O). Critical mass of tools that allow these ideas to work together quickly, even if the ideas come around (Steve C), and successful models (Tom) Question: Where does Accessibility fit into Web 2.0? AJAX as an approach presents some potetial difficulties but at same time a drive towards more standard code, better built site. Takes a couple of years for this to be figured out (Tom). Accessibility is v. important, but the real world sometimes doesn't allow for perfect execution (Ryan). Can build perfectly accessible AJAX pages in principle, just aas you can build poorly accessible HTML (Steffen). Question: are we going to have different forms of commercial agreements? - interelatedness of services. The API is a contract, though not a legal contract. Will see a lot more connected apps with no legal agreement (Joshua). You have to know an API is secure if you're building a business on it, lawyers probably not the solution, but some sort of uptime agreements - going to be fun :-) (Tom) Question: web app companies with revenue upfront, and others build critical mass first.. how do you balance this? Social software needs critical mass, so they can't charge users upfront (Tom). Keep costs low, get money elsewhere so you can scale it. You can build things very cheaply and work out how you can monetise later (Steve C). More interesting apps being created within the constraint of having to attract users who will pay for them (David). Google seen as web search but they make their money through advertising.. but this wouldn't be possible without the search (Steve O).

Technorati Tags: Conferences, Future, futureofwebapps, Internet, Software, technology, Usability, Web

Steven Crossan & Steffen Meschkat of Google

Live Notes from The Future of Web Apps Summit Greater Expectations - Reality-Checking the AJAX Web Application Architecture Steffen M from the Google Maps team. Dissecting the AJAX hype a little bit. AJAX boils down to client-side scripting, done the right way ("but the name CSS is taken"). All of the parts are either nonessential or redundant. All scripting on the web is essentially JS, all interactions are asynchronous. "A bad name is better than no name". Classic web apps. On the client there are only 2 events - click a link and submit a form. Each time the action is replace the entire document. All application logic resides on the server. With AJAX, scripted event handlers are embedded in client side documents. In response to events the document is updated, possibly involving a request for additional data from the server. App-specific behaviour us implemented on the client side. Consequences: Sophisticated User Interaction (partial display updates, modifications, animations; complex manipulations possible; user interaction as with pre-web) and Client Side Session State (transient session state managed on client, persistent state maintained on the server, corrects a long-standing architectural aberration - which also scales very badly). The bad thing about doing something right the first time is that nobody appreciates how difficult it was. Web Technologies give us plenty of opportunity to appreciate how difficult it was. AJAX:

• XHTML obviously the skeleton of what the client sees.
• CSS - layout, fonts, colours.
• DOM (Document Object Model) - no transactions, unspecified partial deserialisation semantics.
• JavaScript - semicolon insertion (can omit semi-colons at end of lines - to woo Visual Basic users!, single threaded ("but nobody tells you so")
• HTTP - XMLHttpRequest (notice the capitalisation, let alone the semantics)
• Data Marshalling - XML, but better JavaScript Object Literals

Sounds bad.. "but whatever does not kill us makes us stronger" ;-) Practical Consequences:

• Cross Browser Compatibility (different implementation of all mentioned technologies, different but always many bugs, enforces good libraries)
• Separation of interaction logic and application logic (implemented in different languages, seperated by flexible and extensible protocol, Seamful integration)

JavaScript: Reputedly not serious (ridiculed for the name; semicolon insertion; surprising scope rules; poorly specified runtime), but actually better than its reputation (custom objects, delegations, closures; rich literals, exceptions, functors; has been called Lisp withC syntax; even the name made sense at the time). Don't be afraid of JavaScript :-) Challenges: Deployment (compilation/packaging, modularisation, cache control), Bookmarking & History (in apps quite pedestrian but so are the browsers), Graceful Degradation (smart reuse of transfer format helps a lot), Frameworks (resist the temptation to build one, because there is already one - the browser)

Technorati Tags: Conferences, Design, Future, futureofwebapps, Internet, Networks, Social Networks, Software, technology, Usability, Web

Ryan Carson of DropSend/Carson Systems

Live Notes from The Future of Web Apps Summit Building a Web App on a Budget: How we built DropSend. Small companies and freelancers Why it's important: You don't have to be big anymore. Much cheaper to do things now without gigantic investments. Broadband is widespread. People comfortable with web apps. Hardware is cheap. Open source is cheap. What's enterprise? Mass market or 1000+ users. Capable of handling a large amount of users. Under £30k. DropSend, enterprise and on a budget. Sending and storing large files. 9.5k users in 2 months. 5 Servers co-lo at 365 Main. Desktop apps which use API (not yet public API). PHP, AJAX, MySQL. The most important thing? Make sure idea is financially viable. Use common sense - would you actually pay for it? Be cautious about projections. Be pessimistic, then assume 65% of that. Will you survive? Aim for profit, not acquisition. Acquisition is a fantasy not a reality. Forget the 'new bubble?' stuff. How much we spent. Set a budget. Diff budgets for diff apps. Branding & UI £5k. Development £8.5k (smalll equity stake for developer). Desktop Apps £2.75k. XHTML/CSS £1.6k. Hardware £500. Hosting/Maintenance £800 per month (BitPusher) for 5 boxes. Legal £2630. Accounting £500. Linux specialist £500. Misc £1950. Trademark £250. Merchant account £200. Payment processor £500 setup. Total £25,680. Cashflow - have a side business to bootstrap and fund idea. How to get and stick to a budget: 1 year to save the cash. If it takes time it's ok! Building a team: Quiet talent, not rock stars. Offer equity (2-5%). Ask friends for recommendations. Outsource - tried India, didn't work for us, might work for you. Scalability on a budget. Enterprise has to scale but you can't afford it. Buy just enough hardware to launch. Wait to see if you're successful before you spend lots. Build scalability into the architecture. How does app handle running out of disk space? Plan but don't obsess. Keep it cheap: Don't spend money unless you have to. "No stationery - we wasted £1k. Dumb." No new shiny machines. No luxuries. No froo-froo features. Cut right back and launch quickly with very few features. Makes product simpler and easier to use in general. Before you spend £25, check yourself. Make deals, give equity, barter services or advertising (on blogs). Use IM, not phone calls. Do as much as you can yourself (did wireframing, marketing, testing, book-keeping, copy writing. Get friends to help (usability testing). Shop around (first quote was £12k month!). Pessimism has it's place: You'll go 10% over budget and 3 months over schedule. Plan on it and update your cash flow. "Holy crap! Lawyers are expensive". Terms of service £1k, Contracts for freelancers £800, privacy policy £15 (clickdocs). Barter! Free one-hour consultation. Cheap software is your friend. Basecamp, Trac for bug tracking, Skype & AIM, Subversion for version control, LAMP Cheap hardware: £200 Linux box for dev server on own broadband. Marketing: Blogs, Word of mouth, viral qualities to app where it makes sense, writing (great way to raise profile - mags in your customers sphere of reference). Venture Capital? Might need it if you need to scale/expand quickly, you can't wait a year to save cash. You need a solid reason to go the VC route. Why give away 25-50% if you don't need to? What we learned:

• Don't spend money unless you absolutely have to
• Bring down costs by bartering
• Cut features
• Be realistic/slightly pessimistic about your cash flow
• Plan for scalability but don't obsess

Technorati Tags: Conferences, Future, futureofwebapps, Internet, Networks, Software, technology, Web

Andrew Shorten of Adobe

Live Notes from The Future of Web Apps Summit AJAX and Flex - shared Web 2.0 themes. Engaging and compelling user experiences. Seperation of data & UI (RSS feeds, Public APIs, Open data formats), Information comes to the user, Standards-based. AJAX limited by browser. Flex leverages the Flash Player. AJAX not designed for high-performance UI rendering, limited UI controls, write-once cross-browser delivery hard, lacks integrated AV, no bi-directional RT messaging support, limited to XML over HTTP, no offline/online working, no screen reader support (?). Move in use of Flash away from expressive content towards an application platform, cross platform/device. 98% reach of Flash player. Flex enables developers to deploy apps to the Flash player. A framework of components. MXML, ActionScript, CSS, Flex Class Library. Application server, J2EE Tier, Integration Tier, Resource Tier. Messaging direct between client apps without server transaction. Flash Player now has ability to view source code (not clear when this is allowed). When to use Flex - as standalone apps: Guided services, Media Rich Applications, Data Management Apps, Data Visualisation. AJAX/Flash composites such as MeasureMap. Tools: Flex Framework 2, Flex Builder 2, Flex Enterprise Services 2 (messaging, sync etc). Flash Player free, SDK free, limited use of Enterprise Server. AJAX on Steroids, Vista on a diet :-) http://labs.adobe.com

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Internet, Software, technology, Web

Shaun Inman of Mint

Live Notes from The Future of Web Apps Summit Ten Reasons why you need to build an API APIs take a good thing and make it better. A documented means of interacting with one application from another. A successful API obscures the storage format of the requested data as well as the details of the retrieval process. Lots of uses of APIs by bloggers, developers, dashboard widgets, service providers. 1. Increase brand awareness. People don't care about the API, they care about what it can be used for. Users of APIs are early adopters, technophiles. You empower users/developers and they like to talk about that. This builds buzz around your application. 2. Allow users to own their own data. Pull data out of services, freedom to move, survive. 3. Build goodwill with developers. Saves people having to do the same things over and over again. People have solved the problems already, use it. 4. A perfect excuse for a community. Mint API lets users extend the functionality, this knowledge needs to be acquired, shared, discussed. Pulls people together around these features. 5. Solving programming problems with an API in mind can improve code quality. Preparedness for this is a discipline, clarifies mental model for application. 6. Simplify internal reuse of data. 7. Allow others to extend the functionality of your application. Eg of SVG graphing add-in to Mint. 8. Allows for alternate input systems. Desktop software like Ecto, MarsEdit 9. Unanticipated applications of your data. Mash-ups. GoogleMaps extensions. 10. Turns your program into a platform. http://www.haveamint.com http://www.shauninman.com/

Technorati Tags: Conferences, Design, Future, futureofwebapps, Internet, Networks, Software, technology, Web

David Heinemeier Hanson of 37 Signals/Ruby on Rails

Live Notes from The Future of Web Apps Summit Introducing a silver bullet for developers: Motivation. A stronger influence on productivity than any other factor. This should be the focus of development processes, need to enjoy the mundane details of what you do. Motivation comes from happiness, so the tools we use should optimise for happiness. How do you go about making programmers happy about what they do? Coding is usually mundane. Beautiful code makes programmers happy. Feeling good about statements which express what is required in an obvious, pleasing, right way. But, your application is not a unique snowflake. You are not special :-). This is hard to deal with, but most of your work revolves around the same mundane details as everyone else. With Ruby on Rails we have optimised for what most people do the same most of the time. 80% is mundane, 20% is special. Convention over Configuration. Config is a big programming task, which is repetitive and hated. Beautiful code doesn't repeat itself. Example of convention of classes linking to tables which are the plural of the class name (milestone/milestones, project/projects). For the special cases you configure, for the rest you assume the conventions. Example also of the naming of web app controllers mapping to the URL without rewriting urls. Flexibility is overrated. It's a tradeoff with readability and speed of coding. Constraints are liberating - if it's easier to follow conventions you'll build consistent systems and not worry about the irrelevant details. Focus instead on what your app actually does. Do the right thing - the clean, pure, beautiful thing. Hard to do - developers have an angel and a devil on each side of them :-) Too tempting to do things the easy, quick way that you pay for in the future. PHP is the devil :-) Constantly encourages you to do the quick dirty hacks, to be a slob. You can fight it, but it's hard, especially when the pressure's on. The angel is embedded in RoR. Conventions. You have to go out of your way to do things differently. Invitations. Embedded invitations to do better, encouraging good practice. Opportunities. To be better and learn more. Allowing common patterns but showing that there are better ways to do things. Expectations. Embedded in the system and the community. Example of running tests with code. Rollback. Ruby makes database rollback easy through blocks of transactions. Validation and associations embedded in the system, and the reliance on conventions makes the code clean and beautiful; almost like plain text. Association chains. Lists model. Ruby everywhere in RoR because it decreases mental overhead of switching, and allows you to move back and forward. So Ruby for embedding in html, for configuration, for functions. Finding the Fit: You feel the hurt - You need to have reached the limitations, found the lack of structure and consistency, degraded productivity etc. Yoy appreciate the agile - testing, domain models. You can skip the vendor - DHH is not a vendor, you want to help yourself. But does it scale? Yes :-) http://www.rubyonrails.org

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Internet, Open Source, Software, technology, Web

Tom Coates of Yahoo

Live Notes from The Future of Web Apps Summit Native to a Web of Data. Two months at Yahoo, presentation online afterwards. Design & Web 2.0: Round corners and gradients. Started by Blogger :-) What it means to build for an emerging web. What is the web is changing into? What can you build on it? Architectural Principles. 1. Web 2.0. A buzzword, but also an attempt to make sense of change. Tim O'Reilly Article. Marcus Angermeier cluster map. But too many ideas. Focus on Web of Connected Stuff. The web that was, silos of info, linking together, towards an aggregate of connected data sources, services for exploring and manipulating data, and ways users can connect them together. Mash-ups (not a great term, but useful). Yahoo Astronewsology idea - splice-up of News and Astrology :-). Hybridising data sources in order to make each more useful. Network effect of services. Every new service can build on top of all the others. Every service and piece of data added makes every other service more powerful. Creates massive growth, accelerating innovation, more competition, componentised services and increasingly specialised services. There is money to be made. Use APIs to drive people to your stuff. Amazon prime model for this. More useful and attractive, less centralised development. Syndicated content as a platform. Turn APIs into pay-for service. Keeps hippies and capitalists happy :-) Dangers of NOT doing this. 2. What to build? "What can I build that will make the whole web better? How can I add value to the aggregate web? Drive to own certain types of data: location, identity, calendaring, namespaces. Tim O'Reilly's 'Intel Inside' of data. Data as core service over next 10 years. Improving use of data, navigating it, more data means better ways to manipulate it needed. Can you help users connect it together? 3. Architectural Principles. Matt Biddulph http://www.hackdiary.com/slides/xtech2005. i. Look to add value to aggregate web of data ii. Build for normal users, developers and machines iii. Start designing with data, not with pages iv. Identify your first order objects and make them addressable v. Readable reliable and hackable urls vi. Correlate with external identifier schemes (or coin a new standard) vii. Build list views and batch manipulation interfaces (3 views - destination, list view, manipulation interface) viii. Create parallel data reps using standardsAPIs, microformats, parallel XML, RSS ix. Make your data as discoverable as possible http://www.plasticbag.com

Technorati Tags: Conferences, Design, Flickr, Future, futureofwebapps, Internet, Long Tail, Media, Networks, Social Networks, Software, technology, Usability, Web

Cal Henderson of Flickr

Live Notes from The Future of Web Apps Summit Flickr - Awesome, and almost 2 years old now Passionate developers create passionate users. You have to care about the things you're building. What users want and what they need are different. Many things Flickr built are not what people would have said they wanted. Ten things 1. Collaboration. Flickr started as a MM Online Game. Massively Multiplayer Online Photo Network. They kept 'friends' and removed 'enemies' feature :-) Social network from the ground up. Incentivise adding people to the network. Collaborative Metadata - adding tags to own photos but also to friends' photos. Idea of a family working together to annotate pictures that a family representative has uploaded. 2. Aggregation. Latest photos from everyone, different slices in different ways, tags, location, Interestingness algorithm (activity around photo) 3. Open APIs. Web services API. Flickr needed it for AJAX-based apps, internal use intially, then opened up later. First stage to do read-only (feeds etc) - lots of value in this alone. Beyond this RPC-type APIs turn into web services where others build interfaces onto the data. This has led to things being built that the developers would never have built. Example of multiplayer game Fastr based on tagging photos. Without an API people will still do this sort of stuff, but they'll scrape etc and it's hard to protect against the downsides of this. Bandwidth hits etc. 4. Clean APIs. Expose logical structure, not the internal workings. MOD_rewrite under Apache. Guessable URLS, and immutable: They must never change! Even when you change system you have to support old URLs too. 5. AJAX. Not necessarily JavaScript or XML.. about the Asyncronous part primarily. XMLHTTPRequest and an API to call. Strong API to expose all needed functionality is required. Used on Flickr to streamline interaction, remove page-loads, save some bandwidth, retain state and context. Also for creating whole new experiences - self-contained applications. 6. Unicode. Internationalisation (building in the functionality) and localisation (translation of relevant parts of app and data). Build in support from the beginnning, using Unicode. UTF8. 7. Desktop/Platform Integration. How can we pull interactions out into other regular apps. All based on APIs. Early on build Mac/Windows uploader apps to overcome limitations of web for doing this. Also browser apps such as bookmarklets, XUL for Mozilla, Avalon for Windows. Integration with email. People already have and understand it, simple mechanism for getting pictures into Flickr (inc mobile users), and notifications out of Flickr to email. 8. Mobile. Will one day become a more important platform.. and they still keep saying it. Simple markup standards XHTML Mobile Profile 1.0. Small apps for mobile devices which will work on majority of modern devices. Building content for mobile is different, not just skinning. Build specially for the constraints of the devices, and the context of use. 9. Open Data. RSS is useful but not a mechanism for getting all of data in and out of system. Easy escape routes are an incentive to stay. Users own their data, and the metadata that happens around them. Allowed through read/write APIs. Also a source of interesting third-party apps - eg export to DVD. 10. Open Content. Prior to Flickr web apps which stored metadata would pretty much own the data you upload. Flickr is different, and they can't do anything to/with the data without your permission. Additionally Creative Commons licences can be applied, leads to very interesting and fun reuses. All pics in presentation were CC from Flickr Slides at http://iamcal.com/talks

Technorati Tags: Conferences, Creativity, Design, Flickr, Future, futureofwebapps, Media, Networks, Social Networks, Software, technology, Usability, Web

Joshua Schachter of del.icio.us

Live notes from The Future of Web Apps Summit JS is talking about what they've learned in building del.icio.us Browsers - quirks, headers, caching, lots of pain Scaling - Don't do it! Unpredictability of scale problems (this gels with what 37 Signals have said). Set up a monitoring system for out of hours problems. Selective indexing. Caching wherever possible. Latency is ok in places - figure out where this is and how much. Understand your database intimately. Abuse - Idiots are smarter than you. Wait to see what breaks before you fix it Apache - Tune, use a proxy, split up stuff between servers, throttle. APIs - JS built API early to bring data in, tech 'priesthood' need this for long-term security. Make it easy so people use it a lot. No API key in del.icio.us. Identifiers - Don't expose unique db id - prevents scraping entire database from computable ids. Features - and feature requests. Features (included and excluded) determine how people think about system. Don't duplicate features available elsewhere - messages as example of duplicating email. Get to the bottom of feature requests - why is something being asked for? Solve the problem rather than fulfill the request. RSS - everything that could have a feed should have. Understand headers, caching etc. 60% of RSS traffic is requests to see if something has updated. URLs - keep simple, don't do session ids in URLs, don't expose workings of system. Expose some functionality via URL. Surprises - watch for what people do and determine whether to amplify or supress. Passion - solve a problem you have. You will understand the problem and be passionate about things. It's inexpensive to build things, and even a niche problem is acceptable because of infrastructure for revenue, advertising. Release - Early and update often. Don't be closed and quiet. Each day behind losed doors is a lost opportunity. Attention and Attention Theft (Spam) - Cut off systems whereby people become driven by ratings and figure out how to beat system. Usefulness of error messages in people doing this.. so don't do them. Tags - Useful for recall, ok for discovery, terrible for distribution. Tags are not definitive. Motivation - why are users there? Expect selfishness. What is the payoff for the user? Make the userbase you already have want to bring people in. Measurement - intuition backed by numbers. Put numbers to everything. Measure the system itself and behaviour rather than claims. Testing - Labs or even Starbucks testing :-) Don't give them goals, tast real behaviour. Let people figure stuff out and wander off. Language - what are people calling things? Favorites vs Bookmarks. Speak their language. Registration - don't make them register before they see the site, or even use the system. What are they going to get out of registration? They have to see it, not be told it. Fear of spyware etc. Design Grammar - if it's different from the way other systems work understand where you're breaking from this. Everywhere else do exactly what the Design Grammar is and don't move far from this at all. Navigation positions, logo link to top etc. Morals - things are really purged when you delete on del.icio.us (makes API more complex, but important) Infection - vectors of word of mouth promotion. How to enable evangelism. Invade every communication stream you can. Look for viral vectors - rss, email, desktop apps which handle http etc. Community - be careful unless you're actually building a community. Communities exist elsewhere and enable them to use it without forcing them to use it. Questions for JS later.

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Futurilla, Internet, Long Tail, Networks, Social Networks, technology, Usability, Web