FOWA: FireEagle (Tom Coates) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check.

FOWA 2007 134

Share your location online. Capture and make sense of your location, share it with your friends, share it programmatically.

How Fire Eagle works.

Apps either get your location or use it in some way. Too heavily enmeshed with one another. Flickr is good at using your information, but bad at getting it (you have to enter it by hand). Plazes is good at getting location. So, problem, each time you build such an app you have to work on both sides.

Better model: one brilliant way of capturing location, then a whole bunch of services based on it.

Open APIs mean anyone can build a client and anyone can access the data (with permission). Central repository.

Input: postcode, address, GPS trace, co-ordinates, neighbourhood name, village/town/city…

The service: a way of handling the data in the middle and APIs on the outside. A bit like PayPal, a service in the middle.

You give other services permission to access your information.

Example: Dopplr gives my location (London) to FireEagle. Then, I manually update my location on mobile site (“Victoria Dock Thingy”). Or I could broadcast location from my phone. (The app exists for certain phones already.) Then I can decide to share more or less precisely where I am with various applications. I open my laptop at a café, Plazes sends Fire Eagle my location. Then, I take a picture and send a geotagged picture to the web. Site updates my location.

Twitter maps application: I only want updates from my friends if they’re in London. steph-note: that would be great!! Proximizer: know how close your boss is. Friends and family widgets.

Being honorable with your data (privacy, ethics, etc). Because, in fact, why would I want to put that information anywhere? Because it’s profoundly useful and fun to do so. Possible to share location without being invasive. Also, exposing your logs to you. Possibility to purge your data. If you’re doing something naughty (buying your partner a present secretly), “hide me” button. Private places.

Possible problem: people forget they’re sharing. The app can check back and remind them.

FOWA 2007 135

FOWA: Copy is Interface (Erika Hall) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check. Read Suw’s notes, too.

FOWA 2007 131

Words are the most important components of your user interface.

Caveat: interface language found in the wild… American. So, not talking about internationalisation, different versions of languages, cultural issues…

Exciting interfaces: gesture thing Tom Cruise is using, Wii, iPhone… But not yet for data/information stuff.

You don’t know how people are going to access your application. Nabaztag. Applications people love today are made from text. Even interacting with our TV with a text-based interface.

Language is an interface.

Dopplr philosophy. Device independant. User benefits by having direct access to information. In our everyday life, our priority isn’t shiny stuff, but things that work. steph-note: interpreting somewhat, here.

How will the application developer benefit?

Though it takes a lot of skill to use language well, it’s easy to iterate. People will freak out when you change the colours of your site, but won’t budge much if you change language.

5 ways to get words right:

  • be authentic; consumating vs. eharmony (Erika’s pet peeve: the “submit” button. If you change one piece of copy, change that. People don’t “submit” anything.) Twitter has good “we’re down” messages. Sounds like there are real people behind that application. steph-note: when putting a quote on a slide, read the quote in full.
  • be engaging;, (“Hello gorgeous!”) Citybank: “Who was your arch rival when you were growing up?” as proposed security question. Pownce genders.
  • be specific with the language you use.
  • be appropriate: it would be disconcerning if my bank tried to be my buddy. Amazon: “where’s my stuff?” Flickr “Talk Like a Pirate” day. But… some people were afraid the site had been hacked!
  • be polite: rude doesn’t get much forgiveness. Feedburner: “Activate Feed” and “Cancel and do not activate”, including type size to help you do what you want to do. “remarks”. adding “Everyone needs a hug” as default text in their comment box, when they were dealing with terrible flame wars.

Things that have gone wrong:

8 kinds of bad:

  • vague: basecamp, “file should be under 10Mb”; Apple: “some warnings occured. would you like to review them?”; Bank: “expand your relationship” (creepy!) Ask real people how they would call this thing they want to do.
  • passive
  • too clever/cute; “Murder your darlings.” Be ready to kill your pet phrases.
  • don’t be rude or stupid unhelpful.
  • oblivious to your surroundings: CNN — “Don’t miss: Bodies trapped in wreckage.”
  • inconsistent: the whole “my/your” inconsistency. Read your interface aloud to see if it sounds dumb.
  • don’t be presumptuous

You will still need designers. We’re sociable and entertaining, shouldn’t lose those skills when developing our application. Language isn’t going away. It will pay to pay a lot of attention to it.

