Another year, another Mac Heist, another round of developers and users talking about how this is bad for developers and users alike. For the first year of Mac Heist I was in this group, which was much larger than it is today. I thought it devalued the software and let those running it run away with a hell of a lot of money while the developers got left with the support burden.
For the first year this did seem to be the reality, with developers getting fixed 4 or low 5 digit sums for their participation (apparently the amount each dev got was doubled after they saw how successful it was. This is what caused most of the outcry as it seemed those who were doing the marketing were exploiting those who did the "real work".
The second Mac Heist didn't receive quite as much controversy. People felt that developers knew what they were getting themselves in for this time. The deal was also a revenue share one rather than a fixed amount. The third and current Mac Heist is operating the same way and is receiving even less controversy.
The change is that developers are finding out more about how the bundles are run and maybe have participated in one of the other smaller bundles. The users are seeing better and better bundles each year with huge sums going to charity. And most of all we're finding out that it isn't a case of the developers doing the "real work" and the Mac Heist team just setting up a website. The amount of polish that goes into the website and the challenges rivals even the best Mac apps. Every year it becomes more apparent that Mac Heist isn't an easy thing to organise.
But none of that will make some of the issues go away. Does this devalue Mac software? Does it hurt developers? The first question I can't answer beyond saying that only time will tell, but I think it won't. The second one I can answer with a resounding no.
For those who don't know, I participated in a smaller bundle earlier this month called the Mac Bundle Box. It worked on a similar concept with 14 apps selling for $49 with 5% going to charity and each developer getting a percentage amount of the profits. It didn't sell anywhere near as many copies as MacHeist does, but it was still a hell of a lot of sales. How many sales? Well I made about twice as much as I currently do a month from regular sales, yet my support load has hardly increased.
Another important impact is the publicity. Your sales outside the bundle can increase as people find out more about your applications. Of course this is more likely to happen if your app costs less than the bundle price, but it is an important thing to considered. It also builds up your user base meaning many more people spreading word of mouth reviews.
As an example of how much developers are making let's look at the figures Mac Heist provides on their site. At the time of writing there has been $123,000 raised for charity, meaning $492,000 in revenue. There are 12 apps, plus a bonus app, plus the Mac Heist team all getting money from this. Let's assume a straight 14 way split, that would be 7% (actually a bit more but let's round down to take into account expenses somewhat). That would mean each party has so far got $25,830, enough to live off for a year if you keep your costs low.
And this is only so far on the first day. There are another 13 days to go on top of the rest of today. Sales will slow down but they'll still be making a 5 digit sum each day. Let's conservatively assume that they average $10,000 a day, that would be $140,000 each for 2 weeks.
Obviously the maths isn't perfect, the expenses may be more, the parties won't get equal amounts (I'd wager that the cheaper apps get a smaller percentage than the bigger apps), but we're still talking a LOT of money. One Mac Heist could set a developer up for several years or let them invest in support staff or other developers. Basically it is more than a good deal for developers, so don't worry about them unless the ones participating start complaining.
A recent few posts about accessibility in the Cappuccino web framework got me thinking, how well do my applications fare in terms of accessibility? The answer: OK.
Of course OK isn't good enough. The Mac is a platform the prides itself on user interface, yet it seems it isn't quite as good as we might think. I'd spent no time thinking about accessibility in my applications, and while they were more accessible than I was expecting, there is still a lot of work that needs doing. So I thought I'd check how some other popular applications work with accessibility and what can be done to improve accessibility on the Mac as a whole.
The first thing to do is explain how to use VoiceOver and navigate your application with the keyboard. Let's use iTunes to try with. With standard keyboard navigation you can easily enough move between the search field, song list and source list and can click on the various buttons with the mouse. But obviously this isn't going to be enough for someone who is visually impaired or who has a motor disability to make full use of iTunes.
To turn on VoiceOver you can go to System Preferences > Accessibility, or just hit Command-F5. Now you will see a black border around one of the UI elements. This is the currently selected item. You can navigate the UI using control-option and one of the arrow keys. Just move around and see how you can how access the full UI, especially take note of what VoiceOver is saying on the various buttons.
Quick Tip: To navigate HTML content, hit control-option-A when the HTML view is selected. This will start reading the full site. You can now use control-option and the arrow keys to navigate the HTML
Below is a table containing some useful shortcuts for navigating the UI from your keyboard, even without VoiceOver selected:
| Shortcut | Description |
|---|---|
Spacebar | Press the selected button |
Control-F1 | Turn on Full Keyboard Access (needed for the other shortcuts) |
Control-F2 | Switches the keyboard focus to the menu bar so you can navigate menus |
Control-F3 | Switches the keyboard focus to the dock so you can navigate the dock |
Control-F4 | Switch between windows |
Control-F5 | Select the active window's toolbar |
Control-F6 | Highlight a palette |
Control-F7 | Switch tab behaviour between "All controls" and "Just lists and text fields" |
Now try your own app and see how it fares; odds are it won't do too well. But you aren't alone. Here are a how well a few popular Mac apps work with accessibility.
For the most part Coda isn't too bad, but one pretty serious bug. It seems to cause VoiceOver to be unable to move around the UI if you switch between Local and Remote views in the source list, stating that it is "busy".
Coda also highlights the most common accessibility flaw: Image Buttons.
As you can see, the descriptions of these buttons aren't very, well... descriptive. These are the most common problem, yet also the easiest to fix and can make a world of difference.
OmniOutliner Pro has a huge failing. There's no way to navigate to the inspector using just the keyboard. The standard Control-F6 command doesn't work. This means that you have to use the mouse in order to move to an inspector. And when you have moved to an inspector, there is no way to move between those inspectors without again using the mouse. This is a shame as the rest of the application works pretty well with VoiceOver.
As with most applications MarsEdit is fairly good, but far from perfect. In the post window there is no way to navigate to the Categories table. You can just about get it to highlight with VoiceOver, but it won't let you navigate it. Besides this though the post window is pretty good. The same goes for the main MarsEdit window, besides the image buttons with no descripdtion it has no major flaws.
Again, Delicious Library 2 suffers from image buttons with no descriptions. But by far the biggest problem is the main display view. They keyboard navigation is great, I can move all around my books and CDs and DVDs using my keyboard. But I'm getting no feedback about what the currently selected item is. As I switch items it would make sense for it to read out the names of those items so I know where I am.
So I did come at those from the perspective of someone who hasn't got a disability (well I need glasses and have mild RSI but I can use my computer without needing any real help). What I consider "pretty good" may still not be too good for a disabled user. But what is obvious is that there is a lot of work that needs to be done. We all take so much care and pride in our visual UIs that we don't think enough, or really realise that there are other UIs that people need. Most of us wouldn't ship a shoddy, half baked UI but the fact is that we are all doing that.
So I thought I would challenge my fellow Mac developers to do something that I am pledging to do here and now:
"By the end of 2009, all the apps I produce will be fully accessible"
What do I mean by "fully accessible"? Well, I take it to mean the following points:
Of course there are some caveats. Some applications cannot be easily made accessible. Photoshop for example would be nearly impossible to make fully accessible to visually impaired. But it is conceivable that someone who is unable to use the mouse could draw. OS X does provide methods for controlling the mouse cursor with the keyboard, but with some inventive thinking certain classes of drawing application could be made much more accessible.
Making your application Accessible can also offer great advantages in other areas. Tools such Instruments and Automator use the accessibility APIs for recording UI actions to perform back. This can help you as a developer with debugging and your users with automating your application. And if you or your users want more flexibility, making your application accessible opens up the possibility of creating UI scripts in one of the various supported scripting languages.
There are also other potential applications of accessibility. Those of you from pre-OS X days will remember the old Mac Help system that could guide you through performing an action by highlighting the relevant parts of the UI and even performing the actions for you. There's no reason why that shouldn't be possible in an OS X app. Imagine how much documentation writing and support time you could save by being able to have your application show users how to use it!
Of course there will be some questioning the value of doing this. They realise it's a nice gesture, but they don't see the return on investment:
"But I don't know anyone with a visual disability" - I don't know any starving african children or anyone dying from cancer, doesn't mean I shouldn't care. Because you don't personally know someone with a problem, doesn't mean nobody has that problem.
"I've never received any support requests asking me to improve accessibility" - That doesn't mean there aren't those out there wanting better accessibility. Consider that someone might use your app, find it's not accessible and just give up on it. They're not going to waste time sending you an email when they can't see if your app is even worth their time and money.
"Sounds like a lot of work, I'm not sure if it'd be worth the time" - Making your applications completely accessible may take a lot of work, but you can do a huge amount in just a few hours just using Interface Builder. Going through and making sure you controls all have accessibility titles and descriptions, linking your UI elements together properly, making sure the accessibility hierarchy is usable. All these are small tasks that don't take too long and can improve your accessibility a huge amount. You don't even have to do all the accessibility stuff in one version, split it over several versions.
"But I can't make my application accessible for blind people" - Don't think that accessibility is just for blind people. Being visually impaired doesn't mean you can't see, just that you have trouble seeing. There are also other forms of disability that need accessibility such as hearing disabilities and motor disabilities. And on top of this, keyboard navigation can appeal a lot to power users who have no disabilities at all
Unless we experience something or are affected by something personally, we usually don't care about it as much as we know we should. Try closing your eyes and doing something. Odds are you'll end up opening your eyes for a peek at some point. You're lucky to be able to do that, some people can't.
I've not got a disability that limits my ability to use the computer and don't personally know anyone with one, but I do have a strong sense that we should all be treated equal and have equal opportunities. When we can do something to help someone else and it is very cheap or very easy to do, then we should do it. Making accessible applications can be very easy and not take too much time, but can make a world of difference to some people.
Over the coming months I'll be posting my experiences in making my applications fully accessible so you can learn from what I've found out. We've already made the Mac the platform with the best visual UIs, let's make it the platform with the most accessible UIs.
Apple's Accessibility Developer Page
For the next 10 days Code Collector Pro and 12 other applications are taking part in the MacBundleBox. This is your standard bundle deal: get lots of cool apps for very little money, in this case just $49. There are some really cool apps in the bundle, such as DrawIt (a vector drawing package) and DEVONnote (an advanced note taking application).
The great thing about bundles like this is that you can find out about lots of other cool applications you've never seen before, such as Espionage, QuickScale, Magnet and Involver. A lot of people tend to criticise bundles that don't offer "the big names", but I personally find them much more useful for finding new apps if you've never seen them before.
This bundle is also donating 5% of each sale to Charity: Water, a charity that aims to give clean drinking water to the 1.1 billion people without it, so not only will you be getting a lot of great apps for a low price but you'll be helping others get what we all take for granted.
This is the M Cubed Software weblog. From time to time we post information about our apps, including updates, tips and tricks or even the story behind how they were created.
If you would like to subscribe you can do so using the link below
You can view our monthly archives by using the links on the left, or search our blog posts using the field below to find what you are looking for.
Nov • Oct • Sep • Jun • Apr • Mar • Feb • Jan
Nov • Aug • Jul • May • Apr • Mar • Feb • Jan
Dec • Nov • Oct • Sep • Aug • Jul • Jun • May • Apr • Mar • Jan
