Professionals: consider paying someone to use your software for some real activity, not just unit testing, and have them report bugs and annoyances. But I quickly realized it could help users in many other ways. I made scripting in good part for myself, so that I could restart where I left off, and also do at least some minimal QA testing before making a new release. This system doesn’t get in the way of most people simply using the program as-is. Or if you can put a script on the command line if you want to start Mineways up with certain export options or viewing a particular world. But for power users, if you want to do a bunch of exports in a row, e.g., tiles of terrain, it’s invaluable. Nothing clever, very little to learn, no Python or even loop constructs in the scripting. Every UI action has some simple, English script command for it. One example for Mineways is basic scripting. If you can leave the basics in place and make the frills and power-user features available but not distracting, great.
This can unfortunately sometimes lead to feeping creaturism, as more and more crazy options get added, to the point where the author is the only one who understands how to use their program. Using your own software makes you realize things that could be better. I could stop this post right here, as I’d say that’s the main thing I’ve learned.Įat your own dogfood: I’m lucky in that I actually want to use Mineways, that’s why I originally wrote it. Really, I should change a few to optionally take the user to a web page describing what to do.Īs a user, I’m happy to get as much information as I can. Over time, the error messages in Mineways have gotten longer and longer, as new problems get reported by users.
Or we’re embarrassed to fully explain the solution, “everyone should already know that I’ll feel I’ll look dumb and will insult my users if I write it all out.” You aren’t dumb, and no you won’t.
It’s as if every word costs us a dollar (hmmm, I guess it could, with localization…), so it’s like we play a game of making the messages as short as possible. I’ve noticed a tendency to have extremely terse error messages, installation instructions, and explanations in general. Instead of sending your users on a possibly fruitless search expedition, or them just giving up on your software, spell out what’s going wrong. Indeed, one Google Photos purge later, that was it.
Recently I received the error message “An Error Occurred Installing iOS 15 on iPhone.” This is a prime example of “not useful.” Googling around and wading through the “buy our software to fix this” come-ons, I found the problem was maybe that there wasn’t enough memory free on my phone. Useful error messages: The most boring part of any interactive application, but vital. So, I thought I’d summarize some of the lessons I’ve learned from developing this interactive app. It’s just turned 10 years old, and has been downloaded over a million times, from what I can gather (about 300 downloads a day currently). It exports models from Minecraft, for making animations or for 3D printing.