FOWA: Data Visualisation (Eric Rodenbeck) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check. Suw also has notes on this session.

From Stamen.

FOWA 2007 115

Data visualisation is a medium. steph-note: this seems like a lot of stuff to see

Slide of the US, last elections: blue and red states. Break down by county, quite another picture. Break down more, looks all mixed up. The way you present things changes the story you’re telling.

FOWA 2007 119

FOWA 2007 120

FOWA 2007 121

FOWA 2007 122

Cabspotting: GPS positions of taxi cabs in SF. Empty cabs and full cabs. Obvious thing is to animate this, and you see the cabs moving, with pick-ups and drop-offs. Other obvious thing to do is to show speed (slow downtown!). And animate that too.

  • Oakland crime. There isn’t one single view that will solve all your problems.

FOWA 2007 124

  • Animation of digg users digging stories.

FOWA 2007 125

FOWA 2007 126

FOWA 2007 127

  • Twitter Blocks: interesting because it shows me stuff about the contacts of my contacts. Can tell me if some of my contacts are also contacts of my contacts. steph-note: finally understanding why Twitter Blocks can be interesting… sorry, guys, I’m slow.
  • real estate flow: housing information visualised. Map of dates that houses were built in SF animated over time.
  • visualisation of what towns people are searching about based on where they are. Also, what towns they search for after having searched for a given place.

FOWA: Launch Late to Iterate Often (Dick Costolo) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check.

Dick: a bunch of startups, last one successful (FeedBurner), so now people think he knows what he’s talking about. 😉

FOWA 2007 136

We hear a lot about how cheap it is to start a company now. Lessons learned that are somewhat counter-intuitive to what is usually thought in this industry.

It’s true that you can get a company started without much money, but it still costs a lot to scale.

Cofounders: unequal equals. Better to treat all cofounders as equal. Unequal brings problems (“yeah, sure you want to do that, you have 75%”).

Dick and cofounders never build business plans anymore. Business plans are things that people write to try to make things they want happen the way they want them to happen. Dick doesn’t think investors read them anyway.

Disagrees with trying to evaluate the size of the market. You can’t know. e.g. eBay.

Location: FeedBurner, everybody in Chicago. Believes there is no strategic benefit in locating a company in the Silicon Valley. Actually, better to be away, you’re distant from the echo chamber. Self-perpetuating myth. Benefit in buzz in being in the Silicon Valley, but do you really need buzz to be successful? For Dick, no benefit in the long-term success of the business.

Cash. You always need way more cash than what you think that you’re going to need. Estimate, then multiply by 2.5, and it was even a bit tight. The leading cause of companies going out of business is running out of money. So raise as much as you can. Don’t run out of business.

VC funding is great. Find the right investors. Raise money when you don’t need it. You can get better terms for venture investors. When you start raising a few millions from VCs, you’ll start seeing legal/jargon VC terms (preference, multiples, participation). They’ll tell you they’re standard deals, but there is no such thing. So learn to understand those terms. (e.g. on Dick’s blog, and other places).

It’s better to own a smaller piece of a bigger pie than the opposite. Everybody needs to be happy about what’s going on. Everybody employed needs the same kind of deal (options, equity etc.), keeps goals aligned, and everyone is treated the same way. Even if it’s the “only way I could get that guy”.

Hiring. Take the guy who runs the fastest and then figure out where to put him. Don’t go out to hire a VP of sales. Look for people who are best available athlete, well-rounded person for this kind of role, but able to zig if necessary. steph-note: …any startups looking to hire? 😉 Dick prefers flat organisations. Hierarchy begets bureaucracy. Problem with flat organisations: when there are under-performers. Replace hierarchy with tools. Deal with this by having employees come up with their own KPIs (measurable!)

Growing the team: mistake = hiring sales and marketing too soon. Once you start selling and marketing, things need to be cooked and ready to go. Without that, you can iterate rapidly. Speed of execution is a competitive advantage of small companies over big ones. Wait until you’re ready to go to market.

Product development and business strategy (1-4 years)

Visit to the eye doctor. Iterate on everything. Disagrees with “get a crappy version out there”, because then you have to iterate with that version that is out there.

