Don't Forget to Plant It!

Skribit March’in On…

(pun intended.)

Skribit Logo

So a couple of weeks ago, we knocked out our third release of Skribit into production. The Skribit team has done a great job of covering what is in the latest release, so I don’t it isn’t necessary to cover what we’ve added here.

So what is the real value of Skribit? Before Skribit, things look a lot like this:

Bloggers posted and readers read the posts and commented on the post. Occasionally, comments will lead into more posts, but still, bloggers for the most part led the conversation. Sometimes you’ll get emails, instant messages or direct conversations asking you to write about something, but they only come from people who can reach you directly. Also, you have no idea if the rest of your readers are interested in that same subject.

With Skribit, things now look more like this:

By using Skribit and taking in suggestions, bloggers can now have their readers lead conversations, as well as gain better understand who their reader are.

Another thing important about this release is that it’s a declaration Skribit hasn’t croaked (oops) and we’re still hoppin’ (yep, sorry!) along. And beyond the initial idea of Skribit we’ve developed the plan will make Skribit a real awesome product.

So please, go sign up on Skribit and join in the conversation. And let us know what you think!

My Thoughts on Atlanta Startup Weekend

Here are some of my thoughts on Startup Weekend and in particular, Atlanta’s Startup Weekend.  I suggest everyone read Micah’s accounts of ASW as well.  He wasn’t there when we were finally able to turn it around Sat. night, but his account was pretty accurate up to that point.

 So here goes:

  • StartupWeekend is not your traditional startup.  Most Startups usually start with an idea before building the team, which means the team would have already bought into the idea.  Traditional Startups also have a core group from which the idea originates from.  In SW, there is no initial idea to begin with, and everyone has an input on what the ultimate idea should be.  It’s now a week later and I’m still surprise that we actually chose an idea.  It’s very hard to run a company as a democracy.  We probably should have elected a person in each of the subgroups to help come to a final decision.
  • Unless your normal job involves delivering a product from conception to production in 2 1/2 days, don’t expect any ‘This is the way I’ve always done it’ to fly.  It didn’t seem like many of us were working in a mindset of having to finish something in 2 days.  I admit I was guilty of that as well.
  • The whole team was split up into separate sub-groups (dev, marketing, biz-dev, etc.), and I didn’t get an opportunity to work with them as much as I would have liked to.  There were a lot of interesting, heated discussions going on everywhere, but there was no realistic scenario where I can participate in them and get the development that needed to be done finished by the Sunday.  There really should be a ‘MockupWeekend’, where people get together just to find, build, and mock up the idea in a weekend.
  • From a development standpoint, we got ourselves into trouble by often classifying things as ‘easy’.  Our gauge of what ‘easy’ is is normally in the context of no less than a week.  In a weekend, nothing is really ‘easy’.  So what problems did this cause?  For one, we were constantly pushing the easy things til the end, which is smart in the traditional development sense, but when you have an overabundance of developers, it makes sense to identify those easy tasks and get people started working on them.  Calling things out as easy too often also opened up the flood gates to additional features that weren’t necessarily vital to the launch of the product.
  • ASW would have benefitted if Andrew brought more structure into group, but I think ultimately Startup Weekend would suffer if was ran that way.  This was Atlanta’s opportunity to show what we could do, and from a self-organizing standpoint, we did pretty poorly.  Ultimately though, we did learned how to work together, and no doubt if we did this again we would be much better at it.  If there was one thing we did do well, and that was when it came down to crunchtime, we rocked it.

Keys to Success

