Blog

This is part four of a series of posts about how we built Dojo Learning (part one, two and three).

Don't bite off more than you can chew

We've been developing internally at Dojo a bit like a traditional software project and a bit like a startup. It's much easier to push bug fixes to customers, since you're all on the same system. So bug fixes get fixed much faster, and more easily too since we only have to test against one server platform (although we still have to test in each browser, no escaping that one).

But the quick push model only scales so well for larger change sets, especially ones requiring changes in several areas or changes that need to be made in concert with each other. For those, we've adopted a more traditional "here's what we want to do for the new version, let's do it" top-down approach.

This removes a bit of agility at first, but gives us several benefits. First, we get to announce each major update as a new version. New versions are one of the few things bootstrapped startups can really use to attract attention from the press, so we benefit from that.

Second, it gives us a specific goal that we're working towards, which helps keep us motivated. And third, it gives us a chance to put the whole product into question and ask all those fundamental questions again.

Lastly though, it gives us a finite goal and limits so we don't get into a scope-creep rut or start adding things that are outside of our agreed upon features for that release cycle.

Break things up for easier digestion

You have to break things up into manageable sizes, or you'll end up with chaos, or worse, wasting time on the wrong problems. We try to break things up into the smallest components we can and then plan those out with wireframes, lists of actions, user interactions, database schemas, etc so that we have as clear of an idea of a feature as possible and how to implement it.

It also helps ensure everyone is talking about the same thing, and that you don't mean something different when you're referring to a feature than the rest of the team means.

Once we've broken each feature down into individual wireframes and tasks, those become the to-do list and away we go.

Set a date

We actually work towards specific release dates internally, and while they're not set in stone, they do help us plan how we spend our time and what we can fit into a development cycle. They also force us to think through our features so we don't over-promise and miss the date.

For me, even though I've done the planning and preparations, deadlines still create a bit of uneasiness early on, but once I'm into a groove I find they create a bit of excitement.

The key to realize is that unless you've already begun marketing or advertising efforts around your deadline, it can be adjusted. It's just an artificial date you've set, and pushing it back isn't the end of the world. And it's a good way to get everyone in sync, and to help give the marketing side of things something to plan around too.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

This is part three of a series of posts about how we built Dojo Learning (see part one and two).

Get to the root of the problem and solve that

Customers are notorious for explaining a feature they want, as opposed to the problem they're trying to solve. It's our job to read into what they're saying, figure out the core problem and solve that. Even our own ideas for features are really just a specific way to solve an underlying problem.

But how do you know you're at the root problem yet? Keep asking questions. Play the five whys game. An excellent indicator you've found the root cause is when the solution to it is so simple you want to smack your forehead for not recognizing it sooner.

I think it was Einstein who had said about his theory of general relativity that he could feel it was right because it was so simple. Occam's razor is a principle that roughly says "all other things being equal, the simplest solution is the best."

This is true of software especially, and what you'll find is that when you've solved the root problem, it has a domino effect on other feature ideas and solves some of those too.

When you solve the root problem, you'll usually find the solution is so simple and obvious that you wonder why you didn't think of it first. The reason of course is that simplicity is hard, it takes hard work and persistence to drill down that far.

My last startup failed partly because when it began to run into trouble, I didn't take a step back and find the root solution for the problems we had. They seem so simple in hindsight, but at the time I couldn't see them. Instead of making one simple change and saving the business, I watched it crumble right in front of me.

There were several other factors (translation: mistakes I made) which I'll save for another post, but one of the key things was that I didn't dig deep enough to see and solve the root problem. So I know first-hand how important this step is. In many cases, it just means feature-bloat. In mine, it cost me a startup.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

This is part two of a series of posts about how we built Dojo Learning (click here to read part one).

Understand your users

Before you can prioritize which features to build and what ideas to focus on, you need to really know your audience. When you're just starting out, that's the first thing you need to figure out. It took us many months, several iterations of our software, and lots of testing and feedback to fully understand who our users are, who they are not, and what their needs are.

Now we're pretty confident we're building a killer set of features that all provide significant value to our users, because now we get it, or at least we have a much better understanding. And that makes prioritization a lot easier.

How we got to understand our users

We started Dojo in partnership with a company, the Centre for Education and Work, who provide services related to training in the workplace and adult learning. This gave us a good leg up, but we still had to decide: are we building an employee training tool, a higher learning tool, something for online trainers and consultants, or something else?

Initially, we went back and forth quite a bit and had to explore each of these areas. Fortunately, there was one group of users who had similar needs in each of these categories: the learners. A learner needs certain tools no matter what company is using our software, and so right off the bat we could focus on the learner experience and add value there while buying time to figure out who our target group was.

