TheWorldIsNotFlat.com (TwinF) is a companion site for our trip around the world in 2006. It has been in the works since December of 2004, when we decided to do the trip and reserved the url: theworldisnotflat.com.
As you may know, designing social web sites is my day job and I wanted to take this opportunity and create a site for our trip that would be an example of my work. This entry documents the experience of building TwinF.
What TwinF Does, and Why
TwinF really only does two things:
- Enable Our Travel Blog, now called "Our Dispatches"
- Collect First-Hand Travel Experiences, called "Member Travel Experiences"
As we started to tell people about the trip, they would always say "Oh,
you must go here and do that" and we would write it down on a handy piece of paper and promptly lose it.
So, addressing this problem with a web site seemed like a no-brainer. We figured that if we could collect and organize all these valuable experiences, we could use the information to have a better trip.
Itâ€™s a simple concept, but we put a lot of thought into it. And, when I say â€œour storyâ€?? and "we" I mean my wife Sachi and myself. She was a part of virtually every decision.
Beginning: Constraining the Opportunities
In thinking about all the things we could do with TwinF, it became clear that we needed constraints. We needed a way to ensure that could accomplish our goals without trying to be everything to everyone (a surefire way to fail).
We had to consider the long-term possibilities. What if it became popular? What if it got too big? What if it demanded too much of our time as we traveled? What if worrying about TwinF impacted the trip?
This perspective enabled us to limit the things we should do. For instance, we considered building a platform for travelers like us to have their own travel sites. If that idea worked, it could consume our time and potentially prevent us from having a good trip. So, we marked it off the list.
Our first constraint and overall guiding principle: We want to have a good trip more than we want to have a good web site.
We are focused on the trip and the traveling experience, not the success of the web site. By looking at it this way, we could ensure that the site doesnâ€™t become a burden.
Applying this concept to the design and goals of the site means making decisions about who the site is ultimately for. Who are the primary users and what are their goals?
That was easy: we're the primary users, and the goal is to have a good trip. By focusing purely on our needs and goals, we could design a site that accounts for our needs only.
While it sounds selfish, it works in this situation because it frees us from the accountability of others. The moment we design the site around the goals of others is the moment we become accountable to them. Being accountable to other people on the trip like this is not acceptable for us.
So, we designed TwinF to be all about our trip. We are not accountable for anyone elseâ€™s experience and if the site becomes a burden, we are prepared to turn it off and move on with the trip.
Next, we considered our goals- what are we trying to do with TwinF?
â€œCommunityâ€?? is Not the Primary Goal
Those that know my line of work would expect me to create more of a
travel "community". Community is an element, but not a goal of TwinF. Lively, interesting and useful communities often take time to manage and administer- time we won't have.
However, we did see an opportunity to use social tools to accomplish our goals without the worry of building a community. Our goal became to collect and organize first-hand travel experiences.
This constraint helped us to reduce the features and options that would
be available on the site. We don't care if people don't feel the need to come back; TwinF is not about repeat visits or a feeling of membership, it's about collecting travel information. If someone comes and adds an experience and never comes back- that is a success.
Collecting Travel Experiences
We considered collecting and organizing the experiences of members - how would it work? We asked ourselves: What is the easiest way for someone to drop off information on a web site? Our answer was via a blog entry.
Blog entries are the basic unit of communication, partially inspired by our Robot friends at 43 Things. Again, this put the focus on the experiences of the members and not the discussions between them.
Organizing the Travel Experiences
The next big question was how the Member Experiences would be organized. Being that the site is focused on our needs, we considered how we would want to see the experiences organized. We envisioned a scenario where we were about to fly to Japan and wanted to quickly view the experiences share by TwinF members regarding Japan. This showed us that the basic unit of organization was by country.
By organizing the travel experiences by country and making the basic unit blog entries, each country page essentially becomes a blog based on all membersâ€™ experiences from each country.
We also saw an opportunity to filter the information by category â€“ we envisioned a scenario where we might want to see only the entries about â€œsight seeingâ€?? in Japan. So, we came up with a common set of categories for each country.
Rating the Member Travel Experiences
Member travel Experiences are an interesting element of the site. They are not as time sensitive as a blog entry. They have a longer shelf life and their quality relates to quality storytelling and nice pictures, for example. We considered ways to reward or positively reinforce the things we like about Member Experiences.
We could leave nice comments, but we needed a quick way for us and other members to easily provide feedback. In enabling a quick feedback mechanism, we could reinforce the positive elements of experiences.
So, we enabled a five-star rating system for the member experiences with the highest rating being â€œAwesome!â€?? and the lowest rating being â€œNothing Newâ€??.
Designing Our Travel Blog- â€œOur Dispatchesâ€??
With the basic concepts in place for the Member Experiences, we focused on our blog for the trip. Being a travel blog, we saw some opportunities to integrate our blogging with a couple of new technologies.
In June of 2005, Google opened the API to Google Maps, enabling the reuse of the map information on other sites. The goal for us was to use the mapping to display up-to-date geographic information on our blog posts from around the globe. We wanted readers to be able to navigate all of Our Dispatches by clicking location markers on a global map, which then reveal our blog posts from that location.
Further, we wanted to integrate a local map with each of our blog posts so that a map displayed with the post, indicating the specific location of the blog post.
To do this, we needed GPS coordinates for all our locations. Currently, we can look up coordinates by entering city and country names into the blog entry form, which pings a database and returns to coordinates for us- so cool! Big shout out to Bryght guy Colin Brumelle for the Map API and Ajax wizardry.
Tagging Dispatches with â€œKeywordsâ€??
Originally, we had 6 specific categories for Our Dispatches. These categories were somewhat limiting and we had an opportunity to use tags to organize Our Dispatches instead. For us, tags provide a much more granular and free-form means of organizing Our Dispatches. Instead of assigning a post to a category like â€œpreparationâ€?? we can assign a host of key words such as: preparation, backpack, mood, seattle, packing.
The tags are purely under our control; no one can tag Our Dispatches but us. While opening the tagging to the members might be interesting, it could also create more administration than weâ€™re prepared to handle on the trip. So, no member tagging of Our Dispatches.
Also, tagging Our Dispatches means that we build up enough keywords to display the tags as a tag cloud, offering visitors a new means of navigating the content of the Dispatches.
Experiences and Dispatches Working Together
Consider this scenario: We are a week away from flying to Japan, and we notice that there aren't many Member Experiences in the "Places to Stay" category of the Japan country page.
In this case, we could use the Dispatches to put out a call to all
readers that says "We're looking for help. We're going to Japan next
and need some information about places to stay. Please add your
Experience to the Japan page." I which case, people might heed our call and choose to help.
Another major consideration was trying to reduce the infiltration of spammers, who would surely have an impact on the site and the trip. Though it would reduce the amount of participation on the site, we decided to require registration for all participation.
Getting TwinF Built
Many of the concepts above were on the table before we ever considered the technological platform. Early in 2005, I got to be friends with the guys at Bryght, who are enabling hosted sites built on the open source Drupal platform. Through lots of discussions with Boris Mann, it became clear that Drupal would work and Bryght could help. We all agreed that making TwinF work could be a win-win.
The key about Drupal is that it provides the raw materials for what we needed to do. Off the shelf it wouldnâ€™t work, but with some customization, it could work like a charm.
One of the first goals was to get the basic structure in-place as described above. Thanks to the help of Richard Eriksson, the basic structure came together in short order.
We started to think about the graphic design. We wanted it professionally designed and had very specific ideas about how the site would communicate with the visitor via the design.
The primary objective was simplicity. With the site only doing two basic things, the design should be built around communicating what those two things are and how they are used.
After 4-5 mockups we finally chose a basic design and started working to make it a reality. I worked closely with Mark Yuasa at Rain City who is a talented designer who worked hard to make the deadlines (which he did).
One of the primary problems that needed solving was making sure the visitors could discern the difference between the Dispatches and the Member Experiences.
First, we made sure that each resource had a distinct and memorable name. We figured that calling the travel blog â€œOur Dispatchesâ€?? would brand it in a memorable way.
Also, we created little headers for each page that we called â€œmini-missionsâ€??. These describe the resource and how it is used. This way, someone stumbling upon the site can have a little more context and a way to understand that there are 2 different things going on. See the top of this page.
Letting People Use It
Though the site was not officially rolled out, it was publicly available for months before it was finished. We invited friends to log in and use it. We gathered feedback during the iterations of the design. Though we didnâ€™t do official usability testing, letting people use it gave us good information about what was and was not working.
I am a big believer in RSS and I think it will never be more mainstream until we get away from the little orange xml buttons that are meaningless to non-technical people. Also, itâ€™s never clear enough to me what content is being provided in the RSS feed when an XML button is displayed.
So, I asked Mark to find a way to display the RSS feed in an unobtrusive way so that people can understand what it is. He came up with two different buttons: â€œDispatches Feedâ€?? and â€œExperiences Feedâ€??. These enact the things that I believe about how RSS should be displayed.
The Last Tweaks
The deadline for the site being ready for primetime was October 1, 2005. Up until the final hours, changes were still being made. The Google Maps integration and the use of tag clouds were some of the final changes. On October 4th, 2005 the site went live.
At Time of Writing
So far it has been exciting to watch the site grow. Weâ€™re about two weeks in and have over 130 members with more members and Travel Experiences coming every day. Our biggest day so far has been October 12th, when we had over 1200 unique visitors and 3700 page views.
Right now our sights are set on the trip and how weâ€™ll use TwinF as we travel. We hope that our departure will open up new and more interesting aspects of the site.
I hope that this document is interesting and I'm excited that you've read down this far. For us, it has some personal historical value that we wanted to document. At the very least, it provides a look at what we were trying to do at this point in our history- a milemarker of sorts. So much is unknown about our future and the future of TwinF, but we can always look back at this and compare it to what actually happened.