Day 1: feed stats, but knew they wanted to do more later. They waited until they had a basic underlying architecture to be able to extend the service before they launched. It didn’t do much, but was ready for building more. So that allowed them to iterate very rapidly. “How are you guys rolling out features every month?!” Spent the first 5 months building that underlying architecture for extensibility.

Let the market tell you what the business model is (cf. Twitter). Open system with APIs, help the market tell you what the business model is. Lock-in is bad for business. APIs lower the barrier to entry and to third-party service development. Lock-in creates barriers to entry. steph-note: so does the fact you don’t own your data.

Revenue plan: don’t kid yourself. Goes along with “don’t run out of money”. You’ll never make as much money as you plan, or as fast. VCs don’t pay much attention to it. Those plans are always wrong and at least a year late.

Don’t spend months and months trying to get your pricing right.

Strong advice: don’t worry about your exit strategy, worry about everything else, and also be competitive on your merits, not on how much the other guys suck.

FOWA 2007 138

Let your company have a voice and a culture. It’s harder to make your language sound antiseptic.

FOWA: Putting Users First (Thomas Vander Wal) [en]

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Suw also blogged this one.

FOWA 2007 109

Throw out the “user”: used to be a good term to help us think of the people using our system… but somewhere along the line, the user became the annoying person for the developers, lost its empathy.

Focus on people. Real people doing real things. Me. All the stuff that has to do with my life, connecting all the bits. My information.

Real people… means we have to start thinking about their desires, wants, needs. This is really important for people who are building, designing, developing… even using these systems.

If we don’t think about their wants and needs, that’s when they start sending nasty e-mails or complaining on their blogs or facebook.

Real people includes the 95% of people who don’t live their life on the web. (Not us in the room, that is.) Think outside of the alpha/beta users. People need the information in their real life, out of the browser. Real needs there.

Tech pains:

  • syncing (no comment)
  • refindability: remember that time where you were trying to find something you knew was there?
  • taste: better agree with the editor of Mahalo on what a “cake” is
  • identity: “I gave the internet my details, why do I have to do it again?”
  • easy of use
  • portability
  • privacy: smart privacy
  • attention: we only have so much attention… we’re going the same stupid things over and over again (sorting junk out of the mail)

Lots of problems that tools today can address. What we should be doing is easing tech pain.

Tagging and other features.

FOWA 2007 111

Work contributing vs. derived value.

Tagging takes a bit of work but it puts your world of information in your context. Ratings require roughly as much work but don’t derive as much value.

Tagging brings up the “F” word: “Folksonomy”. Coined by Thomas in 2004: looking at Flickr and It’s not a taxonomy… it’s regular people calling things the way they usually call them.

Folksonomy solves the problem of retrieval. I tagged it, so I can refind it. It’s also usually done in a social environment, so that opens it to others. Personal and shared folksonomies. The act of tagging is done by the person who is actually consuming the information. I put something of my identity in my tags.

Three bits: object being tagged, metadata or tag, person doing the tagging.

FOWA 2007 112

Identity linked to object by interest. Identity linked to metadata by vocabulary. Object to metadata by definition. A community of those using the same term to tag the same object emerges. Community linked to metadata by terminology. Community linked to object by culture.

This allows us to find more objects. Find somebody else who has tagged stuff “audi”, subtract what I’ve tagged “audi” from their stuff tagged “audi”, and that gives me five new things! Smart system.

Social bookmarking gets (more) social. Ma.gnolia has groups. Nice feature: giving thanks. Just a click to say thanks for something nice you found through somebody else.

Private groups; top tags; recent bookmarks; discussions; members.

Sharing and being social is how humans have got out of caves, and how we advance as a society.

Getting to real relationships: lots of tools have a “broadmind friend” concept of relationships (“you’re my friend, therefore I’m interested in everything you are.”)

Spheres of Sociality: personal, selective (many), collective (all people on the service), mob. steph-note: I got a “mob” feeling when I tracked “FOWA” on Flickr.

Directional sociality: real relationships are not equal. They can be unidirectional. Unequal access. People might have access to read our blog, read and comment, read and also read private feeds.

FOWA 2007 113

steph-note: this is exactly what I mean when I say we need a way to structure our social networks

We don’t want to be listening to everything from everybody. And we need to be able to do something with the information. Frustration with Facebook and also, to a lesser extent, with Twitter.

