/devel

Three months ago I received an invitation to try and review Toshl, a mobile expense tracker developed by ThirdFrameStudios. I also received code to get  Pro account free for first year to help me test it, which saved me a modest amount of 20 euros. It is also not a secret that I know people working at 3fs and admire their work.

As influences go, that’s it. I received neither threats to pets I don’t have or contributions to a bank account I do have. Also a complete absence of nudges means that this post took longer than planned and that all opinions are mine. Too make them less ignorant I decided at start to give Toshl a proper test and use it for couple of months before passing judgment.

Toshl, as mentioned, is a tool for keeping track of expenses. You are obviously sensible enough to know why this is wise, if you are still reading this, so I won’t bother explaining. It comes as a free application for Android devices and Maemo based N900. I heard rumors of an iPhone version, but Symbian or BlackBerry owners are out of luck (for now). Using web based companion and synchronization is free too, but you have to pay for Pro account if you want to add expenses through website or need a more flexible export of your data.

I tested Nokia N900 version of Toshl and liked it. I don’t want to go into details since they quickly become boring and there is no better test than your own (remember, it’s free). I was impressed how well it handles decimal separator for me, since I sin by using both comma and point.

Entering expenses is easy and quick, especially if you have entered similar recently, since you can reuse tags just by clicking on suggested. You also see already entered expenses sorted by time or tags. There is still room for improvement (like adapting tags suggestions based on first entered), but not much to fault.

I believe Toshl’s goal is to be as simple and fun tracker of everyday expenses as possible. You can do basic add and removal of expenses, export inserted data, categorize each entry with tags and see few different reports. That’s it. There is no integration with banks, currency conversions,  or even a notion of income. Reports are basic and I am not a fan of those included.

I usually used more than one tag on each expense and had difficulty wrapping my head around graphs where same expense could be shown multiple times. I failed at judging how much impact do some expenses have overall without at least some tweaking of graphs. I am certain that Tufte would call it chartjunk, but their implementation certainly is fun to play with.

And that’s where Toshl’s main strength is. A fun way of doing something that most people find incredibly tedious. You might overgrow it one day and switch, but it will help you develop a necessary habit of recording your expenses.

Being simple and fun doesn’t mean powerless. Tags free you to your own categorization and multiple export options give you an opportunity to massage that data further in tools of your choice. It might not be as trivial as clicking on a graph is, but doing it in Excel is not much harder.

I will not continue to use it because I am that sort of person who gets off on double-entry bookkeeping. I’ve been using GnuCash for years and there is no easy way to sync data with it (probably shouldn’t be either) and few reasons to input every expense twice. I do recommend anyone who isn’t tracking yet or is not satisfied with his current approach to give Toshl a try.

And if you are happy with free version, then buy a Pro account. It costs little, gives you features as polished as rest of service and it help secure your apps future.

Related articles by Zemanta

• Toshl expense tracking app is web connected and I love it for that! (intomobile.com)
• Personal finance software – Free download the ultimate Gnucash (techblissonline.com)

Joshua Porter’s workshop at recent UX London conference was great and a must see if you can, but there is something that’s been bugging me since. In discussion about difficulties of getting people to sign-up for service, Joshua mentioned how some companies see connecting with Facebook Connect as Facebook “owning” their users.

They are right, but it doesn’t matter much. Relying on Facebook for authentication certainly makes Facebook sort of a gatekeeper. This does not matter because it can and should be a transitional phase in an evolving relationship.

My view is based on assumption that company wants to build a long lasting relationship with a customer. This may not be true, but then there really is no point in having a sign-up at all. Avoid friction of one, make a trade and move on.

I think most user lifecycle strategies look like trying to get laid by the end of evening while hoping to start a long-term relationship. It might work, but how likely?

There are two things relationships need. Continuing benefit to parties involved and mutual trust. And trust is built through actions over time.

Traditional UX life cycle can be seen as:

Awareness -> Sign-up -> First-time use -> Engagement -> Referral

Each step has to offer more benefits to person taking it as it requires more trust. Moving sign-up after first-time use changes dynamic by making service prove itself before asking same of its user.

Using Facebook Connect (or OAuth, OpenID…) is just going further in mimicking natural relationship building. It’s asking of a smaller commitment at a fragile stage of relationship. You can ask for a bigger commitment with your own authentication later on, when you have already proven your worth and gain enough trust. You could even offer something available only to “full” members to make such commitment more enticing.

If you are building years long relationship like I have with Amazon, does it really matter if you get me to fully sign-up after third month instead of first?

Hence sign-up should be thought of as a gradual process taken over time instead of one-time obstacle.

All this is just speculation at this point, but I hope to test it on two projects this year. If I do, I’ll let you know how it went.

April is about to end and with it also the deadline to submit your EuroPython talk. I thought about submitting a proposal, but realized it would be nuts to do so with my current workload.

It would also be nuts not to go and if you are a European (or not) Python developer you owe it to yourself to come.

I go to a few conferences every year and each has its own personality. It is sometimes hard to point at what makes them (feel) different, but they just are. I like many, but only EuroPython, which I regretfully had to miss last year, feels like home.

That’s why I decided to volunteer this year. It’s a way to give a little bit back, like cleaning dishes when you visit mom.

So do submit your talk and come. It won’t be the same without you.

I admire the look and feel of Mike Matas’ new website. It is really well thought through. I was also intrigued by how he did it, especially after getting a pop-up on my first visit advising me to use a more modern browser than a recent version of Firefox.

There is no point in speculating why some of its features don’t work in more browsers. But I was surprised to see that blurred images are served that way and don’t get blurred in browser. I am playing with an idea of implementing a gallery inspired by Mike’s work, but I would like to reduce manual labor needed for maintaining it.

So I wrote a function that blurs an image on canvas. You can see it in action or copy its code, if you find it useful.

The algorithm used is described in 2001 paper by Wojciech Jarosz. Page contains two implementations, second trading algorithm purity for in my opinion nicer code. Increase number of passes or run it few times over an image, if you need a blurrier result.  Please ask, if you need help with its use.

I also measured its speed to see if it fits my needs. That brought a new surprise. Firefox 3.5.8  on my Linux powered VAIO with 1.2GHz processor blurs image twice as fast as same browser on a Mac with a 2.8Ghz processor. Numbers between runs may vary slightly, but never much. No idea why this is happening, since all functions do is some basic math over items in array that should be well optimized everywhere.

I am sure somebody can optimize it further, but I find it good enough for my use. Image isn’t very blurred after one pass, but one pass over a small image is also a good way to measure how fast a particular computer-browser combination is. On fast combinations I might go for multiple passes over images in view, but fall back to a single pass or no pass on slower systems.

I am not much of a YouTube user, but I have recently started to upload some of my work there. You might find them interesting if you are into interactions prototypes for products that may never be (especially if you are a Zemanta user).

I want to stress that while we use prototypes to learn what to implement and how, there is no guarantee that any particular feature shown will be actually included in our products. We do make an effort of listening to our users so please tell us what you think.

This is also a good time to mention that I don’t lead front-end team at Zemanta anymore. My new title is Chief Product Officer which is a fancy way of saying that it is my task to care about our products and our users more deeply than anybody else.

Related articles by Zemanta

• Zemanta Hackday Spring 2010 (zemanta.com)