Like Micah said, at some point on Saturday night, the momentum started to turn in our favor.  As always, there were probably many things working together that helped turn the ship, but I felt there were a few things that were key. This is from development side – I had to shut myself from the other groups otherwise I couldn’t have focused on doing actual development.

  • Jason and Alan was finally able to get on top of the situation and make themselves gate keeper of what development was supposed to be building.  Before then, we were getting conflicting requirements left and right.
  • Jeff, Amro, and Andrew from Appcelerator jumped in a took the task of the developing the widget using appcelerator, while the rest of us worked on the website with traditional Rails.  I was one of those that was originally wary of using Appcelerator, but in the end it looked like appcelerator was a very good fit – at least on the widget side.  More importantly, it put together a team that was already used to with working with one another hammering away at probably our most complex task.
  • There were a lot of devs that really came through and filled in the gaps where help was needed. I can’t stress how important this was, to have people filling in doing sysadmin, CSS/layouts, and other small but definitely-not-insignificant details that really helped. I see these things as the 20% that always takes 80% of the time, and having people fill in where ever they can really helped a lot.

In later posts, I’m going to a recap of the events.  I’d also like to talk a little more about Skribit, which I have high hopes for.

Day After Startup Weekend

Skribit Logo

I’m about to head to work after 2 1/2 long days and nights of Startup Weekend, but I wanted to make sure I at least posted something about it. I’m sure I’ll have more to say about it as I replay all the events in head, but overall it was a blast. It was roller coaster ride of emotions compressed into less than 60 hours, and while there were many moments of frustration over the course of this weekend, it only made the ending so much sweeter.

Introducing MyNextDive

There are some things – buying your first home (check), getting married (check), having babies (no check) – that seem like you’re never ready for. Those things are always blocked by some other thing in the horizon that you want to wait for before taking the big leap. Determining when you want to get your application is ready to put in front of users apparently is one of those things.

Since the beginning of this year, Neil Green and I have been working on MyNextDive. We’ve always said that we needed this or that feature before we’re ready, but either the features move further and further away, or more ‘must have’ features appear. It was comforting to us that we had technical hurdles facing of us (familiar), instead of non-technical ones (unfamiliar).

MyNextDive has been available online for a few months now, but we’ve never made a concerted effort to get people to our site. If you wanted to find us you could, but the Internet just doesn’t work that way.

So we’ve put a line in the sand. We’ve dropped the features that has so far eluded us, some of which are half done. Some really kick ass features. We’ll come back and revisit them later, but we can’t let them be a drag to us any longer. We need MND going and dragging us along, and not the other way around.

So what is MyNextDive? We want to build the ultimate application for planning scuba vacations. If I have to pick 3 things I want MND to do, it would be:

  1. Make planning and discovering scuba trips fun and exciting for divers.
  2. Create a place where scuba divers can get together and plan a group vacation together.
  3. Create the most comprehensive directory of dive sites on the web.

As you can see, we have a long way to go, and we could use some help. If you’re a scuba diver, please check out MyNextDive and let us know what you think. If you have friends that are scuba divers, please tell them about our site. If you’re just curious and think ‘scuba’ is a funny sounding word, we’d love to hear from you too. Just note that it is still rough around the edges (we’ll be slapping on the mandatory web2.0 ‘beta’ label soon), so please be gentle.

This decision to launch has already provided immediate benefit, because it forced use to focus our energy on figuring out those things unfamiliar. Now we have found a clear path of action, and the clarity is so that I’m very excited for what’s coming next. Stay tuned.

Running Intense Debate on My Blog

I was lucky in enough to get invited into the closed Intense Debate a few weeks ago, and after a stumble here and there I was able to get the ID plugin installed and working on this blog. Now all new comments be going to be handled by Intense Debate instead of WordPress.

In case you don’t know what Intense Debate is, it’s a blog comment service that can hook into MovableType, WordPress, and Blogger. It enhances the old comment system by adding things like threaded conversations, reputations, and avatars, but also allows me to keep track of my comments and my friends comments – provided that they are commenting on blogs that use the Intense Debate comment system. Checkout my Intense Debate profile page to get a sense of what ID can do.

Please give the plugin a test drive – post a comment and tell me what you think.

Lifestreaming Using Yahoo! Pipes

Some of you might have noticed that I recently added a What I’m up to feature on my blog. While I’m not normally a frequent blogger (I actually consider that a feature of this blog), I am pretty active elsewhere on the internet. So I thought it would be cool to create an aggregated feed of my online activities, commonly referred to as a Lifestream. This seemed like the perfect job for Yahoo! Pipes and apparently I’m not alone in that thought.

