Tag Archives: ux

Reflections on startup life: Week 56

When I consider that last week I touched on 5 out of 5 projects, started learning a new language and framework, plus spoke at the Australian Language Technology Association conference on Thursday afternoon, I think I know why I feel like I'm doing about 10 jobs.

The vast majority of the week (40+) was on the new Rails Challenge project.  This has been interesting, not least because as we've tracked through it, it's quickly apparent (as we expected to some extent) that it's less and less about technology and more and more about scope, documentaton, design, architecture and so forth.  While in theory I've always understood this, it's a neat trick to try something completely new and see how far that gets you.

For Tribalytic we discovered it's allergic to Christmas.  More specifically a carefully constructed search term will crash a process and grind the server to a halt (no, I'm not telling you what it is and no, I don't want you to try find more!).  Will be fixed shortly and in any case, it's only happened a couple of times in 6 months.

We are feeling comfortable enough with Trunk.ly now that we added a wide range of new users.  We launched to a new round of 150 beta testers, which if they all sign up (unlikely), will take us to close to 200 users testing it for us.

The best thing about this time of year though is all the end of year catch up and parties.  I've made some great new friends this year and it's fun to catch up with them all, enjoy a drink or two and share thoughts on what's been a crazy (but fun) year.

Highlights
  • New Trunk.ly users invited on board.
  • Exploring and learning Ruby and Rails.
  • Speaking at ALTA and networking with several academics who heavily research and develop the type of tools we "plug in".
Lessons Learned
  • If you're going to be body-shopping, you need to track your time. Yes, we've started some basic time-sheets so we can measure how much work we are putting into contracts.
  • Sometimes those things you "put off" because they'll take a long time actually don't.  Could of saved a heap of effort this year with some basic integration work that I did manually for far too long.
Goals this week
  • Deliver a working Rails prototype.

Reflection on startup life: Week 55

The way in which people use product is endlessly fascinating.  For example, with Trunk.ly (which collects links from multiple sources) one of the very first features that most people requested was to filter links by source.  So we added this in.  A week after launch, no one is using it.  So does that make it invalid? ie. Should we “not” deliver that function?  

I think the question is more complicated than that – sometimes there are things that people want in the first 5 minutes that’s very different from what they need once they experience the product.  One premise of Trunk.ly is that it collects and indexes links from multiple sources.  Allowing a user to filter by source is a first five minutes experience that helps them quickly confirm the promise of the product.

It’s something that Twitter and Facebook spend a lot of time on, yet most people don’t see it.  If you register a new Twitter account there’s virtually an entire application around helping you get started and get connected that’s something you only use in the first five minutes.  I’ve registered a lot of Twitter accounts this last 12 months and that experience is continually changing and enhancing (to the point that as an “experienced” Twitter account creator it’s annoying, but I am a minority I suspect).  Yet if you registered your account more than 6 months ago, you’ll never have experienced any of this substantial amount of screen design and effort on Twitter’s part.

We launched a new version of Trunk.ly which went smoothly enough.  There were lots of minor bugs in there, but we fixed them quickly enough.  We continue to get a lot of interest in Trunk.ly and increasing numbers of people registering for access which is exciting.  It’s still a little way from opening it up more broadly, but it’s getting there.

Unfortunately it looks like Trunk.ly will have to remain on the back burner for the next few weeks.

Last week was very focussed on making sure we got one of our projects for SportsGeek finished – fingers crossed the minor bug I fixed this morning sees that project now complete. I won’t spoil Sean’s fun by saying what the project is, but Alex and I are both pretty excited that the first client Sean has signed up and will be launching with is an NBA team.

This week we launch into a Ruby on Rails project.  For those playing along at home, you might have a WTF moment… as of course we are primarily a Python / Django shop. 

To cut a long story very short, we had a series of really interesting email conversations around a potential project, the end result of which was “let’s do this”.  We were all on a similar wavelength and were excited about working together, but right at the end realised that Python / Django wasn’t going to suit this customer as a Ruby on Rails shop.  We needed to find a creative way to make it work – so we’ve committed to a pilot in Ruby on Rails.  Over a couple of weeks we’ll develop some of the core components, mostly on our time as we are learning as we go with a new language.  At the end of that we’ll submit it for review and if it’s good enough, we’ll negotiate from there.  Once we suggested this, they agreed and then proposed some funding to ensure we are compensated at least a little for our time (these guys are awesome – really fair, above board and straight shooters – the kind of clients you want to work with).

Of course there’s lots we need to do that we DO already know – front end, HTML, JavaScript, Twitter API and how to work with it robustly etc.  I’ve programmed to some degree with C64 Basic, Fortran, Pascal, FoxPro, Visual Basic for DOS, VB4, C#, C, C++, SQL Server Scripting, Python / Django and now Ruby.  It’s safe to say I’ve forgotten more than I remember!  Ruby / Rails is just another step on the road.

I thought as part of this “challenge” I’ll make it entertaining and for the next couple of weeks I’m going to geek out here on the transition from Python / Django to Ruby / Rails by posting daily updates. I think I’ll call it “Rails Challenge” so feel free to ignore these if you’re not into languages.

Highlights
  • Ignite talk on Wednesday – great event and well run by Mark Mansour.
  • SportsGeek project done
  • New Trunk.ly launch
Lessons Learned
  • Billing is a pain – especially when your bank stuffs up transactions and you can’t even tell if its you or them!
  • Creative persistence is worthwhile.
Goals this week
  • Learn Ruby on Rails and cut some code!