WeSay Development Progress

Our approach to software development requires that we “ship early, ship often”.  We listen carefully to you, and try to quickly respond to your requests (though at this point, we’re way behind on many requests for new capabilities).

The down-side of this approach was that the newest version is not always the safest.  We don’t have any “testers”, so if a release had great, sweeping new features, it could come with related bugs.

This has now changed.  We now make two versions available to you.  One is the safest (”stable release”).  The other has the latest stuff (”development release”).  If you are checking out WeSay’s capabilities or willing to help guide us, you want the dev release.  If you are deploying WeSay to less computer-savvy or less network-connected users, you want the stable release.

When we hear of a serious bug, we will normally fix it on both releases.  New features and non-serious bugs only get added to the development release. Make sense?

To make it easier to track which is which, we use the old Linux-kernel numbering approach.  The stable track uses even numbers, the development track uses odd ones.

Our current “stable” releases are 0.4, and the “dev” releases are 0.5. And remember, there are new versions, especially of dev releases, several times a week.  So if it’s not too inconvenient, it helps if you can check with a recent release before reporting problems. Thanks!

It’s been a wild year for our team, and if all you do is follow this blog, you’d think we disappeared.  Eric has moved to Microsoft (lucky them!), I’ve moved from Thailand to the USA and then Papua New Guinea, and two new guys have joined our team in Thailand.  Amidst all that, I’ve fallen behind in blogging about our progress.  In this post and others which should follow shortly, I’ll try to catch up.

Starting with version 0.4, we’ve changed the “dashboard” you see when WeSay opens up.  With this change, we get more on the screen, lessening the need to scroll down.  Also, the new design organizes tasks into groups so that users can have a sense of the workflow.   Some of this will become more clear as we add tasks to the various sections.

You can see from this screenshot that we have some work to do on this still… the Word List task should display a “progress indicator” like we see in the second row.  “Review” and “refine” are two more sections, which I hope to see populated in the future.

The Eee is, so far, the best selling of the new wave of “4P” computers; laptops which are characterized by low Price, adequate Performance, portability, and low electrical Power requirements.  Now, this is no OLPC; it costs around $500 and isn’t as rugged. It does not aim at the same ultra-low power usage. But it does have two things over the OLPC today: you can buy them on Amazon and you can get them with Windows XP.  (Yes, sadly we’re still waiting on some open source pieces to mature on the Linux side before we can get WeSay running on the OLPC and other Linux boxes).

So, how would WeSay run on this relatively slow (900 Mhz), relatively low-wattage machine?  Getting Windows installed and running, the Eee felt very sluggish.  Because of delays, I found it easy to make errors when using a web browser.  Very slowly, I grabbed .net 3.5 sp1, then WeSay build 1451.  Very slowly, I ran the installer.  By this time, I wasn’t expecting to have a happy WeSay experience.

To my surprise, WeSay runs GREAT on this box! Changing records, finding words, and bringing up new tasks were all pretty snappy.

Note: I only did a quick walk-through using the sample data, so please don’t go out and purchase a hundred Eee’s to run WeSay based on this blog post.