- Design and Web 2.0: it’s all about the rounded corners and gradients
- Blogger may have started the trend
- Outline
- What is the web changing into?
- What can you / should you build on it?
- Architectural principles of Web 2.0
- Web 2.0?
- Buzzword, conference, new way of thinking
- Web 2.0 means so many things to so many people though
- Let’s concentrate on a “web of connected stuff”
- Web at the moment – data silos
- Now and in the future:
- A web of data sources, services for exploring and manipulating data, aways that users can act together
- Web of pages -> web of mashups – > a web of data
- Mashups
- two disparate data sources, made more useful by being combined with eachother
- A network effect of services
- Build on top of what’s already there
- What you build enhances what’s already there
- Consequences
- Massive creative possibilities
- Accel. innovation
- Competitive services++
- Componentised services++
- Money to be made
- Use APIs to drive people to your stuff
- Amazon is the prime example
- Better service with less centralised development
- Use syndicated content as a platform
- Turn API into a pay-for service
- It’s no good to be a web isolationist these days
- Choosing what to build
- What can I build that will make the whole web better?
- Add value to the aggregate web
- Architectural principles
- Data sources
- Std ways of representing data
- IDs and URLs
- Mechanisms for distributing data
- Ways to interact with/enhance data
- Financial/legal stuff
- hackdiary.com‚ Xtech2005
- Good URLs should:
- be permanent references to resources
- have a 1-to-1 correlation with concepts
- use directories to represent hierarchy
- not reflect the underlying technology
- reflect the structure of the data
- be predictable / guessable / hackable
- be as human-readable as possible
- be – or expose – identifiers
- Core types of page:
- Destination page
- A core first-order concept and its subordinate info.
- List view page
- A slice of your data used to navigate between first-order concepts
- Manipulation interface
- Interface for batch manipulation of first-order concepts
Category Archives: Internet
Cal Henderson – Building Flickr
“Ten reasons to love Web 2.0″
- Flickr is awesome! It certainly is…
- Web 2.0 – kinda awesome…
- Flickr 2.0 is 2 years old on Tuesday!
- About 2 million users – many passionate ones
- The developers are passionate about what they do
- Passionate developers make for passionate users
- User wants vs user needs (recurring theme here…)
- Don’t listen to your users – they say what they want but don’t really want them
- Give them what they need and they’re more likely to be passionate
10 things:
1. Collaboration.
- Flickr used to be a MMORPG, but became MMOPS (Massively Multiplayer Online Photo Sharing)
- Putting photos on web sites isn’t new
- The social network sharing is, though
- Collaborative metadata
- Add tags to my own photos, but also to my friends’
2. Aggregation
- Slice the data in interesting ways
- latest photos from everyone, from your contacts etc.
- slice by tag, geo-location, “interestingness”
3. Open APIs
- web services APIs – SOAP, REST, XML-RPC etc.
- What’s the point? They needed it for Ajax-based apps. Eating. Own. Dogfood
- Do read-only stuff first: RSS etc
- Do read-write later – provide API and data-storage, let others build the UI. E.g. Fastr – a game.
- If you don’t provide an API and people want your stuff, people will screen-scrape instead.
4. Clean URLs
- No need to expose the guts of the app anymore
- Expose the logical structure from the POV of the user
- mod_rewrite under Apache is the easiest way (maybe…)
- URL hacking is an alpha-geek thing to do, but people do it.
- They mustn’t change. If a URL links to a resource now, it should link to it forever.
5. Ajax
- “remote scripting” / “remoting”
- Could really be called ‘A’, as it’s not necessarily about XML or even JavaScript, just asynchronous requests.
- All of the Ajax on Flickr uses the Flickr web service APIs
6. Unicode
- i18n – comes first, l10n comes later
7. Desktop integration
- All happens through the APIs
- Not just desktop apps, browser apps too e.g. bookmarklets
- Interaction via e-mail – great for uploading from mobile phones
8. Mobile
- “next year – the year of the mobile” – said every year since year dot
- Modern phones use decent browsers though, which supports XHTML-MP 1.0
- Still limited by small screen size, so rethink the content and the interface, not just re-present the same content as the desktop browser site
- Still limited by small screen size, so rethink the content and the interface, not just re-present the same content as the desktop browser site
9. Open data
- Import and export of data
- RSS gives me the latest 10, say, but doesn’t provide access to the entire dataset
- The API lets them do this
- The more you make it easy for people to leave, the more they’re inclined to stay
10. Open content
- The data is owned by the user, not by the service provider
- Various Creative Commons licenses can be applied to define how other may use your stuff
Joshua Schacter – del.icio.us: what we’ve learned
- Browser inconsistencies
- Scaling – SQL isn’t great under heavy load
- Think beyond one web server, one db server
- Abuse
- “Idiots are a lot smarter than you”
- Wait to see what breaks before you fix it
- Know it inside out
- Put a proxy in front that isn’t apache – helm? – to add throttling etc etc
- Images on a separate server
- RSS on a separate server
- Use throttling – mod_throttle doesn’t work very well…
- Built in from the start, because the developer needed it
- Greatly encourages adoption
- No lock-in – the user owns their data
- No API key in del.icio.us – low barrier to entry
- Hundreds of plugins have been created
- Identifiers
- Don’t expose the internal ID, especially if computer generated, or people will try and programmatically hammer & scrape the service.
- Don’t add features that exist elsewhere – e.g. messaging
- Build features that people will actually use, not what they ask for (what they need, not what they want)
- important – the native way to describe a list of links
- put them everywhere you possibly can – (msk note: PWA needs RSS!)
- Understand caching & headers, the “if not modified” header
- del.icio.us has more RSS traffic than HTML & API traffic, due to poorly-written RSS readers…
- make ‘em simple
- hide your implementation
- design them for the user, not the developer
- del.icio.us started from a text file of links – 25,000 entries
- next step – a single-user db-backed system
- then thought “maybe other people would like to use it too…” del.icio.us was born
- don’t go looking for problems to solve – solve your own problems that you’re passionate about
- Don’t go closed beta, be open!
- Get passionate users using your app quicker
- “The daily popular”
- Aggregation of attention works for small groups
- Less useful when the population of the app grows larger
- But…you can aggregate by tag
- “attention theft”
- “social software is that which gets spammed”
- No top 10 on del.icio.us – not very interesting
- If it were there, it would be a spam-magnet, people trying to get to the top of the list
- Don’t provide feedback – let them think things are still working. No error messages to give the a clue that they’ve been rumbled.
- It’s not about organisation, but about UI and recall by the user
- Not all metadata is tags
- There’s a bit of difficulty involved in adding a URL to del.icio.us, but not too much. Don’t make it too easy, nor too hard.
- Beware librarians! Don’t try to impose a vocabulary/taxonomy.
- Make it useful for the user in itself
- Make it so the users want to bring other users into the system – evangelism
- Don’t spend time building features that no-one will use!
- “Intuition is guesswork backed by numbers”
- Measure the system itself
- Measure behaviour rather than claims
- User-acceptance testing
- Test that it matches the users
- Don’t assign people goals and make people do them
- Speak the user’s language
- Bookmarks only make sense to Netscape/Firefox users – IE users speak “favorites”
- Make as much functionality available without registration as possible
- People are wary of spam & marketing
- Short and sweet reg, then send back to whence they came…
- emulate the structure of the web world out there – don’t deviate from established conventions too much
- How users are treated
- It’s users’ data, not yours
- Many systems don’t allow account deletion – it’s good to allow people to jump ship if they want to.
- Deleted data should be really deleted
- zero-dollar promotion
- totally word-of-mouth
- RSS important
- E-mail not so much – you don’t want to be seen as a spammer
- “viral vectors” – umm? RSS, iCal etc etc? Bzzt.
- There’s no community in del.icio.us in the traditional sense
- Saves having flamewars etc.
- Enable communities to use your system without providing an actual community
d.Construct wrap-up
[I'm writing this two days after the event, by the way...]
In no particular order, here’s my d.Construct 2005 wrap-up. It’s nothing short of electronic name-dropping, I’m afraid
- Cheers Rich for the ComPeelation CD. I hope you enjoy the bizarrely-titled compilation CD I made you.
- I partook of a Cornish pasty (lamb & mint, pasty fans) with Simon & Natalie
- Andy Budd took my photo! Cheers, Andy!
- I chatted with Cory Doctorow and he gave me his business card.
- I talked to Drew about the Greenbelt festival and the WaSP
- Stuart/sil/Aq bought me a pint. I had to leave after one round to get the train, so I’ll buy you one in return at LUG Radio Live 2006
Oh and, amongst all the hob-nobbing, I learned a whole lot about Web 2.0. To quote Andy Budd, “It’s not a technology or technologies; it’s a state of mind” (or words to that effect).
Cory Doctorow: The Remix Economy
[Editor's note: the battery on laptop A had pretty much given up the ghost by this point, so I made a few choice notes on the wifi-less laptop B, which I offer below for your kind consideration...]
- Alchemy vs Chemistry. The difference is that in Chemistry you tell other people what you’re doing.
- The internet comes out of the scientific community.
- Scientific norms – embedded in the internet – encourages reuse of other people’s work.
- A permissions-based knowledge-based economy is alchemy. “You drink mercury, and then you die” :~|
Much of the reasoning was familiar to me and, in terms of media control by the entertainment industry, I’m completely in agreement. It was good for me, for the first time, to hear Cory speak though. I chatted to him afterwards about the ORG. Oh, and he gave me his business card! (It’s sad, I know, but it was a highlight of my day).
So, I’m not sure what it all means from the point of view of my employer, which makes a good chunk of its money by charging people money to read about what’s happening in the world of Physics. We don’t slap DRM on our stuff, though.
Aral Balkan: The state of the art Flash platform
- Flash vs HTML - both sides’ prejudices are outdated
- Aral founded and runs OSFlash.org
What is Flash?
* A platform
* A VM (Flash player), tools, servers, components, solutions etc etc
* A vibrant open source community
* People think it’s annoying intros, interstitial add etc
* But nowadays it is more likely to be Rich Internet Apps (RIAs)
Ajax? Pah!
* Flash can do what Ajax can do, but it’s been doing so since 2000
* Flash still needs a plugin, of course
* Aral thinks the browser is a plugin too, and that the OS will be where it’s at in the future
The state of the art
* K12 - the world’s first online school
* Opal SMS messaging platform
* Flash – not the app that you think of to make apps (in its timeline-based animation guise). Not maintainable or scalable.
* They wrote their own components to make Opal possible
* More options for authoring Flash now: Flex. Flexbuilder 1 is basically Dreamweaver. Flexbuilder 2 will be an Eclipse plugin 
* Declarative UI design, like HTML. Tag soup HTML, that is Ok, it’s not that bad
* Proper architecture (ARP): business logic on the backend. Good separation of logic, structure and presentation.
* Loads of Open-source tools out there (*including Eclipse*). J2EE on the backend.
* They’re developing Flash apps without using the Flash IDE
* Flex is pricey though – £10,000 a licence.
* Mockup of UI was very fast using Flexbuilder’s design view
* Then switched to Eclipse to finish implentation.
* Flex – a Java servlet/tag library for making SWFs
* “a neat separation of concerns”
* Martin alert: he just said “Service Oriented Architecture”
* Flex looks like a good fit with our Java & Eclipse usage! Rich apps, anyone? Yes, I know Tim M was saying this a year ago, but still
Cool tools
* Swfmill
* ASDT
* MTASC
* ARP, Cairngorm
* ActionStep, AsWing
* Red5, Laszlo
Tom Hume: Web everywhere?
- From Future Platforms, which specialises in content delivery to mobile devices
- Used to work in web development, but got sick of it in 1999
- Got into mobile market instead
- A different perspective, as he’s never done any Ajax
- Analyst quote. The gist: “there are lots and lots of mobile phones“
- Another view: convergence (Bill Gates)
What’s Web 2.0?
* Reminded of “new media”, “4G”, “Java 5″, “New Ariel” – they describe what they’re not, rather than what they are.
* It’s a marketing term of differentiation
What about mobiles?
* Open data formats? Check. Or open standards at least, implemented well (c.f. the adoption of “modern” browsers took w3 standards from nice theory to good in practice)
* No walled gardens? Erm, nope. But the gardens seem to work in the mobile world…
* Online – to be connected to 30%+ of the human race
What’s it all about?
* Communication between individuals, mostly pretty lowbrow
* Glancing (“I’m thinking of you”), gifting (“I saw this and thought of you” – MMS)
* Personal entertainment. People want TV on their mobiles, for some reason! Also content production (camera phone direct to Flickr)
* Info. on the move – (e.g. Google Local Mobile)
* “I believe that the future of the Internet is mobile”
Web on mobile
* WML (native.or transcoded)
* XHTML-MP
* cHTML (NTTDoCoMo’s own standard)
* HTML (Opera browser on some mobiles)
* Ajax (not yet, but being talked about) Appropriate on mobile? What about Flash Lite? Is Ajax a step backwards in that it’s trying to replicate desktop apps?
* Google killed the pub quiz!
* Some technical overlap between mobile and desktop web
* The markup is only a small part of the pie
* Existing web agencies sometimes view the mobile web as print designers viewed the web in the 90s
How is mobile different?
* Network operators are very important – a love/hate relationship with the web industry
* Device diversity – far greater than in the desktop world. No standard form factor. Need adaptive services. WURFL is your friend
* Tight software/hardware integration – you can’t change your phone’s browser. Closed devices, without software upgrades and with slow hardware upgrade cycle.
* Truly mass market: possibly 100% penetration in UK, >100% in other countries. Broad demographic reach. Less arrogant language towards consumers than the web (you don’t have to understand it in order to use it). Usability & design more important. QA more important, as things get installed on handsets.
* Implicit commerciality. No “information wants to be free” There’s a billing relationship: it’s commercial. Successful micropayment implementation. Economics are different due to limited radio spectrum
* Context of use: private, personal, anonymous? Anywhere, anytime. “Disposition towards goal-driven use”. Good fit with the provision of medical care/advice.
* “Wi-fi will destroy telcos”. “That’s balls”
Web everywhere?
* Mobile is how people are connected today
* Web and mobile overlap but are distinct
No time for questions…
Ben Metcalfe: BBC Backstage
Ben’s presentation for download
- backstage.bbc.co.uk
- The BBC’s “Developer Network”
What is backstage.bbc.co.uk?
* Content re-use, with robust licensing, so developers know where they stand
* Peer developer community
* platform to share bbc.co.uk content
* “Mutually beneficial relationship”
Why?
* part of greater “open BBC” push
* support creativity & innovation
* a “public service for the 21st century”
What’s on offer?
* RSS feeds
* travel XML
* (soon) weather data
* TV listings
* message board threads
* more to come. the BBC has loads of data…
What’s the deal?
* Non-commercial use only
* Mashing up with other services (Flickr, Google, Yahoo) is encouraged
* IP: copyright is retained by the creator of what’s built. Content copyright is retained by the BBC.
* Stuff is showcased on backstage.bbc.co.uk
How does the process work?
* Make something, tell backstage.bbc.co.uk, they check it over and if it’s OK they post to their blog about it.
* They help developers of prototypes to improve what they’ve built
* Really compelling work may get folded back into bbc.co.uk itself
It’s possible because…
* Available data: rights cleared and in open formats (RSS, Web 2.0)
* Passionate user base
* Support from the top
Star prototypes
* Travel delay maps / jam cams on maps
* Competition winner: www.mightyv.com
* Site diff tool
Web 2.0 @ BBC
* Mostly RSS; some people don’t think of this as Web 2.0
* Read/Write Web in a traditional read-only environment (*Sounds familiar…*)
* BBC doesn’t own the rights to all of “its” data
* Much data not in a CMS
* …but the BBC does “get it”
BBC programme catalogue
* First public demo!
* Think IMDB for the BBC’s programme content
* Experimental prototype to launch early next year
* Ruby on Rails, for rapid prototyping
* RDF feeds, FOAF to describe relationships
* There will be a Web 2.0 API (probably REST) on top, to complement the web interface
Audience questions
* Will it link to media, at specific points in streams? No – it’s about metadata, not the content itself. Further plans for content-delivery platform next year though.
* Useful data, but BBC only? We want people to remix the BBC data with other offerings. We don’t have the rights or the data for other channels’ content.
* If rights weren’t an issue, could you do more? Definitely: a lot of the problems we face aren’t technical, but IP-related and political
* OT: why use Real for radio content streaming, rather than open formats? Real was the only streaming format in town back in the day (1998, when BBC streaming started). Podcasting is happening in a limited way.
Simon Willison: Ajax and the Flickr API
- Flickr: totally buzzword compliant (“Social software, Tags/Folksonomies, Web Services, Ajax”)
- The developers said: “we wouldn’t trust a service with no export option”
- Don’t want to build an export tool
- Built an API instead – let the users build an export tool
- No-one’s built one yet, though they have built loads of other cool things
- Related tags browser
- Flickr upload tools: iPhoto plugin; various Linux ones; FlickrFS – virtual filesystem for Linux!
- The ultimate geo-spatial mashup! magic tags in photos: geo-long, geo-lat, geotagged XXX
Web services
* Lets software talk to other software over the web
* SOAP and XML-RPC – magic function calls
* REST
* Flickr API calls made by sending named parameters to an endpoint
* Required: method, api_key
* All data is expected to be UTF-8, if not, it’s converted from iso-8859-1
* Public, private and authentication-dependent methods
* API Explorer
* Community API kits in various languages
Scrümjax! (Flickr’s own buzzword)
* Inline editing – titles, descriptions, tags
* Notes
* Misc. niceties
* All uses the public web services API!! (Martin: this is SOA on speed…)
* They’re eating their own dogfood
* Firefox LiveHttpHeaders extension is useful for debugging Ajax apps.
Benefits of adding web services to apps
* User trust
* External innovation & creativity
* Encourages better app design
* XMLHttpRequest and REST make a great combination
* www.flickr.com/services/
* If you only want read-only, there are also RSS feeds
Audience questions
* What percentage of usage is via the API? Not sure, but Flickr is the biggest user of its own API.
* How much load is introduced by exposing the API? Absolutely loads, as some queries are really expensive.
* How has the API design evolved? Simon’s only been there three weeks, but he thinks the API has been there from very early on.
* Server-side tech? PHP/MySQL (!). Loads of caching used, plus some java to distribute photos between servers. Performance-intensive stuff in C/C++.
* Organizr uses the API? Yes, but the XML-RPC version.
* What stops someone building their own site on top? API keys, and Ts&Cs
Stuart Langridge: DOM Scripting & Ajax
- Ajax makes for better, more usable, more interactive UIs
- Interaction can be designed
- JavaScript is a bit of a dirty word for many people, because of the useless fluff (and required code forking) of old-school JS
- However – CSS & valid HTML are a whole new world
- JS is a tool – not for evil. It’s not DHTML, with all the browser-specificity that implies.
- Make the web work better
- CSS - separation of structure & presentation. Not until the CSS Zen Garden was the concept properly articulated
- Different design – unchanging base. This is incredibly powerful. Sites (should) still work without CSS - and this concept is mostly taken for granted now (or is it? there are loads of rubbish presentationally-marked-up sites out there still). Is the message getting through.
- E.g. S5 – just plain HTML, plus a layer of CSS (presentation), plus DOM Scripting (behaviour/interactivity). The result: PowerPoint (!).
- The behaviour layer: control users’ interactions. No longer limited by the way browser makers have made browsers work.
- No page refreshes – no more long waits for servers to return the same page with a bit of an update
- Fade in/out notes to alert users of changes (Yellow Fade Technique)
- Buy a book! Jeremy Keith’s or Stuart’s (got this one already).