Improving Apps

Lately there’s been a lot of commentary about Canonical’s new package that they’ll be using to count computers using Ubuntu for an OEM partner. As that last comment clearly said, people need to calm down about this. Even if they were tracking users in disagreeable ways, it’s open source and out in the open. If they start doing something shady, people can see that in the code and you can just uninstall it. From what I understand, it’s not even going to be part of the default- it’s specifically for an OEM’s customers which implies ‘normal’ Ubuntu users aren’t going to have this installed.

What’s the Big Deal?

Why is it such a surprise that a software maker would want to see how many users they have? In the commercial world where a software license is involved, user registration often is required and the software maker can be privy to all kinds of customer demographics. When my parents fill out these registration forms, it doesn’t even occur to them to not enter the information or to lie. They just type it in. And if that data is anonymous why should we begrudge our Linux distribution of choice a few demographics that will help them hone their product.

There are several other ways open source companies try to find out what they can- without threatening users. There’s Smolt from Red Hat which openSUSE also participates in that’s intended to evaluate hardware support priorities based on the userbase for a certain device. Debian has Popcon and openSUSE has Popcorn, their own spin on it. According to the description it “is an attempt to map the usage of … packages.” What a great idea! Know what users are using! It’s shocking!

Why Would You Want Your App to Phone Home?

Outside the Linux ecosystem, it would be typical to phone home to check for updates. Since the norm is for Linux to let you know and help you update accordingly, I think we’re used to apps not phoning home. But there are other reasons an app phoning home is a good idea:

• Update content for users like news or to highlight website content
• Get statistics on usage of your releases

Here’s a great example. Thunderbird from Mozilla uses the phone home tactic to great effect. At least since Thunderbird 2, the start screen when Thunderbird opens is by default a web page on Mozilla’s servers.

And in fact, when Thunderbird calls that page on the server it sends several bits of data:

• application
• version
• locale
• operating system
• application build number

They don’t know it’s you- don’t worry. But they can get an idea of their userbase in broad terms. Not just that, they can show users content targeted to the version the user has installed. If the user is using a version that’s about to be abandoned, they can be warned. In the Shredder example (Thunderbird’s developer version codename), early adopters and testers are given information that will help them get feedback to the Thunderbird development team. In the 3.1 start page, Mozilla adds a donation button for a good cause. Potentially, they could highlight a feature every day, training the user on how to use the app from within the app itself! The start page can be overridden, but most users won’t bother, leaving this valuable two-way communication channel open for you to better understand and help your users to use your app even better.

Maybe phoning home isn’t for you, but maybe it’s going to be key to making your app great. Think about it.

By the way, the Thunderbird pages are here, here, here, and here.

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

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.

There’s this mantra I hear a lot in open source: Release early. Release often.

This saying is very fortunate because only a certain kind of personality is good at proudly releasing source code for the world to see. We tell ourselves that we’re good programmers and that we solved some interesting problems. Maybe even in an elegant way. But then, it’s time to release and we feel a little edgy about the world seeing the code. Some of it was elegant, but some of it was ugly. And there are parts we weren’t even sure what we were doing but it seems to be holding together.

And we don’t ship.

I’ve got an open source CMS based on the Zend Framework that I’ve been working on for years but it’s never going to be so ready that I’ll be able to ship without any nervousness. What if I release and am flamed by the world as an incompetent programmer? That would just be humiliating. I might have to switch careers.

So it gave me a good boost to read some comments from Seth Godin:

Shipping is fraught with risk and danger.

Every time you raise your hand, send an email, launch a product or make a suggestion, you’re exposing yourself to criticism. Not just criticism, but the negative consequences that come with wasting money, annoying someone in power or making a fool of yourself.

It’s no wonder we’re afraid to ship.

I didn’t feel it was fair to quote the whole article but you should read it. Stop being afraid. You’re right. It won’t ever be as good as it needs to be for us to not be nervous. Just give it a shot.

That “release early, release often” saying gives us an easy out. We can just say “we live by the ‘release early, release often’ philosophy” and we’ll be ok.

I saw a very telling article this morning on Ajaxian about a new Mac app called Kaleidoscope:

The Website for this tool is so well done, that I feel compelled to click buy even before downloading the free 30 day demo :)

That is what you’re going for- albeit perhaps without the buy part. Your users should be enchanted. Eager not to just try it, but to turn their life upside down just to be able to use it!

The site is really just one page with some anchors down to content farther down. Honestly the design of the page with the big horizontal sections isn’t pulled off that well, but overall it’s very sleek.

The app interface looks simple but does some pretty amazing things. I work with images all the time, have never needed something like what it offers for image comparison, but it’s such a cool feature that I want it!

But think about this- this app has one page on their site and conveys a solid perception of trust and dependability by the finished look of their site.

In the Chrome browser, I didn’t realize for a while that the image of their rainbow-y icon actually had the color gradually shifting. Wow. They must have so much time to be able to do something that’s such a waste of time, right? No- they’re serious about this being a great app and have spared no energy to convince others of that fact.

While currently my Linux distribution of choice, openSUSE is not the most popular distribution by any means. Honestly, I think it’s a little unfortunate that openSUSE is in the name, but the openSUSE Build Service (OBS) may be the most important thing to come out of the openSUSE team.

Build service?! My users can build from source, you say. Don’t be stupid. Linux momentum is growing because users don’t have to do that anymore. If you’re not providing packages for the major distributions, you are doing two things:

1. You label yourself as a minor app without the skill or resources to provide packages.
2. You label all users of distros you don’t support as having made a bad choice and not being worth your time.