In case you’ve been in a non-WIFI enabled cave the last few months, here’s Yahoo!’s description of what Pipes does:

Pipes is a powerful composition tool to aggregate, manipulate, and mashup content from around the web.

Essentially, Pipes is an ETL tool for web data, with resulting output being an RSS feed, JSON data, or web widget.

Being that I’m already using Web version 2.0, most of my activity on the internet culminates into some sort of RSS feed. Off the top of my head, I chose to compose my lifestream from my twitter and delicious accounts, as well as a couple of forums that I monitor (shameless plug – Boardista is a forums website I’m currently working on).

So here’s how I created my Lifestream feed. Here’s my Pipes page if you want to follow along. Initially, I had everything in one large Pipe, but quickly decided to break them up to make things more maintainable. One really cool thing about Pipes is that it allows you to break up large Pipes into smaller, interconnected ones, making things easier to manage.

First, I fetched my twitter, delicious, and forum feeds using the Fetch Feed module. I do this in the LifeStream: Twitter/Delicious/Forums Pipes. I separated them out because each type of feed had some characteristics that I wanted to transform from so that when I merged them individual items had some level of consistency with each other. I also wanted to modify the author of each item so that I could later render an icon to identify the source of the item.

Second, I merged the individual feeds into one large one (Pipe Lifestream: Merge Sources):

Then, I sorted the feeds, chopped the feed to only show the last 5 items, and truncated the description to 150 characters if necessary (Pipe LifeStream).

Finally, I needed a way to show this on my blog. I really liked how Andy Bennett showed his latest twitter on his blog, so I wanted to have something like that. Doing some research online, I was able to find the KB Advanced RSS Widget which did mostly what I wanted, all I had to do is tweak it to show the correct icon based on the author I set in the first step.

So after few hours of work, I had a pretty cool Lifestream feed. Overtime, I expect to add more feeds to make my lifestream more complete (I would love to add my coComment feed, if I can only get my actual comment in the feed).

I’ve also learned quite a bit about Yahoo! Pipes:

  • It’s pretty amazing what you can accomplish with such a finite set of functionality.
  • I’m skeptical that your average internet users is going to be able to build truly useful Pipe without help. I was often frustrated by how Pipes wouldn’t let me connect some modules, and by how some controls were enabled/disabled by some seemingly illogical condition.
  • Being able to interconnect Pipes can potentially create some amazing results. It would be even cooler if I can plug in other people’s Pipes.
  • There’s a Web Service functionality available that allow developers to provide some custom transformations for Pipes, which gives Pipes virtually unlimited capabilities. It also means that you can potentially use Pipes to push data to your application.

A Spreadsheet for the Web

No, I don’t mean a web-based version of Excel, but an application that does for live web data what the spreadsheet did for static cell data. This type of application is commonly referred to as the mashup editor, which there are a few of out there, but are more like the “IDE for the Web” than a spreadsheet.

A couple of days ago, I found Strata, which is an interesting contender in this space. From the website:

Kirix Strata is a new specialty browser for accessing and manipulating data from the web. View and work with data from web tables, CSV files and RSS feeds, integrate information from web services to create personal “desktop mashups,” browse and work with MySQL, Oracle and other databases.

It’s basically a browser that understands web data such as HTML tables and RSS, and allows you to link them to other sources of data, including databases and web services. Since it’s in beta, it is still very basic, but its upside is great; wrapping these capabilities in a browser allows a user to build an application more organically, which I can imagine will lead to some interesting results. There are some more functionality I would like to see:

  • Microformats support - it’ll be cool if it could suck up microformats or RDFs as data.
  • Easier Web API support - I’d like to be able access web APIs without having to jump into scripting. Maybe Strata can define a API spec standard, sort of like a WSDL (but not as cumbersome).
  • Some Support for ‘Mashable’ Websites - I like how the latest version of Flock auto-detects certain social networks, I wonder if Strata could leverage this as well.