Favicons can be fabulous, I mentioned the Dopplr one in the book. Today, I thought this post about favicons on ThoughtBot's blog gave a useful summary of them and some fun examples. I wanted to highlight the excellent idea of setting a different favicon for each server that you are using to test, stage and deploy. This is a tremendous idea from Joe Alba. In the book I recommend adding in a line above the general site design to say TEST or STAGING etc, but using a colour change in the favicon is much cleaner and saves additional complexity in your code. You could also use a simple T or S to denote the non-live server versions.
Google Buzz launched last week in rapid fashion to a mixed reception. Using email, which is inherently private as the means for generating a public social network seems like an odd decision when put as starkly as that. The address book inside GMail is a valuable resource, it does represent the people that someone is in contact with, but using this alone is a weakness. There have been some strong reactions to the seeming breach of privacy that Buzz created. Google have rapidly revised the product to fix this private to public disclosure, but I wanted to explore how they might have made these initial product decisions they way they did.
GMail has many tens of millions of users, other Google applications do not have anywhere near as many. So it is a tempting place to base a new realtime sharing application. Google Reader is not nearly so widely used, RSS feed reading is much less mainstream than email. So by choosing GMail as the host application, it was probably hard to factor in other sources of data and keep a consistent experience for different sets of users. Drawing on Google Talk chats, Google Reader subscriptions and the GMaill frequent contacts would have generated a more accurate social model for the person, but limited the number of users. A much smaller number of people would use all three applications and so benefit from a more coherent social model.
The other aspect of this is the initial decision to make Buzz automatic, without a confirmation step. I think this came about as a result of testing and belief in the product. Along with a desire to avoid the blank slate experience. Social application testing requires a set of social networks to be created. This is time consuming to set up, so the idea of automating it seems attractive. Also people who are testing the application are likely to be heavy users of the host GMail application. So people who have a gmail account, but their primary email is elsewhere will be poorly represented in this testing. For many people GMail is an additional account for other professional activity, so having clients and former partners automatically added is a disaster for them. These cases will be far outside the testing community that Google will have had for Buzz. You are not your user community is just as true for general purpose tools like GMail as it is for other areas.
Social tools should never automatically act on our behalf without a confirmation phase, except when the outcome is known and obvious. The set up stage of a new software product is something that must require confirmation. Buzz now does offer this important step.
Rapid turnaround is a good thing, but also considering the needs of non-mainstream users who can be affected by your initial product decisions is important too. There is definitely a strong product in socially filtered activity streams, but using multiple sources of interest in a person is required to determine if that person is relevant. Simply email someone a lot is not enough, it is good to see this being tested at a large scale.
More on geo and Google Buzz in a bit, but I thought I'd post this comment by Steve Baker on the five nations in the USA for Facebook visualization that is doing the rounds at the minute.
I am an engineer for Oodle, the company that runs Facebook Marketplace. One of the things we noticed the day we launched Marketplace was that many folks with traditional Arab names (such as the ones above) were posting classified listings from places such as Cairo, Illinois, and Alexandria, Louisiana. Upon further review, we realized that an autocomplete feature we had built for a location textbox was taking the values "Cairo" and "Alexandria" and completing those names out to US locations with the same name. In other words, folks would just type in a location of "Cairo" for their listing, hit enter, and it became Cairo, Illinois.
In the chapter on data modeling I sort of assumed that you will model the entire world at the start, but encourage people to come from your home country at first. This comment shows that you really do need to think about the whole world up front.
A few recent events have pointed at the importance of the app store for supporting your own platform if you have an API. Several companies have launched an app store recently, Flickr have their new App Garden, Ribbit, the new-ish mobile voice company owned by BT has an app store. Twitter have allowed oneforty to take this role in their market.
An app store shows off your own platform and will draw developers to make apps, if the app store is a good one. Apple get a lot of flack for the rejection policy and arbitrary nature of managing the app store for the iPhone, a lot of it is justified, but there is no doubting that 100k apps is a lot, as tracked by appshopper in late October. The iPhone app store is a pretty easy to use interface and it is a single place to go to for iPhone apps. It is unlikely that any web app can enforce this single venue, but you can make the most popular one, as you run the platform. These kinds of app stores pre-iPhone had a bad reputation coming from poor PDA-based sites of the past. So most social software companies did not see the utility of a central clearing house for promoting the apps created for their plaform. Supporting actual users and developers can be quite enough work. However an app store (even if you don't sell the apps) is a great place to connect the developer community with the user community.
If you have a good API with solid developer support and an active community then an app store is the next logical step, but don't create the app store in advance of either of these. An empty store is a sad place.
I'll be posting more regularly here from now on, covering nice ideas I see which would have gone in to the book if I was still writing it. Today's example is a small aspect of the new Flickr People in Photos service. On top of building an easy to use interface for adding people there are lots of clever user interface details that enrich the experience.
The ability to add multiple people on a photo is good, if straight forward use of the XMLHTTPRequest Ajax functionality. Where it becomes more elegant is that you can simply drag to mark out someone's face and choose between note or a person and name that person in the same simple interaction. What prompted me to write this post was the delighter that is hidden on the pictures of your contacts page, when you have a photo containing more than one of your contacts.
This image shows two of my friends in the same picture, the use of and&ellip; rather than repeating the A photo of reflect natural human speech. Lovely, this image shows what happens if you have four or more. You get yay and wow comments too. Functionality like this only comes from spending time testing and exploring the user interface beyond the merely functional. It is worth the extra effort to make your own features as shiny.
Hello and welcome, Building Social Web Applications is available on Safari today. This website will gain the bibliography I mentioned in the book in the next few days. I hope you enjoy the book.
While I create the bibliography, why not have a look at the conference talks I've given recently.
While I create the bibliography, why not have a look at the conference talks I've given recently.