Why? Why in a world with Launchpad from Canonical and so many other great products for packaging is OBS a big deal? Because despite being made by one distro, it can package for all the main distros including Debian, Fedora, Mandriva, openSUSE, Red Hat, SUSE Linux Enterprise and Ubuntu. Notice that they’re not just the ‘open’ distros but a few commercial derivatives too. They have made a tool to make it easier for you to get your app in the hands of Linux users all over.

Users who may be using a distro you don’t care for.

The distribution puzzle of Linux creates certain problems other operating systems just don’t have. Odds are that there are a big group of users out there that right now, simply can’t use your software. The OBS levels that playing field.

Benefits

Think about it for a second.

• No more waiting for your users’ distribution to update the official distro packages before they can use your cool new feature.
• No more looking for a packaging expert for that one distro or waiting for that expert to have time to help.
• No more saying to users that you only support distro X. That’s almost like saying that the distro they have chosen is for losers. That may even be true. But give them a break.
• No more download page with nothing but a source tarball on it.

What It Is Not

OBS is not a project management tool. It is a build service (that’s why it says that in the name). OBS won’t get your project on track, but should be used in conjunction with project management tools.

This just emphasizes how great OBS is. Rather than making something that corrals developers to “their” playground, the OBS team have made a tool, not a world for you to live in. Come on in, take advantage of this great service, and then distribute the results to your users!

Yes- I knew it would be here eventually! The FOSS community answer to the MacUpdate, MacZot, and MacHeist bundles: The Humble Indie Bundle

Their spin on the bundle idea is that you can choose how much to pay and even then can choose how those funds are apportioned.

All of that and their site looks great too. Go get it!

You may not love Sid Meier’s Civilization games but I do- have for years. So when I saw this I knew I had to mention it. Sid talks about the psychology of game design and I’ll summarize his points from this article.

1. Recognize that the player is an egomaniac- the game has to be winnable by the player
2. Too much randomness in the game will make the player paranoid- the player has to know they are in control
3. Protect players from themselves- too many options kill the enjoyability
4. Listen to players- not just to what they say but to what they’re really getting at

Which I will regurgitate as advice for app developers:

1. Recognize that the user is an egomaniac- he expects that he is exactly the one you made the app for and it should easily work for him and his unique computer setup
2. Too many bugs or unexplained quirks in the app will make the user paranoid- even if you made it work a certain way for a good reason, if the user doesn’t understand what’s going on, he won’t trust the app enough to really use it
3. Protect users from themselves- too many options and GUI elements will make the user unsure whether they can actually use the app or potentially lead to a group of custom settings by the user that makes the app useless. Don’t try to make it infinitely customizable- that will just take an infinite amount of time for you to make and an infinite amount of time for the user to set up. Use reasonable defaults with only a couple of options.
4. Listen to users- not just to what they say but to what they’re really getting at

Whenever a proprietary operating system company gets enough market share, they ignore common sense and courtesy.

One of the things that impelled me to launch Tuxrocket instead of quietly leaving the Mac fold and going 100% Linux was the fact that I was so locked into Apple products (and products that only ran on Apple products). To this day, we essentially have to keep a Mac Mini running with our iTunes video purchases. By buying Apple I had sold my life to them.

Those that care already know that Flash doesn’t run on the iPhone. I will state right now that I am not one who cares.

So Adobe cleverly created a tool in their impending launch that takes a Flash file and creates an iPhone app out of it. There are a couple other products that do similar things.

But in their new iPhone 4.0, these will apparently be out the window. In fact, Apple has so much control in the space that they can tell you what programming languages to use. You can “think different” as long as you’re thinking how Apple wants you to.

Adobe headquarters must be literally filled with yells and screams right now. The launch of their new product has been answered by Apple: “Oh, you’re going to compile Flash into something the iPhone will run. Ummm. No, I don’t think so.” And frankly, Adobe can’t do a thing about it. The iPhone is in Steve Jobs’ pocket.

If anyone out there was wondering if Apple has gone power-crazy, you should have your answer now.

Support openness. Don’t go for lock-in. Go for empowerment.

Human Interface Guidelines (HIG) are available for all the major desktop environments. OK- I’m guessing on Windows (I was right). But Mac OS X, GNOME, and KDE all have guidelines meant to steer developers to develop in a way that makes apps consistent in various ways.

For productivity, consistency can be key. Users need to be able to use their computers. Not groan every time they launch a needed, but bizarrely put together, app.

Apple for several of its own apps, tends to ignore their own HIG, choosing instead to make an interesting user experience. Since the launch of the iPhone, that thinking has blossomed- leading to UIs like these from Landing Pad.

At what point does a beautiful app distract too much from what the user is trying to accomplish? Is the HIG you’re developing for hold you back?

One of the design goals was when you saw it you wanted to lick it.

When Mac OS X first came out, Steve Jobs bragged that they were making an interface so beautiful you just wanted to lick it. Now, I don’t know about that, but having a beautiful interface is definitely not going to hurt you. Take a look at this MacHeist ad I just got yesterday. MacHeist repackages third-party Mac apps and sells them in bargain bundles- often including a puzzle to be able to buy it. Notice anything interesting about it?

There are only 2 things being sold here. That’s right. Yes I can count the 7 apps in the bundle. But really they’re selling on two points. The app icons and the bundle price.

These aren’t apps that make sense to be sold together. They’re a pretty good hodgepodge of functionality. They’re also not ‘essential’. But they normally cost a lot more. And the icons look nice and are presented beautifully in the email. Yes, there’s a description of each app, but it’s so short as to be simply a note about what you’re buying- they’re not a full description of each app.

Take a moment and look at your app icon. Is it lickable?