Macadamian Blog
The Apple Magic
We're often asked - "What's Apple doing that makes them so successful?" and "How are they approaching product design and product management that's so different?", and naturally "Can you help us become the Apple of our product segment?"
The launch of the iPad reminds us why Apple makes such successful products.
Which localization framework to use on a WPF project?
Microsoft recommends using a tool called LocBaml to localize the strings in your WPF application. We spent a lot of time trying to get LocBaml to work, and ended up dropping it, particularly because
- Documentation for the tool from Microsoft is sparse. You have to rely on blog posts and articles like this
- The tool appears to be a beta from Microsoft, and there are a number of known bugs. I haven't seen any indication of when they'll be fixed.
- Using tool is a 10+ step process, and this process needs to be repeated frequently to update the localization. It involves command line operations, generating .csv files, etc. all of which is reported to be error-prone
A project developed in 2008 (under MS public license) called Extension: WPF Localization got a lot of favorable reviews on the web, so we decided to try that instead. It is simply 4 .cs files which provides a localization framework and dynamic language switching at run-time, among other benefits. The documentation and examples are also quite good. Until we hear updates on LocBaml, this is a framework we'll definitely re-use in future projects.
Are you Selling Winter Tires or Customer Experience?
Winter has officially started, and here in Canada that means everyone is busy putting winter tires on their cars. For some of us, that's as simple as taking the summer tires off and putting the winter tires on, but for others (myself included) this year means buying new winter tires and having them balanced and installed at a garage.
In theory, this is a simple transaction. I buy winter tires from a garage, and pay to have them installed on my car. What I realized this year, however, is that when dealing with the garage, I'm expecting a lot more than a great set of tires. Think of all the interactions involved in this process:
First, I call the garage to make sure they carry tires for my car. Next I drive to the garage, talk with an employee, pick out the tires I want, and pay for them. Then I leave my car at the garage, and return when the tires are installed to pick up my winter-ready car.
The garage has many chances here to provide a positive customer experience. Just look at all the things it can do for me during this transaction:
- Record my information when I call ahead so that I don't have to repeat it to whoever I speak with when I drive in with my car.
- Warn me if it will be a long wait to have the tires installed.
- Not expect me to have memorized my car's tire size.
- Explain the different brands of tires it sells and recommend some based on my car, preference or driving history.
- Keep a record of the work they do on my car in case I come back to them again next year.
- Make sure I have a ride home if it will be a long wait to get the tires installed.
- Inform me when my car is ready to be picked up, or at least provide an easy way for me to check on it.
- Make sure I have a ride back to pick up my car, or better yet drive my car to me.
- Sell me a great set of tires.
There are plenty of garages that sell great tires, but how many of them also sell a great customer experience? How many actively focus on improving that experience?
This got me thinking about how that lesson could apply to software development. Most of a user's opinion of a software application will be based on how they interact with it, not the features it provides. To be really successful and to make software users love, the focus must be on improving those interactions.
Am I doing everything I can to make interactions easier for my software's users? Or am I just selling great tires?