We were also lucky in that we were able to harness our partnership to do testing with learners from all across Canada. That provided amazing feedback, and was our equivalent to the "release early, release often" philosophy at that stage.

But you don't need a partnership with an existing company to get that, you can ask your friends, family, acquaintances and contacts to test it out, you can solicit users online to be beta testers, and you can even approach companies directly and just ask them: Do you want to pilot some new software?

Prioritize by value

Once you get that down, any time you think of adding a feature you can hold it up to this measure and see how it stacks up. If it doesn't add real value for your users, then it's clearly not a keeper. If it only broadens your audience and makes it less clear who your software is intended for, that may actually hurt your marketing too. But even if it doesn't, it still wastes time, and time is your best weapon early on.

I look at writing software like writing a story or a movie: If what you're adding doesn't move the plot forward and isn't central to the story, then you should leave it out. Have the confidence to do so, it's tough sometimes but worth it.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

We've been working on Dojo Learning for over a year now and we're progressing nicely towards a really major update we're calling "Dojo 2.0". It's still a couple months away, but we think we've got something that will definitely knock some socks off. I can't say any more yet, but we'll have more details on that soon enough :)

I've also been doing software development for about 10 years now professionally, so I've seen my share of what works and what doesn't. And I learned most of what doesn't the hard way.

But instead of officially employing a particular software development methodology as a standard here at Dojo, we simply try to practice a few informal principles in all of our thinking about Dojo.

Over the next few posts, I'm going to break those down and talk about each one. The first is about managing ideas.

Keep a list of ideas

This may seem like an obvious one to many, but a surprising number of people don't record their ideas and so those ideas simply come and go.

We have a huge number of ideas for new features and improvements to Dojo Learning. We record them all to a big list and revisit it periodically. Most of them will likely never see the light of day, and many end up being solved indirectly anyway (I'll get to that later).

The important thing here is just to keep a list, to keep adding to it, and make it accessible to everyone so they can add to it too. And any time a user suggests something, put it in the list.

We also keep a list of ideas that don't fit the project, but may be things we branch into later, or that pieces of what we've made before can be used towards solving.

You never know where an idea will lead, so jot them down. This is the easiest thing you can do, and gives you an endless supply of material for future brainstorming and planning sessions.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

Here are some thoughts on our API and APIs for Software-as-a-Service companies in general that I wrote in an email recently and thought they might be worth making public.

API in plain English

API is a programming term, which stands for Application Programming Interface. An API is a way of accessing your data directly, instead of going through our website in your browser. A developer or administrator could use it for example to do regular backups themselves, to export data into another application, or to build an entire application outside of our site itself.

We have a few ideas of our own that we'd like to build on top of our API, but essentially it opens things up for customers and enables many possibilities that we may not have thought of ourselves.

Content ownership in software

We see this as very important since content ownership needs to rest with the customer, not with us (the service provider). This has always been a big issue in software, not just with SaaS services, but SaaS does change things up.

Traditionally, proprietary software used proprietary file formats, meaning that while you had your files, you were still locked into their file format, and so you had no choice but to use that software, or change with some difficulty. The Open Source software movement helped change that by raising awareness and by ensuring the code and also the data formats were open and interoperable.

Where SaaS changes things

The problem with the traditional software model is that by installing software yourself, you bear the burden of maintaining that software and the machines it runs on. For complex software, this often requires a full-time system administrator to be hired.

Software-as-a-Service solves that by letting us be your software host so we take care of the technical details for you, which can save a company lots of money, but it can potentially put your data into a closed scenario again.

So customers should be careful to make sure any vendor provides a means of accessing the data in a way they can take with them, that way the control and ownership rests where it belongs, with the customer and not the vendor.

Future interoperability

Over time, I believe standards will continue to develop and be adopted by SaaS companies too, and I think it's in everyone's best interest for that to happen.

Just like today OpenOffice.org can import and export Word files and new file standards are emerging for office documents, so too will ways of standardizing data formats for more specific applications like e-learning. And in the meantime, if we all do our part to make sure customers maintain clear ownership of their data, then we ought to be well poised for a future where customer relationships with SaaS services are built on quality, value and trust.

We should be out enjoying the nice weather today (it may be one of our last up here in Winnipeg!) but instead we spent today doing a bunch of bug fixing. These include several improvements for instructors, people management, messaging pending users, a fix for Firefox 2 users in the lounge, and some minor UI tweaks too.

Now to enjoy the remaining sunshine! :)

This post is our contribution to Blog Action Day, which brings together thousands of bloggers to write about one topic for a single day. This year's topic is poverty.