Ease of use: needs to be as simple as ripping off a phone number from an ad stuck on a lamp post. The information is portable. Our web services need to be this easy. Good example: Stikkit. Identifies that this thing I’m saving is a date/calendar thing. steph-note: like Tumblr recognises that I’m posting a quote

Test early, test often, and test with real people. We’re not necessarily our own best audience.

FOWA: Enterprise Adoption of Social Software (Suw Charman) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Suw has written a blog post about her presentation.

FOWA 2007 105

Suw is a freelance consultant, has done a lot of work with businesses and vendors. Guide on getting your stuff used by businesses, based on her experience.

A couple of areas to think about:

  • tech readiness? does our tool work?
  • support readiness? are we ready to provide support to our customers, and how they will adopt our tool and convince people in their business to adopt the tool?

Two sides of the same tool.

Important: make sure your tool is really ready. If it’s still buggy, if the interface or language is confusing, don’t try to sell it into enterprise. Get more funding first. You only get one chance in enterprise. They won’t come back to see where you’re at.

FOWA 2007 106

Incremental improvements based on user feedback won’t work in businesses. They want something that works now, and regular but not-too-frequent updates. Stability.

Have a process for feature requests. Difference between big vendors (MS, Oracle) “this is what we’re giving you, deal with it” and small vendors.

Pilots aren’t an opportunity to do user testing. They’ll shy away if they feel they’re being used as guiney-pigs.

Don’t assume simple tools will automatically get adopted. People very resistant to use software. They don’t use software because it’s cool. They just want to get the job done, and will find ways to work around the tools they’re given.

Where do you start? Try to figure out what businesses want from you as a vendor, and your tool.

  • integration with their existing systems, single sign-on, active directory, LDAP
  • very concerned about security: “can our employees use this and put data in it and have that data be safe from accidental stupidness or prying eyes?” Technical security and user stupidness security (delete everything by mistake). Big plus for wikis, which have history. Disaster recovery: offices burn down, how will you help them retrieve their data

Understanding time scales. It can take months for things to happen. Lots of things can get in the way of adoption, even with vocal evangelists inside. Contracts, lawyers, packaging…

  • be aware of internal political rankings (stakeholder management)
  • be flexible about how you intend to sell into business. You might end up having to host your service (very different from selling a chunk of software). Trojan mouse solutions.
  • be prepared for runaway success. Can you scale? Really? Quickly? Administration can turn around from “against it” to “we want this everywhere, now!” in the space of weeks
  • be prepared for failure — understand what happened, and have processes in place so that you can learn from failure, but possibly not the same way. Try and fail in new and innovative ways.

Businesses are quite happy to spend money on hardware, software, but not really on operational (people) stuff. Bundle in your support costs into your selling price. If you do an unsupported package, they’ll take that, and you’ll still get the calls. You need to make sure you can afford to help your client get the best out of your tool. How will you be responsive? How will you deal with your contacts in the business, and all the (possibly tens of thousands) of people in the business using your tool?

Sales! One case where a business tried to get through to the sales people to buy, and didn’t get a response. Had to call the CEO! Have someone available to talk to a client.

How are you going to explain your tool to the people who are going to use it? You need an adoption strategy. No use in just giving people your tool. steph-note: as I say, throwing blogs at people doesn’t make them bloggers. What kind of materials are you going to provide them with?

A good place to start: pilots. Groups of like people. Who are groups of people who might benefit from this? Case with wiki: PAs and secretaries, for example. People like very specific use cases. Not good at generalising. Who are you talking to and what do they need from your tool?

Adoption isn’t a business goal. Running the business is the business goal. You need to meet both the wider business goals and the individual people’s goals.

People don’t use documentation. They don’t click help. They ask human beings instead. There is a lot of informal and semi-formal learning going on in businesses. 80% is informal, it seems. Formal learning, training courses aren’t effective. How can you provide ad hoc support? IRC channel? Social collaborative learning tools? (blogs, wikis)

Centralised support is important for the people using the tool. If the company is going to take over that role, they’ll need the materials for it. Make your material user task oriented, not software task oriented. “This is how you do a meeting agenda in the wiki.” Not “this is how you make a page”. Present it to them on a plate.

A qualitative leap needs to be made between old and new things, even if the new things aren’t so much more complicated. That leap can be difficult. But at some point, when enough people in the organisation are using the tool, they start helping each other. Provide the materials for that. Giving people the confidence that they know how it works.

