I like to post my own thoughts here, but I just read a short blog on Derek Sivers' blog that really hit home for me. He tells the story:

A new green college campus was built, but one thing was still debated:

Where in the grass should we put the paved walkways?

Some felt the walkways should be around the edges, to leave the center green and untouched.

Some felt the walkways should cut diagonal, connecting all buildings to all buildings.

One professor had the winning idea: Don't make any walkways this year. At the end of the year, look at where the grass is worn away, showing us where the students are walking. Then just pave those paths.

I love it! I've seen so many places that have beautifully planned out landscaping that is marred by efficient pedestrians that know that the shortest distance between two points is a straight line.

He goes on to say how we can model our business after this plan. This follows the use of rapid iteration model of software development.

Listen -> Build -> Release
Listen to what people need, listen to their pain points. Build something lightweight that you think people will love and that will remove their pain, build it quickly. Release it before you think it's done. Go back to listening, listen to what they like, what they don't like, and what they want. Go back to building, build what they want. This reduces the amount of time you spend concocting crazy use cases or user models that may or may not exist or spending too much time building something that nobody wants and let's you leverage the wisdom of the crowds. When you're done building you know that you have something that people want to use because they helped you decide on the features.

One example of a company that doesn't seem to do this is of course Apple. Apple (an to an extent Google) has an incredible ability to anticipate what consumers want before they know they want it. To be a true market leader and leap over the competition risks like these are not only desirable but necessary. There is often a time when a consumer doesn't know what they want or need, they just know they don't like what's out there. What was wrong with the Philips GoGear? Before the iPod Touch came out I don't know if I could have put my finger on it. It took Apple's leap of design and development before I realized how many features were missing. This model is significantly riskier, but like all things with risk comes the potential of reward.

Labels: feedback, software development

I recently made the switch from Windows to Mac. Don't panic, I still use bootcamp to boot into Windows regularly for development work, but I'm really making an effort to "be a Mac," at least for a little while.

I just tried to add my Google Calendar as a caldav calendar. My first issue was that you can't use the "Automatic" account type, or even the "Google" account type, you should follow the instructions very carefully on the google calendar help page. Once I followed the instructions carefully my calendar seemed to start to sync.

I use Google Calendar quite a bit, so I'm sure there were quite a few items in there, but after about a minute I became impatient and closed iCal. When I restarted it all my calendars were gone, imagine my surprise :)

I started digging around on the internet, but found nothing that addressed my specific issue. Many crashing iCal issues, but nothing that mentioned iCal simply deleting or not loading the calendars that were there.

I deleted the iCal preferences files found in my ~library/Preferences/ directory (anything that starts with com.apple.iCal) but that didn't help.

The final solution was to go to ~Library/Calendars and move the newly added google calendar to the trash. It seems this got corrupted when it was trying to pull down the data from Google. Once the file was corrupted iCal simply stopped loading any calendars, and displayed a completely blank calendar.

Of course if I were going to recommend a solution to Apple, I would say to alert the user of the corrupted file, ask them if they'd like to keep or delete the file and where it lives on the disk, then (gasp) continue loading all uncorrupted calendars.

Joe

Since becoming a full time chrome user I've begun to see the power of using bookmarklets. A Bookmarklet is a small bit of javascript that you can put in your toolbar to perform some task on the current page your looking at.

InstaPaper
InstaPaper let's you quickly save and read articles that you want to read later but don't have time to right now. It does more than bookmarking the site because it tracks what you've read and syncs it on all your computers and devices. There's an iPhone app that lets you read the articles you've read. Once you've read an article InsaPaper archives the link so you have it for future reference while keeping your current queue uncluttered.

The bookmarklet lets you quickly save an article for future reading, without having to leave the page. This is super useful if something looks interesting but turns out to be a lot longer than you were anticipating.

Bookmark on Delicious
I've started to bookmark interesting links on delicious. This is a nice way to organize and share links with people. Without tagging I tend create a huge, flat list of bookmarks on each browser I use, on each computer I use. Since my alter ego is a web developer I tend to use a lot of browsers on all my computers on all the different VMs, so this can quickly fail to scale properly.

This bookmarklet lets me quickly save a page to delicious without having to leave the interesting page I'm currently on.

Readability
When I do get around to reading the articles I want to read Readability makes it much easier on the eyes. This reduces clutter on the page by doing a very nice job of removing the ads, images and making the text uniform. You can configure what it looks like to suit your preferences.