|
![]()
Recent Posts
Links
Archives
|
|||||||||
Posted by Terry Howard @ 2/28/2006 It's a been a while since OpenBusiness published an interview on The Value of Attention with Esther Dyson. In that piece, I found her "bar analogy" for social software to be simple yet compelling: You could think of it like your favourite bar. The social function is similar. You don’t go there because the beer tastes different than from in the bar next door, but because of the people who are there. The value of any bar is in its clientele – usually dependent on the owner/manager and the bartenders, whose job is it to care for his guests. Then you can charge for the beer, or if you sell coffee, the coffee... Some retailers sell clothes, for example, and give free coffee. Both are good business models and can work... or they can be done badly, and fail.People who aren't already caught up in an on-line community often fail to understand the allure. They seem to think that the virtual nature of the community somehow structures the interaction in a way that precludes the sort of intangible things we're used to in face to face communities. One of the stories I'll have to tell in more detail after my service at Yahoo is complete (and likely just a footnote in someone's book) is about the Flickr acquisition. During one of the final internal "sales pitches" for the purchase, I had finished demonstrating Flickr to some important Yahoo's that weren't as familiar with it. One of the technical leaders in the room suggested, politely, that it was a waste of money and that "we could build this in six months." I honestly don't remember if I responded to his assertion in that meeting or not (I think I did), but to me he was wrong and missing the point. Yes, we could have replicated the technology in six months. Heck, we probably would have improved it quite a bit. But we didn't have the experience to replicate the "feel" of the early Flickr community. It was a lot like suggesting that you could build another bar across the street from the famous Cheers and expect it to be just as successful. As for being simply wrong, our ability to build it in a few months didn't matter since nobody was working on it and there were no plans to do so. (Insert rant about how the seldom the "build" option is really exercised after the "build vs. buy" debate concludes that we should not buy.) Like Flickr, del.icio.us has its own character. Much of that comes from its creator(s). The same is true of MetaFilter (and Ask MetaFilter), Slashdot, Kuro5hin, Upcoming.org, and so many other community driven sites. But it's hard to see this from the outside. Esther's bar analogy is helpful in bridging that gap. Related Link
Posted by Terry Howard @ 2/26/2006 http://www.loyalkaspar.com/ http://www.trollback.com/ http://www.steelevfx.com/ http://www.tronicstudio.com/ http://www.zonadesign.com/ http://www.concretepictures.com/ http://imaginaryforces.com/ http://www.ca-square.com/ http://www.pmcddesign.com/ http://www.bigmachine.net/ http://www.hornetinc.com/ http://www.belief.com/ http://www.grasshopperny.com/ http://www.attik.com/ http://www.quietman.com/ http://giantoctopus.com/ http://2advanced.com/ http://designchapel.com/ http://gfxmoo.com/ http://www.stardust.tv/ http://rudehoney.com/ http://mk12.com/ http://www.psyop.tv/ http://eyeballnyc.com/ http://www.buckla.com/ http://novo.com/ http://www.3idzn.com/ http://www.nthdegree.tv/ http://www.rezn8.com/ http://www.nailgun.tv/ http://theorphanage.com/ http://www.steinbranding.com/ http://www.hypa.tv/ http://artifactdesign.com/ http://www.waytion.com/ http://www.image-group.com/blink.fx/
Posted by Terry Howard @ 2/22/2006 Each time an individual visits your organization's Web site, information about their visit can be saved. This information can be used to generate "Web statistics" that characterize your site's overall use. Web statistics are a useful tool for measuring site use. For example, using Web statistics, you can calculate a number of useful marketing-relevant indicators: Penetration = [unique visitors to home page] / [unique visitors] Penetration reflects the percentage of site visitors that go beyond your organization's home page. It's not uncommon for Web sites to lose 50% or more of its visitors before the home page finishes loading. A home page that has 5,000 visitors a month with a penetration of less than 50% may be less effective than a site with 4,000 visitors with higher penetration. Conversion = [unique visitors taking desired action] / [unique visitors] Conversion reflects the percentage of site visitors that take a desired action. You can measure the conversion for several actions simultaneously. For example, the percentage of site visitors that purchase online; and the percentage site visitors that subscribe to your organization's electronic newsletter. Connection = [Referral click-thrus] / [desired pageviews] Connection refers to the number of site visitors to your site from an external location, such as another Web site or banner advertisement, that view desired content. Online promotions with a high connection rate are more effective. Migration = [visits to content area]/ [site exits from the content area] Migration refers to the number of site visitors that leave your site from a specific content area. Content areas with the highest migration are typically less effective than areas with lower migration. Clicks to Action = [Average number of clicks from home page to desired action] CTA reflects the number of clicks it takes from the Home Page to reach a desired action. For example, reducing the CTA to complete an order should result in a measurable increase of customer conversion for online orders. Intro Skip Factor = [number of visitors to Intro page]/ [visitors that bypass Intro] This indicator reflects the number of visitors that view your site's intro page, if applicable. If a large percentage of site visitors bypass the intro, it can indicate an ineffective intro, or a high percentage of return visitors. Related Link
Posted by Terry Howard @ 2/22/2006 ![]()
Posted by Terry Howard @ 2/22/2006 From Jeremy Zawodny: Amazing things happen when you give people a bit of trust and authority to do things according to their own judgment. I was reminded of this a few weeks ago when I stumbled upon a Fast Company article called Engines of Democracy. It describes a revolutionary jet engine plant in Durham, North Carolina that produces some of General Electric's most important engines: the GE90, the CF6, and the CFM56. I'm going to quote from it heavily, but you really should read the whole article. GE/Durham has more than 170 employees but just one boss: the plant manager. Everyone in the place reports to her. Which means that on a day-to-day basis, the people who work here have no boss. They essentially run themselves. How does that possibly scale? Self-managed teams. The jet engines are produced by nine teams of people -- teams that are given just one basic directive: the day that their next engine must be loaded onto a truck. All other decisions -- who does what work; how to balance training, vacations, overtime against work flow; how to make the manufacturing process more efficient; how to handle teammates who slack off -- all of that stays within the team. Not only are the teams self-managing, they have unprecedented authority and transparency. Everyone knows how much money everyone else makes, because employees are paid according to his or her skill... This plant has no time clock. Workers leave to go to their kids' band concerts and Little League games. The results are pretty compelling: When it all comes together, GE/Durham can accomplish things that are almost unheard of -- even in the world of sophisticated manufacturing. Although comparisons between GE plants are difficult--no two plants do exactly the same kind of work, with exactly the same kind of overhead to support it--Bob McEwan, who has authority over GE/Durham says simply, "They are the best in the GE Aircraft Engines division." The most interesting measure may be one that the people at GE/Durham talk about themselves. They don't really think that their main job it so make jet engines. They think that their main job is to make jet engines better. Amazing. But you don't have to be a highly skilled worker making jet engines to see this at work. Anyone flying on Southwest Airlines has seen this too. Scott Gatz, in Trusting a community to get it right, observed the following: You might think that the SWA gates would be a madhouse, but in fact they are very orderly. People arrive and begin to lineup into three lines (A, B and C) in a quite orderly fashion. People in each row are cordial to each other asking “is this the line for B to san diego?” and exchanging niceties and often that question allows people to break into a friendly conversation. If you were to look at the gate area from above, you’d see what looks like three branches on a tree, they curve around the furniture and the walls, but they are a line. He goes on to compare it with America West: A throng of people surrounded the doorway to their gate, each trying to push past each each other so they could get to their seat earlier (even though they know they are guaranteed to sit in the same seat no matter how quickly they board). And he connected the dots: It struck me that this is a lot like community on the web, if you give people a little guidance and a benefit, they’ll actually organize themselves just fine. On SWA, the benefit of being orderly is a smoother travel experience and a good seat and the guidance is telling people where they stand — those that are in line C know that no amount of pushing will get them good seats and those in A know that they are gonna be in a seat they like no matter what. On AW, they don’t ask anything of the traveller, they don’t trust the travellers to line up, they treat travel as a solitary experience “every man for themselves”. And it shows. Duh, right? Well, maybe. On the web, we’ve seen some really interesting communities grow: flickr, delicious, craigslist. All of them give benefits to people in the community (tags make it easier to find stuff, the tools allow you to connect with friends or meet new people or sell stuff, etc) and all give a simple amount of guidance “to get those benefits, we’d like you to tag, post, rate, report bad stuff, etc”. And you know, the community organizes itself. Those communities police themselves a bit. There’s abuse (”people cutting line”), but its buried deep down in the site because the community won’t rate it or will report it. Those communities help me find where the good stuff is, because, that’s what they’d want someone to do for them. And the sites actually ask people to do it and reward people for doing it right. Really quite simple. To summarize: give people some trust and authority. They deserve it. You'll be amazed at what they can do without you supervising their every move. It works for employees and customers. Related Link
Posted by Terry Howard @ 2/22/2006 I've had a tab open in my browser pointing at Tom's Native to a Web of Data slide for a few days now. It's been nagging me. I needed to do something with the ideas encapsulated in that one slide, and tonight it struck me while I was doing something completely unrelated. Though I wasn't at his presentation and haven't talked with Tom about this, I've decided to annotate (some may say "translate") them for the benefit of the typical MBA laden, non-engineering focused Product Manager that you might find at a large Internet company... or anyone else who cares, really. :-) Look to add value to the Aggregate Web of data As a company with infrastructure that can scale to scan, retrieve, and analyze a significant portion of all the public on-line information in the world, think about how you can use those capabilities to improve the world. What can you do that someone looking at a much smaller set of the data cannot? What patterns can be found? What connections can be made? What can you simplify for people? Build for normal users, developers, and machines Make whatever you build easy to use, easy to hack, and make it emit useful data in a structured form. That means you need a usability geek, an API geek, and probably an XML/RSS/JSON geek. Start designing with data, not pages Figure out what data is important, how it will be stored, represented, and transferred. Think about the generic services that one can build on top of that repository. Only then should you get the wireframe geeks and/or the photshop geeks involved. This is scary, because you won't have a mock-up right away. Your PowerPoint presentations will look as if they're missing something. But that's okay. This is about doing some engineering style design before product design and interface mocks. Identify your first order objects and make them addressable Figure out what your service is fundamentally about. If it's a social shopping application, you're probably dealing with people, items, and lists of items. Nail those before going farther. And make sure there's a way to access each object type from the outside world. That means there's a URL for fetching information about an item, a list, etc. These are the building blocks that you'll use to make more complex things later on. Hopefully others will too. Use readable, reliable, and hackable URLs If the URL is hard to read over the phone or wraps in email, you're not there yet. Simplicity and predictability rule here. Consider something like http://socialshopping.com/item/12345. You can guess what that URL does, can't you? You may not grasp how important this is, but don't let that stop you from worry about it. This stuff really does matter. Look at how most URLs in del.icio.us are guessable and simple. Mimic that. Correlate with external identifier schemes Don't go inventing complete new ways to represent and/or structure things if there's already an established mechanism that'd work. Not only is such effort wasteful, it significantly lowers the chance that others will adopt it and help to strengthen the platform you're building. You are building a platform, whether you believe it or not. Build list views and batch manipulation interfaces Make it easy to see all items of a given type and make it possible to edit them as a group. Flickr does this when you upload a batch of photos. Search, in its many forms, is the classic example of a "list view." Create parallel data services using standards Developers (and the code they write) will want to consume your data. Do not make this an afterthought. Get your engineers thinking about how they might use the data, and make sure they design the product to support those fantasies. Again, always default to using an existing standard or extending one when necessary. Look at how flexible RSS and Atom are. Don't re-invent the wheel. Make your data as discoverable as possible The names and attributes you use should be descriptive to users and developers, not merely a byproduct of the proprietary internal system upon which they're built. This means thinking like an outsider and doing a bit of extra work. Related Link |
||||||||||