Getting Real

I just got done with the book “Getting Real” by 37Signals. This book is a bible for anyone looking to start a web app using minimal resources without sacrificing quality.  “Getting Real” is divided into 16 chapters and covers planning your application up to launching and supporting your application. Each chapter consists of sections that talk about a certain aspect of the chapter. For example, the chapter on supporting your application has a section on setting up forums, a section on why the developers should be on the support frontline, and how to prioritize bug fixes. Each section is backed up by essays and quotes from various people who have been through the web app process . I strongly recommend anyone who is thinking about or is in the middle of developing a web app to check out this book. If anything, it lets you know where they’re coming from when they developed applications such as Basecamp.  Let’s check out some of the important concepts that we’re presented with.

  1. Don’t worry about the details; just make a decision. Don’t waste time arguing about the small details of your web app. The type font type used, border size, all don’t matter when it comes to the core of your application. Learn to make a quick decision and move on. Your users will give you feedback to let you know whether or not you’re on the right trail or not.

  2. Include only the most necessary features in “1.0” Don’t add any unnecessary features; in fact a lot of the features that you think are necessary may really not be. Cut these features out and include them in a future release. An example they gave was a billing system when they deployed Basecamp. The feature wasn’t necessary until 1 month after their initial release because that’s when their users got billed. Instead they released Basecamp and then worked on it. This was plenty of time to create the feature and everything worked out.

  3. Iterate as you go. The nice thing about web apps is that you can instantly deploy bug fixes and new features to your users. This allows you to be competitive since you are able to easily adapt to change and rapidly make fixes. You’re also able to receive instant feedback from your users as you make fixes and/or deploy bug fixes.

  4. Create your interface first. Start off with some sketches on a piece of paper and then maybe convert it into HTML/CSS. The reason to do this is because the interface is easier to modify as opposed to re-writing code. As you create your mock-ups questions will be brought up and decisions will be made. It’s better to make those decisions at this stage rather than after you’re into hardcore coding.

  5. Learn to market your site from day one. Include a teaser on your front page, screenshots of previews, blog about the development process and features that will be included in the initial release, use invite codes. All of this will create a buzz about your product. When it comes to invite codes, have users submit their email addresses to be notified when more invites will be available. You’ll at least now have a list of people who have expressed interest in your app and they can be notified when your initial release comes out.

  6. Become your own support department. Dealing with your users on a direct basis allows you to get into their mind and get instant feedback. The people who are developing the application should be answering questions, defending their choices and taking criticism. Be sure to consider a FAQ page and forums so that users can help themselves and other users.

I’ve really only scratched the surface of what this book has to offer. Check out the rest here!

A Look at the Practical Applications of Microformats

HTML used to semantically describe what information looks like. HTML is now leaving the styling of information up to Cascading Style Sheets and is becoming more interested in describing what the data is. There are tags to let the browser know what information is a header, paragraph, list, etc. Microformats take the concept of describing data up a notch. Microformats are pieces of semantic data embedded into HTML that uses existing standards to describe what the information is. Once a user agent (such as a web browser) knows what certain pieces of data are, it can export the data to a more appropriate context. In this article we’re going to look at two microformats in particular: hCard, hCalendar.

Both hCard and hCalendar are based off of already existing standards (vCard – RFC#2426 and iCalelndar – RFC#2445 respectively). With some XSLT transformations or Javascript parsing, we can export the microformatted data in a webpage to other pages or into other data formats. For example, sites like upcoming.org mark up events with the hCalendar microformat. If we plan on attending these events, we can add it our Google Calendar, Yahoo Calendar, or 30Boxes to remind us about the event at a later date.

One of, if not the most popular microformat user-agent is the Firefox extension Operator by Michael Kaply. Currently, Michael is working on adding microformat functionality and javascript functions for microformats to Firefox 3. This means we’ll be seeing a lot of these features in the next version of Firefox. Operator supports a wide range of microformats, but as previously mentioned we’re only going to stick to hCard, hCalendar and we’re going to talk a bit about rel-tag. The premise of operator is simple: if it detects any microformatted data, it allows you to take some sort of action. If you find a person or place marked up with hCard, you can export it as a vCard or add to yahoo contacts. Exporting an hCard as a vCard will allow you to save a contact to programs like Address Book, Outlook or any program that supports the vCard standard.

I’ve already mentioned what you can do with information marked up with hCalendar, so let’s look at rel-tag. Rel-tag is simply marking up up the “rel” property of a hyperlink with the value “tag.” Once Operator knows that the link is a tag, it can then look for that same tag at sites like flickr, technorati, and del.icio.us. A common use for tags is looking up additional information about something you’re reading. Blog posts for example are usually tagged, so people can find pictures on flickr, related blog posts on technorati, or related sites on del.icio.us.

Let’s take a moment to recap and see why we like microformats and operator. For one we don’t have to input data ourselves. Since the data is already online we’re simply copying it to our application of choice. With this comes the advantage of actions becoming point and click. If you want to add an event to your Google Calendar, you point and click on the add to Google Calendar option. Pretty simple.

One area that can benefit from microformats is the cell phone market. I’ve already written about the iPhone as a microformat killer-app, but I wanted to expand this idea to include both cellular phones and internet-enabled PDAs. Cell phones and PDAs both have notoriously horrible input interfaces. Don’t you dread typing out a long text message, let alone trying to search for something on a cell phone browser? What about trying to write something out in Graffiti? What if these devices had the point and click ease of use that operator has? With REAL browsers coming to next-gen cell phones such as the iPhone, I see no reason why microformats shouldn’t be a part of this market. Imagine adding a person’s contact information into your cell phone via their hCard. You have all of the information you need about them ready to and be entered into your cell phone at the tap of a stylus. The same can be said about events and adding it to your calendar application on your cell phone or PDA.

With these smaller devices, ease of input usually suffers. In this case microformats make a great alternative to user input and can help overcome these shortcomings. It really can be just as easy as point and click.