Posts Tagged ‘usability’

Tweak Your UI- The Ubuntu Calculator

Recently I saw a couple articles on the improved calculator that will be shipping in Ubuntu 10.10 and I thought “Really? An improved calculator?” It turns out that the major, obvious improvement is a UI change. It seems odd. I mean, calculators are calculators right?

Take a look.

The second I saw it I loved it- the colors make the eye easily track where the button groups are. Reminds me of other calculator apps I’ve seen mentions of lately:

A little UI polish goes a long way to making an app fabulous to use.

A few years ago, an interesting blog article surfaced about the development of Coda, a web development app for Mac OS X. The toolbar was strikingly different- it really just meshed well with the overall UI. Coda is sofware that is just fun to use. Extremely slick and powerful. Anyway, the toolbar wasn’t possible to do using standard Mac OS X apis, due to a 3 pixel border they couldn’t get around and still use standard UI controls.

I’m just as much (maybe more) of a standardista as the next guy. But your app needs to be perfect and to do that, it may have to break rules. After a long development cycle, the team behind Coda threw out the system toolbar and wrote their own, even though it took a lot longer.

And all because we didn’t want to settle.

So take a look at your app. Are you settling?

In the end, by the way, the UI looked so good that Apple incorporated that look into the system toolbar in the next release of Mac OS X. It’ not rule breaking- it’s pioneering.

Thanks for visiting! Any suggestions for content that would be helpful to you? Contact me.



Ready for One User

A while ago, I saw an interesting development idea I thought I’d pass on. Work on KOffice is proceeding by targeting a specific user.

Target the application for one specific user and make it perfect for him/her. Then hope that it’s good enough for other users as well.

Honestly, I don’t know how well it will work. There’s the potential to cause problems by being so targeted that it’s unusable by anyone else. :) But I have to say that this makes a lot of sense. Most open source projects, if they were just stable enough for any user to use, they’d come a long way. They may even come up with a couple features no one has thought of yet, but I doubt it. I suspect that they’ll mostly be checking off features they’re used to using elsewhere. As I’ve mentioned before, you don’t get many switchers by just matching features. But, if they can check off some important features and add a game-changing feature that could work.



Does Your Software Know Who’s Using It?

Seth Godin says:

The people who make desktop software are making themselves obsolete. When you start developing on the web, your default is to be smart, to interact and to be open (with other software and with your users). Desktop software (like Word) is insanely unaware of what I do, why I do it and who I do it with. Right now, the desktop folks have the momentum of the incumbent. Not for long. Time to hurry.

As a web developer, I know that there are numerous technologies out there that can make the web feel more and more like a desktop app- some like Adobe’s AIR and Appcelerant’s Titanium provide an actual desktop app that use web markup and coding to create a desktop application. That’s fine- but I don’t subscribe to the new ‘Web is the OS’ movement. I work on my desktop and there is a real difference between the two. At the simplest, my desktop is usable no matter what happens online. If a website I use goes out of business, gets shut down, decides they don’t like me anymore, etc., I’m sunk. I can’t use that anymore. And anything ‘saved’ on their sites is just gone.

But I digress. Seth is right in that it’s odd that apps I use on my own computer know me less than a lot of websites I use. One reason for that may be that on a website, you try to customize the experience for user because you want something- more users or more money. So the data and personalization goal is to drive revenue. You are hoping that if you create a great experience the user will continue using the app.

A desktop app is either:

  • Free : you’ll never get any revenue for it
  • Shareware : the user has a short time to decide to pay or not. Most of the time they will not have enough time to put enough data in for it to show whether it will personalize things or not.
  • Commercial : the user has already given you money. There may be hope that they will upgrade when it’s time, but those upgrades are usually driven by a need for a new feature- not because the app is so fun to use or personal for the user.

But a web app usually has a free model to attract eyeballs or a monthly payment system. Everything depends on people coming back while a desktop app developer may not care whether a paying customer ever uses their app at all.

Why should your app be different?

If you’re making a free, open source app, that changes more than just the initial ‘price’- your upgrade model is different too. As long as your app is useful, there’s nothing to stop users from getting the latest version. If they like what they’ve seen so far, why wouldn’t they upgrade? If the app you’ve created gives them the personal experience that just makes their whole desktop come alive for them, they’re going to talk about it with those they know. They’re going to start talking about you.

When they do that, you’ll have created a reason not just to use your app, you’ll be making the whole Linux community a better place because your app is there. Face it: Apps drive adoption. A stronger Linux community will depend not on the kernel but on the apps that are available to users. Make yours personal.

Two Goals For Your App

  1. Keep track of what users do and when they do it. One of the things Seth mentions is his contact list and how it would be nice to sort that based on when they were used or maybe the frequency of how often they are contacted. To do either of those your app needs to save data on how often and when contact is made. Store what actions are taken, who they involve, how many times they happen, when the last one was, when the first one was.
  2. Alter your app’s behavior to take advantage of the data. Offer new sortable columns if that applies. Highlight certain things differently based on age. If you see certain things happening on a schedule, have your app offer to do it automatically or create a toolbar button to easily perform that action. Making an app isn’t about collecting data- it’s about applying it. Every screen and button in your app should be aware of who is using the app.


Build Things to Solve a User’s Problem

The company (or project) that figures out how to do this will win.

That’s what Matt Asay says on his CNet blog. What to know what he said that about? He said that open source projects need to:

determine what average users want and then to translate this into development plans

Asay says that Apple wins with users because it takes what users want and makes its engineers deliver it, while typical open source projects, made by engineers, are not often made to be used easily.

It’s one thing to create a cool app that can do wonderful things. But the user doesn’t want a cool app- he wants a solution to his problem. Thinking man Clayton Christensen expresses it this way: People that shop for drills don’t want a drill. They want a hole.

Solve their problem and solve it in a slick way. Then you’ll have a fan.



Improving Apps: Some hints, tips, and thoughts on marketing an app for Linux.

More

Pure Linux: How I use Linux 100% of the time.

More