Code Frenzy

About a week ago, Chris and I “launched” TravelStash.  By “launched” I mean we have now opened it up for general consumption.  Anyone can join TravelStash and use it just like Rheanna and Sanjay did on their recent South Africa trip, Margaret and Alan have on their trip around the South Island of New Zealand and of course, how Chris and I have consistently used it to keep our friends and family updated on all our travels over the past couple of years.

TravelStash started off a few years ago as a simple travel blog with a map on it.  At that time there were no blogging engines available that allowed one to map their travels, something I was very interested in since I was working for a mapping company at the time.  So, I decided to build one from scratch.  I won’t deny it, it’s been hard work, but since then, we’ve built a lot of cool features (read: we’ve spent and continue to spend a lot of time on it!) and TravelStash has grown into a fully functional travel blog (still with a map!).  What makes TravelStash a little different to other travel blogging sites out there is that it allows members to sign up as part of a ‘group’ and create separate ‘trips’ for each of their holidays that they can then ‘blog’ under.  Members can upload as many photos as they like to each of their blog posts using a really advanced photo upload mechanism designed to facilitate photo management as much as possible.  Aside from their travel stories, members can use TravelStash as a bookmarking tool to save links or travel ideas, something that we have chosen to call a ‘wishlist’.  You can even save your wishlist to a PDF file so you can quickly and easily print your bookmarked ideas to paper and take them with you on your next adventure.  Then there are ‘travel tips’ – quick little snippets of travel advice that members can write up…

Basically, there’s a lot of neat stuff already built into TravelStash and we are constantly thinking of new enhancements for it.  The latest addition has been the ability to notify your facebook account (if you have one) when you publish an article or a wishlist item in TravelStash.  That way, if for some strange reason your friends and family haven’t subscribed to your TravelStash RSS feed and aren’t obsessively hitting your TravelStash group or trip pages to see what you’re up to, you can still let them know by posting a small note to your facebook wall and your friend’s news feeds when you publish a new travel post or wishlist item.  We’ll soon be extending this to travel tips too, just to be consistent.

Another feature we’ll be releasing soon is the ability to save an entire trip (photos, map, blog posts and comments) to MS Word or PDF format.  This will enable you to save your holiday stories and memories in a format which you can then print out and make a book out of.  If you save it to MS Word you then have the ability to edit and alter the way it all looks and could even take it down to a print shop to have professionally printed and bound into a beautiful coffee table book.

In any case, at this stage TravelStash is 100% free to use and has no ads.  We think it’s pretty cool (ok, that’s a bit of an understatement… we think it’s freakin’ AWESOME!) and encourage everyone to create an account and use it on their next holiday.

The other day while on a bus in Brisbane, I witnessed a classic error message FAIL:

On a more serious note, error handling and the display of error messages in software development is an often discussed usability topic.  Errors occur for all sorts of reasons – user-generated, hardware failures, invalid data, and of course software bugs.  But how much do you let the end-user know that the software has failed?  Well, I believe it depends on the type of error, the impact of the error and who your audience is.

Clearly in this case letting the end-user (i.e. the general population driving by) know that the modem had failed was not useful at all.  What would an end-user be able to do with that knowledge?  Nothing.  They can’t fix it nor would they care to.  Showing them that message is pointless and makes the manufacturers of the mobile street display look stupid.  SOMEONE ought to know about the failure but in this case that someone is certainly not the end-user.

Another concern with display error messages such as the one I witnessed the other day is that it gives those malicious souls out there who thrive on breaking other people’s software a better idea of what will make the software break.

Personally, I’m a fan of generating more than one type of error message upon software failure and audience.  If the end-user is likely to be the general population (i.e. website users), then you should look at what caused the software to fail.  If you’re allowing users to generate errors by entering invalid data into a form, then you should probably let the user know that they entered some invalid data and that they should try entering something valid next time.  However, if you’ve coded restrictions into the software so that they should never be able to enter invalid data but somehow they do anyway, then you may be a victim of a hacker’s attack.  In this case, you do not want to admit that they have almost just broken your site because if you do you’ll only be encouraging them to try again and you may have just given them the extra information they needed to totally own your site.  Instead, the message you display to the end-user should be a friendly and generic/vague one, something along the lines of ‘Oops!  Your request returned no results.  Please try again later or contact support.’.  That way, the hacker will be none the wiser or at least they won’t think that their last input came so close to pulling your site down.  The same error should be logged somewhere on the system (event log, log file, database error log…) with a much more specific error message.  If it’s a critical error then perhaps it should even be emailed or sms’ed to an administrator automatically.

I guess the moral of the story is that it really doesn’t matter that you’ve handled all the potential errors in your code.  What really matters is how you’ve handled them, in particular, who you’ve alerted and what information you’ve given them.  Telling the world that the last input caused an integer overflow is probably not the best way to keep hackers out and users in!  If you’re a developer, think carefully about every line of code you write and if that line can raise an exception then make sure you know what to do when it happens.