Don’t try to make it up as you go along. Plan in advance. Bring people in. You don’t have to do it all alone (materials, etc).

More about this! Important: both management and grassroots buy-in. Balancing top-down with bottom-up approaches.

Q: tips for demonstrating tool usefulness?
A: work on the use cases. ROI: investing time and money and getting something in return. Important to understand those metrics. Careful, metrics don’t tell you what an individual’s use of something is. One of the problems with social software is that it can sound a little fluffy. “It improves collaboration.” But people think like “I want it to improve productivity to the point I can fire someone.”

Q: is it different for open source tools?
A: enterprises can be very wary of it (how will we get support?) even though there is a huge amount of open source being used. The more technically savvy they are, the more likely they’ll go for it, and the more business-oriented, the less. No hard and fast rules.

FOWA: The Future of Presence (Felix Petersen & Jyri Engeström) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check.

Felix does Plazes. Story: in 2004, original idea to build some location-based service for networks. Geo-annotated database of Wifi networks. At some point, where is the benefit for the everyday user? (Some nerds find it exciting to add data to a database, but not for everybody…) User base strong in certain cities rather than certain countries.

Jyri does Jaiku. Story: in 2006. Help people have a better social peripheral vision. We spend a lot of time physically disconnected from people we care about. Presence or activity stream. What are you doing right now? Not just things that people type, but also items automatically generated by what you’re doing online.

Brian: are Jaiku and Plazes “presence” apps?

FOWA 2007 101

Felix: presence is kind of a by-product of the network, software stuff. You’re connected to the network, and that makes it possible for the tool to broadcast your presence. But at the beginning, could only be somewhere if there was wifi… which is a problem! Need to be able to add small messages. (e.g. “I’m at the airport, leaving for London” — or “just here for another 20 minutes”) Coordinates don’t give you a lot of context.

Jyri: we’re still figuring out the language to talk about these services (e.g. “micro-blogging”). The important part is bringing people together, by enabling them to have this social peripheral vision.

Felix: actually, lots of services have been used like that for a long time, but we didn’t have specific tools for this. E.g. Felix used his blog in 2002 to keep people updated on where he was, and to send links rather than by e-mail. Shift from push to pull. steph-note: ditto. Lots of presence updates all over the place. Now it’s made more explicit by our tools that we’re doing that.

Brian: exciting idea, get all these things to talk together. How are you guys designing your systems to be open?

Jyri: social network portability… importing your friends/buddies from one service to another. Would it make sense for me to import my dog-loving friends from Dogster into my professional network in LinkedIn? steph-note: I think it could make sense, if there is structure to the network. Maybe your dog-loving friends have great professional opportunities for you, but you’re not aware of it because of the circle in which you interact. Getting rid of silos (IM, phones, e-mail…). The answer isn’t “everybody go on Facebook”. We want Facebook to be a player in a larger system which is the internet.

Felix: more about interoperability. Hard to figure out: harmonisation of the objects.

Brian: Jeremy Keith’s lifestream. steph-note: the colors make it really readable

Felix: as long as people are able to get their data out, it’s already a good thing.

Brian: Jaiku Mac client allows you to see what your friends are doing in a granular way. steph-note: need to check it out

Jyri: the image that comes to mind when you say “social network” is the graph of the relationships. But there’s a problem there: people are connected to one another through some type of object, for a reason. In Jaiku: reporting on the actions that people have performed on these objects (tagging a photo, favoriting a video…).

Felix: at the beginning, was just “I’m here now”. What is the “shared object”? In Plazes, I could share the location, but not “me being at FOWA tomorrow”. That’s where it confused people. No way to share or reference it. Blogging was a step forward because you can reference a single post, and do things with it.

Brian: are you building tools that many social networks might use, or are you building communities?

Felix: are we a community or a service? We’re a service, but we’re socially enabled. A service that different people can use in different ways, but it’s a social service.

Jyri: what’s going on on the web has to do with becoming more fluid. e.g. in social science, people are not just talking about social networks, but knots in the social network — transient. Jaiku is based on Jabber, so very different from usual LAMP systems. Creating a load on other servers to pull feeds — unnecessary load, and not real-time. A photo on Flickr has comments on Flickr, but also on Jaiku — not good, we’d like that to be one conversation. But very difficult to do. XMPP protocol to keep conversations in sync, maybe? This is a different approach to what we’re used to when building web pages.

