All 14 entries tagged Web20Expoberlin
No other Warwick Blogs use the tag Web20Expoberlin on entries | View entries tagged Web20Expoberlin at Technorati | There are no images tagged Web20Expoberlin on this blog
November 09, 2007
So, now the sessions are over, what kind of things have stuck in my brain? There are a few key themes that I’ll be taking home:
1) Commoditization: All sorts of things that used to be distinctive features, are now becoming commodities. There’s no point expending your own resource on things that you can get from somewhere else, be they hardware resources (ec2/s3/joyent etc), or data (flickr/gmaps/facebook/every other site with an API, or identity services (openID/OAuth)). Re-use what you can, and devote more effort to the things that make you unique. Bear in mind, though, that there are always drawbacks to using someone else’s stuff; make sure you understand what they are, and what your escape strategy is, before you commit.
2) Focusing on the user experience: And, perhaps more importantly, focus on what the user wants to do. Our users don’t, by and large, want to make web pages. They want to do fabulous research, or be recognized as great teachers, or build their reputation as a brilliant journalist or fascinating blogger (is there a difference?), or whatever.
I’m not sure I really understand the things that our users do, and the reasons why they want to do them, well enough to really deliver the best user experience we possibly could.
2.1) Look further afield for ways that the user experience can be improved. Several people have pointed out the synergies between the user-experience elements in game design and the web space; looking at some of the elements around progression that games feature, would probably benefit some of our applications.
3) There’s a world of Federated Identity evolving quite separately to JISC’s Shibboleth roll-out. Fortunately, we don’t have to choose between the two; it seems as if we should be able to have both.
4) Good operations, ( assuming you’re not just handing the whole lot over to amazon :-) ) is an engineering problem. If you want to develop a good operating environment, the people you need are developers; Sysadmins are customers of this development process.
5) Mobile Stuff. Mobiles are the obvious extension point for web 2.0, but there are various different takes on this. On the one hand, you can look to serve upcoming smartphones, which are basically fully-featured browsers which just have a slightly smaller screen than usual. Or you can target the millions and millions of PAYG phones with little or no web connectivity, just basic SMS and maybe WAP. Or you can go for the middle-ground, with very limited HTML and low-bandwidth connections. Whatever you go for though, the interaction model is very different, with people looking for short, limited-attention, result-focussed interactions rather than the long-running dedicated attention that you get when users are sat in front of a PC.
November 08, 2007
Sampo Karjalainen: sulake
Habbo – virtual world for teens. Self Expression/Open Play
Five Key takeaways from games
1: Points. Accumulate score; make progression obvious. Look for quantitative measures that you can report on. Ebay ratings, youtube hitcounts/ratings, digg count
2: Acheviements / Levels: Look for “completion” stages; once you’ve done something, you don’t have to go back
3: Collecting: e.g. Pokemon – a variation on Acheivement; collecting a whole set, or collecting a big set of friends on a SN sites
4: Learning: (c.f. Raph Koster: “A theory of fun”). Flow requires learning; have to be increasing your skills at the same rate as the game difficulty increases
Need progression. Imagine if every facebook app was installed in your account from day 1
5: Virtual Economy; game-in-a-game (c.f. Julian Dibell “Play Money”)
Five +1 tips for Open Play
Open play environments give users resources to develop their own games and activities without imposing any predefined idea of what the game should be
1: Something to play with. Less is more, so long as the objects are recombinable
2: Intuitive Interaction. Easy, rich interaction with a UI which is as invisible as possible. No dialogs, buttons etc. Don’t interrupt the flow and force the user to break out of their world
3: Mood for Play. Make it clear to users that play is allowable/expected
4: Foster user-created goals. Don’t impose your own goals on the system
5: Anticipate and Adapt. Watch for unexpected ways in which users are playing, and adapt the system to meet their needs.
+1: Shared Social Setting. Single-player open play doesn’t often work
Waterfall: bad; washing machine: good;
Waterfall process: gather data->analyse data->formulate solution->implement.
– even in a formal process, people will tend to move between problem and solution, theorising, implemting a POC, revisitng,
– cyclic, iterative process synchronises everyone’s progress from problem to solution and back again
-WM: iterative; rapid early releases; teams are multi-disciplinary; collaborative
-Example WM metholologies; agile; UCD (user centred design (iterative, personas & scenarios, contextual research, user testing))
– both have missing elements: Agile is weak on end-user involvement. UCD is very design-centric; doesn’t involve developers, doesn’t release early
– agile fails to deliver on 2 key points: It confuses the customer who’s paying, with the customer who’s using. The bill-payer is very privileged in an agile project, but the end-user doesn’t get much of a say
– A large percentage of customer requirements never actually get used
– There’s no substitute for design research ; going out and actually asking users what they do.
– doing useability research at the end is too late. research has to be ongoing from as early as possible
– Nielson: Pay attention to what users do, not what they say
– need to add a “cycle 0” into an agile project where ucd is performed, but also need design involvement in every subsequent cycle
– Agile UCD needs longer cycles: but not too long!
– Agile UCD happens within Agile cycles, but typically feeds into later cycles
November 07, 2007
- starting point: one machine, running the whole stack
- scaling from 1->n app servers is hard
– backing up large datasets is hard
– scaling filesystems to large numbers of clients is hard
– inter-app communications is hard
– managing traffic spikes is hard
– managing load fluctuations is hard
- Amazon offerings: s3: 15c/GB; ec2 10c cpu/hour
- s3: redundant storage; as much as you like. 5GB per object (large files have to be split). APIs are HTTP or BitTorrent
- s3 buckets are a single-level hierarchies (each one must have a unique name). Each bucket contains key-value tuples
- APIs for most languages
- EC2: linux 2.6.16 Xen images; Can have small, medium or large servers; large is 4 dual-core processors, 15GB RAM, 1.6TB storage. Storage is not persistent; when the instance is spun down the storage is lost
- ACLs for host/port access
- commandline toolsets for stopping/starting instances
- SQS: reliable messaging service. 256KB message payload. pay per-message (10c/1000 messages). Basic permissions model
– backup (s3sync.rb: like rsync)
– S3 asset host: Use S3 to hold large files rather than serving them locally.
– S3: authenticated downloads; s3 can make files publicly available for a short period of time (~2 s) if the user presents a specific token
– rails: attachment_fu does this for you automatically
-load fluctuation: start additional servers with cron for busy periods; or even use monitoring system to detect h igh load and spin up new machines
- to make storage persistent; have a slave database which syncs periodically to s3
- Problems: dynamic IP addresses makes it hard to manage the loadbalancing, can’t specify DB server very well.
- Solution: run DB server in-house, just use EC2 for app servers for surplus capacity; VPN through from your DC to EC2. Still problems with latency between your DC and EC2
- http://g.ho.st – entirely built with AWS. No datacentre of their own
- High quality and low cost; occasional problems with latency/integrity and vendor lock-in
James Kalbach, LexisNexis
- Metadata: Owner-created (controlled vocabulary), technically generated (search-generated), user-generated (tagging). Which to use is situational; each has pros and cons
- tagging != tag cloud; there are other ways to present it
- Why do people tag? 1: to find stuff for themselves 2: To share with others
- 3 stages of tagging: creating tags; using and managing your own tags; using other peoples tags
- UIs need to encourage tagging for it to work; make the field (a) visible, and (b) large if you want rich and abundant tags (Which you do)
- make suggestions for tags
- provide multiple views onto tags – favourite, recent, popular
- don’t make tags be the only way of searching for resources
- allow of combinations of tags (e.g. del.icio.us related tags)
- allow slicing+dicing: grouped tag clouds
- Good tag-driven sites: LibraryThing; Buzzilions;
- tag clouds are inaccessible unless they include some kind of textual indicator of the number of tags rather than just relying on fontsize
David Recorden, Martin Paljak
- Decentralised, lightweight
- reduce the number of usernames and passwords needed online
- supported by lots of geeky tools, and increasing numbers of development toolsets. starting to get penetration in larger service companies.
- end-user tools from sxipper, symantec, verisign.
- Estonian smartcard system – used for all kinds of e-services. Uses openID behind the scenes to manage SSO
- Gives users more control over their identity data. Services only need to get identity, not personal information, so users don’t need to have multiple privacy policies.
- Need the right hardware and software to use it. card + PIN verification
- Developers don’t like it, in part because of the cost of getting an SSL-enabled site (need a distinct IP address and a certificate)
- Mobile-ID: Same data from the smartcard, on a GSM SIM; but the implementation is totally different. Websites allow you to enter a phone number as an ID; you get sent a confirmation text, use a PIN to reply (PIN stays on the phone), can then continue logged in
- Anonymity: anonymity is a priviledge; open.id.ee provides partial anonymity
- OpenID 2: multiple identities. Can have an openID with no personally-identifiable information in the ID. provides anonymity whilst still allowing sites to assert that these are real, unique people.
- Other EU countries deploying openID. OpenID is designed for interop.
1st wave of social networks – forums, message boards
2nd wave – make friends through friends
3rd wave – tool assisted, as networks start to get more meaning
- The real mobile social netowork is the phone’s address book
- The networked computer is where the social networking revolution is currently happening, but 85% of the world doesn’t have this. As phones become networked mobile computers, there will be an explosive expansion of social networking
- Cellphones revolutionised communication; portable computing will do the same
- social networks are currently too geeky; they require you to be sat down and on your own. portable computing allows you rely on bodies rather than on screens.
- Killer app for geeks: Where the application layer can make inferences based on social data
- Killer app for normal people: When you meet someone, how can the mobile help? could the phone gather social network data from people who are close?
- Casual Computing: Quicker, more engaging. People won’t dedicate as much attention to mobile devices as they do when sat in front of a computer
- search centric – as device storage increases, search-based navigation is more important
Writing about web page http://www.microformats.org
Centralised vs. Decentralised: Smart vs. Dumb
- The internet is a dumb, decentralised network, but each component is just smart enough to get by, and this leads to the whole being very resilient to complexity
- RDF vs HTML: RDF is too complex and hard to publish. Anyone can make HTML
- If markup were robots, XML/RDF would be mechas – big, cool, but not for everyone, HTML would be a nanobot – Dumb, ubiquitous, and reliant on network effects to acheive anything
- People first, machines second. Given a trade-off between ease of publication and ease of machine-consumption, favour publication heavily.
- Microformats are an 80/20 solution; some use cases just aren’t do-able with microformats. That’s a deliberate design choice. Go for the low-hanging fruit
- Microformat building blocks:
– the rel attribute on links and anchors: rel=”license”, XFN ( rel=”friend met colleague” etc)
– the class attribute: hCard, class=”vcard”, class=”fn url”; hCalendar
– hCalendar is an example where a microformat has had to give way on the ease-of-publication vs. ease-of-consumption scale; dates are specified twice;
[abbr title="2007-11-05" class="dtstart"] November 5th [/abbr]
(2007-11-05 is an ISO standard format for dates)
- microformats are seeds
- expose – CSS.
- Discover – Firefox Operator
- Convert – technorati XSL service
– these are problems with HTML generally; microformats don’t make this easier or harder
– grey goo – explosion of formats – there’s an established process for developing new microformats, to control adoption.
– Microformats vs. POSH (Plain Old Semantic HTML)
- Community: wiki, irc, email, blog (tag microformats)
- The future
– portable social networks
– syndicated contact details
– semantic web (little-s little-w). No RDF!
November 06, 2007
- The Web is Global SOA
- Users are taking charge of their web experience. Web sites increasingly providing portable content
- Atomization opf content – small pieces are easier to re-use
- DIY web
- The web as a “parts superstore”
- Jakobs Law of the Web User: Users spend most of their time on other peoples’ sites
- The most successful sites leverage this
- Create open platforms
– APIs, widgets+badges, syndication
– re-use APIS etc from other organisations. Don’t re-invent the wheel
- Widgets: Small applications or bits of functionality that can be embedded on the web; typically ajax or flash
- Badges: Displays of content pulled under the covers from other websites. Less interactive than widgets
- Gadgets: Widget models with specifications e.g. google, netvibes, MS
- Key features of widgets:
– supreme ease of consumption and distribution: copy/paste; one-line JS includes; object/embed tags for flash
– connect to their underlying sites to provide value + control
– have a business model baked deeply into it
– Consumers – moving content and functionality to where they need it
– Developers and prosumers – easy to integrate with high-value functionality
– Businesses – external sourcing of functionality and content
– Web apps built “On the shoulders of giants”
– google gadgets
– MS live
– WidgetBox (re-useable widget directory)
– Myspace Widgets
- Simple widgets get much wider use than complex ones
- OpenSocial: OS gagets will run on every OS-capable site, and get social data from that site
- Widget Stories:
– YouTube video badge – uses the web as a content “billboard”; consistently drives user growth, video views, and traffic back to the site. Made it utterly simple to embed – show the code next to every video
– Google Adwords Widget; probably the most successful widget in history; drives a huge amount of revenue for google. Good user incen tive, extreme ease of use, strong viral feedback loop.
- Blogs, wikis are end-user IDEs
– small pieces, loosely joined
– re-use if possible, but be aware that there are few SLAs
– understand the implications for intellectual property
– provide an absolute minimum of restrictive structure.
Designing for a web of data
- Y! brickhouse – yahoo internal startup environment
- “Interesting” new sites are basically data repositories / platforms.
- The web is turning from a web of pages connected by links, to a web of data connected by APIs and services
- Sites don’t need to own the data themselves; users can own it
- Web pages are being designed in an increasingly data-centric way
- Your site is not your product. c.f.
– twitter; the twitter.com site is only a very small proprortion (~10%) of twitter traffic.
– Flickr: widgets, badges, cards, phone updaters, desktop clients…
– Last.fm: many users almost never visit the site
- In the future; the network and compute devices become more pervasive and ubiquitous
- 3 kinds of things: data sources, data consumers, and data recombiners
- nabaztag, ambient orb, wattson – physical devices that consume and produce net data
- apple.tv – could interact in all sorts of interesting ways with online services
- Why open your data/services
– drive people to your service
– because people will pay for them
– as advertising, or as positioning
– to allow external developers to contribute and add value
- Network effects – every new service can build on top of other existing services
– Every service that’s added has the potential to make everything else more powerful
- FireEagle – knows your location, and uses this information to geotag information that you put on line
- You can never have too much data
- building a datasource
– open up a datasource you own
– build one with your users
– enhance one dataset with another
- Scale: flickr has 1.88 billion photos, growing by 500 million in the last 6 weeks
– how can you make a number like that comprehensible?
– use metadata:
+ data created during production
+ data derived or inferred from analysis of the thing concerned
+ data that you can crowd-source from user contributions
+ data you can capture from behavioural analysis
- Folksonomy vs. taxonomy. Don’t choose, expose both
- Hierarchies can’t take the weight
– Amazon top bar – went from 2 to 6 to 16 tabs, then finally back to 1 with a web-like search
- Top navigation is just a jumping-off point.
- From a visual design perspective; use visual hierarchies to suggest paths
- “Perception of quality is in the edge cases”
- A final word on design practice: Stop! collaborate and listen!
- Organisations have dominant job roles; other roles orient themselves around the dominant roles.