A friend of mine, Ilan Shwartz, took a trip to South Africa a few years ago to volunteer at a place called the Hillcrest AIDS Centre. Hillcrest provides medical services, education/awareness, emergency food parcels, sustainable agricultural development, and income generation programs for people in an area where the unemployment rate and the rate of HIV/AIDS infections are both over 40% of the population. The number of people there infected by HIV grows by over 500,000 every year. That number is almost the population of Winnipeg (the hometown of Dojo Learning).

When Ilan came back to Winnipeg, he brought with him a few dozen small beaded pins called "little travellers" which were sold at Hillcrest as souvenirs, as part of their income generation program. When people here started expressing a desire to have one of the little travellers for themselves, Ilan started selling the pins here like they were back at Hillcrest.

Things started to pick up quickly, and so Ilan organized a group of volunteers under the name "Little Travellers" (originally the "Simunye Initiative") to promote the pins at local events and find local stores to carry them. Fast forwarding to present, the Little Travellers are now in cities across Canada, and have started spreading into the US and as far as South Korea. To date, the Little Travellers HIV/AIDS Initiative has sold over 30,000 pins, raised over $150,000, and have been endorsed by Stephen Lewis, the former U.N. Special Envoy for HIV/AIDS in Africa.

Each doll is hand-made by women affected by HIV/AIDS, and 100% of the proceeds go to help fight HIV/AIDS and to provide an income source to the families of those who are affected. In addition to all of the  services provided by Hillcrest, the sale of Little Travellers provides an income to more than 100 families affected by HIV/AIDS in one of the most impoverished areas of South Africa.

Please take a moment to check out the Little Travellers website, read the stories of some of the crafters who make the little travellers, and buy a few for your friends and family. At only $5 each, a little goes a long way.

"By making these dolls, families have been fed, lights have been turned on, little children have gone to school, water has poured out taps... but most of all, hope has been restored."
– Paula Thompson, Woza Moya income-generation project, Hillcrest AIDS Centre

We've been hard at work this summer and have just launched a major update to Dojo Learning.  Take a look!

New features:

Developer API
This allows other developers to make use of our online learning application in unique and custom ways.  The API has many functions that can be used in almost unlimited ways to customize your Dojo Learning experience.

Facebook Application
We have added a Facebook application that allows you to share which lessons you are taking and which ones you are instructing and connect with other Dojo Learning users on Facebook.  Great if you are selling your training or using Facebook in your online classroom.

Profile Pages
Upload your photo and connect with other learners using your profile page.  Learners are automatically connected to each other when they subscribe or when they are invited into a lesson.

Widget Tool
We have developed a Widget tool that let you embed your lessons into your own blog or website. You can use the Widget to promote your lessons while keeping your already branded webpage.

Promote Your Lesson
Use your address book from Gmail, Outlook, Plaxo, AOL, Yahoo! or use a CSV file to promote your lesson to all your contacts or submit your lesson to over 20 social media sites.

Updates:

Journal
The Journal tool has been improved.  Navigation is easier, responses are easier to read and profile pictures are connected to each response.

Improved Landing Page
When logging on to Dojo Learning, you are presented with a new, more informative landing page that quickly directs you to the lessons you're taking or instructing, and provides you with a quick link to add a new lesson to your account.

Chat Tool
The chat tool was taking too much screen real estate, so we tucked it away in a side tab.  When a fellow learner or instructor starts a chat, an indicator will let you know that a chat has started.  You can disable the indicator tool if you want to work in private.

We are very exited about these changes and are already working on Dojo Learning version 2.0.  We will strive to make Dojo Learning the most engaging learning application on the net.  Enjoy the upgrade.

We've been working hard this summer to improve Dojo Learning.  We are making a major upgrade October 1st, 2008.  We've developed a Facebook Application, an API, added Social Network features, and have made user interface upgrades.  Stay tuned for more details as we approach our launch day.

I was playing with the recently announced Ubiquity Firefox extension from Mozilla Labs today and came up with a little Ubiquity command for Dojo users.

Ubiquity extends Firefox to enable end users to create their own ad hoc mashups of the various web services (Google, Wikipedia, Amazon, you name it) in cool new ways, without needing to know about the underlying technical details.

An example from their demo connects a restaurant with a map to get there and a customer review, then emails it all to a friend to make dinner plans. Needless to say, this is an awesome new development in web browsers that really puts more power into the hands of the everyday web user.

Back to Dojo, if you install the Ubiquity extension then browse to this page here, it will prompt you to install the Dojo Learning command, which provides search results of our lessons for use in your Ubiquity mashups. And here's a screenshot of what it looks like in action:



Enjoy!