FOWA: Making Your App Social (Rashmi Sinha) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check. Suw also took notes on this talk.

Rashmi does Slideshare, which is 1 year old today!

The idea behind slideshare: presentations are hard to share. Pictures of Flickr, videos on YouTube, but what about the slides?

Again, nothing against the person presenting, but a case study of SlideShare shouldn’t be titled “Making Your App Social”

People share varied stuff on SlideShare. After the initial “2.0” uploads, realised that PowerPoint is the simplest way for people to share a bunch of photos or stuff.

FOWA 2007 92

10 lessons…

  • forget the iPod (good design, but it’s not social)
  • give up control, it’s messy
  • plant seeds, let people connect
  • should have a strong individual focus; don’t count on altruism
  • try to solve one problem really really well

steph-note: can hear Leah Culver (talking in the other room) in here really clearly, it’s quite annoying

What kind of social? Social space or widget? Facebook app? own a piece of the social network steph-booth: ew, another use of “social graph”

FOWA 2007 93

Privacy is social: sharing is often in closed circles steph-note: yes!! yes!! There is a whole continuum between “public” and “private”. Important to be able to shift back and forth between public and private. By setting the default to public, really enabled the sharing of bookmarks.

FOWA 2007 94

Brian: how do you carry privacy settings outside? (feeds, etc)
Rashmi: give control to the person. The social connection is the carrier of the “privacy metadata” (ie, tell your friends to not share further).

steph-notes: some of my thoughts on privacy are in Ethics and Privacy in the Digital Age. I agree that for the moment, privacy is mainly managed through our relationships with others, rather than technically.

Privacy is a tough issue.

Levels of participation: everybody is not a creator.

Popularity. Metrics:

  • favorite & tag
  • comment
  • view
  • embed
  • download
  • e-mail

“The Wisdom of Crowds” by James Surowiecki– add to reading list.

Get into a conversation with users. You can’t get away from them, particularly if you’re in the social application space. Customer service as user research. Answer e-mails personally, monitor blogs… etc. steph-note: cf. Satisfaction

Launched SlideShare by just embedding a slideshow or her talk in her blog. October 4, TechCrunched.

Designed SlideShare for people like themselves, but quickly saw that people were using is to upload art, etc.

Rashmi believes more in “putting it out there”, and letting the people who need it find it, rather than a closed beta which is a lot of work. Hard to find the right people for the closed beta too. Launch first, refine later. steph-note: I kind of agree, but in the case of coComment, for example, launching too early actually did them disservice.

Important: make sure that what you “put out there” works. Little by little. Indeed, if it’s broken, people might try it and not come back. The “put it out there” philosophy works for non-critical stuff.

Be agile. Fail fast to get to the right answer. Track metrics, adjust, change.

Allow for play.

steph-note: I’ve written about quite a few of these privacy issues on CTTS, and had a nice discussion over lunch with Rashmi. Start with Ethics and Privacy in the Digital Age.

FOWA: Predicting the Future of Web Apps (Edwin Aoki) [en]

[fr] Notes prises à l'occasion de la conférence Future of Web Apps (FOWA) à Londres.

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Chances are I’ll be adding links to extra material and photos later on, so don’t hesitate to come back and check.

FOWA 2007 91

  1. A new industry consortium will develop standards for building web apps and concente for low-cost, reduced capability devices

  2. AOL will announce a major push for HTML and JS applications on the desktop

  3. A new mobile computing device, with a modern OS and open developer platform. The hardware will include a hard drive, harndwriting recognition, and a touch screen.

All these predictions have already come true… 10 years ago!

  1. The Network Computer Reference Platform.
  2. 1997: Netscape Crossware
  3. AT&T/EO communicator (1994)

All these ideas are still relevant today. It’s not about the technology, it’s about the ideas.

The web apps of the future need to run everywhere. AJAX browser in the pocket (iPhoto), or on your Wii.

But you can’t be everywhere all at once.


  • small and beautiful beats big and clunky
  • sweat the details but not the infrastructure (let service providers do the heavy lifting for you)
  • standards and openness are really important (employ them with an eye towards security and trust)
  • technology moves faster than society (laws, education, customs), so use these tools responsibly — it’s up to us

Edwin predicts “Future of Stuff”, 5-10 years from now.