Screaming Penguin

So this is something that has been stewing in my head for a little while, but it still isn't fully baked. Forgive me if it goes a little sideways. As readers of this space know, I maintain Shortyz, a crossword app -- client, really -- for Android on the market. Honestly, this started out as a "scratch your own itch" FLOSS project for me, but has actually kind of taken off. It is one of the best reviewed "games" on the Market, and the user base is rapidly approaching what can be properly called the tens of thousands. Lately I have been making a lot of changes to the UI. Nothing I would have considered major, but of course the feedback is generally negative. This I like to call the "Facebook." Any UI changes will pass without acknowledgement from the people that like it, and inspire vitriol from the people that don't. A great example: Recently I changed the progress bar on the browse list view from the stock Android ProgressBar style:horizontal, to a vertical one along the left edge with some color codes. This was actually how I wanted it originally, when I discovered Android doesn't include a style:vertical on ProgressBar (WTF?). Anyway, it makes skimming long lists of puzzles for incomplete puzzles easier, IMHO, and the color coding adds new information about the NYT puzzles. Moreover, I borrowed a lot from Twicca, which I think does a good job of showing that you can make something that looks like "Android" without looking bad. Of course, I get 22 emails from people who hate it, and one from people(?) who like it. Still, I think it is better. There has been a lot of people who complain on the Market about the lack of Zoom control. Of course, there is a Zoom control, under the Long-Touch context menu on the playboard. I thought this made perfect sense. Long touch is part of the Android metaphor, and I support it everywhere but one place in the app for various functions, but people still don't get it. Is that because Long Touch is a broken action type? I don't know, but it pisses me off when others don't support it. This is kind of tangential, but it does make one significant point: Users don't use the app the way you intend them to. Ever. The point about superstition comes with something that came up today in the comments on the app. I added a Double-Tap toggle between your standard Zoom setting, and a "Fit to Screen" Zoom (as well as a proto pinch zoom on Froyo). This seemed natural to me because this is kind of how the browser's "Zoom to DOM Element/Zoom Out" mechanic works. I'm not introducing a new action to the user, just copying one that is likely familiar. The thing I learned is that users learn your software in a very human way: "Ilan" said that I had confused "Double Tap to change directions" [direction here being across or down] and "Zoom." Actually, the Zoom function was the first time double tap was ever even recorded as an action in the game. To change directions, you can press "Space" on the soft or hard keyboard, or tap the current cursor box. Now a double tap anywhere on the screen previously would change the current cursor box, then change directions, but these were actually two separate actions as far as the app code and design were concerned. This user, however, had interpreted this as "Double Tap changes direction." We all know users don't read. I have help text. I have all the things you are supposed to have, but some people have a model in their head, and that is how the software should work. The last major upgrade, I implemented four different movement strategies based on the feedback I had gotten on how movement on the board should work. The original version was based on how I wanted it to work, but it became clear there were different camps. That update eliminated ALL of the complaints in my inbox about the movement pattern. The lesson here: Users will play with settings, but they won't read help text. Joe Nuxoll advised me at JPR that my app already had too many user settings. He was wrong. Even if you create a setting to make something idiotic, users will play with it and realize how the default works and go back. They will never read your text about how the default setting works. But, more importantly, giving these customizations can eliminate "software superstition." That is, the user getting the wrong idea about how the software actually works. Maybe they read that one liner about what the setting does. Maybe they don't. However, you have now given the user a one variable experimental basis to form a new "scientific" (as opposed to "superstitious") mental model of how the software works.