Software for Activists - the Do's and Don'ts
- Software for Activists - the Do's and Don'ts
- by Stephan Urbach
- This paper goes to the devs out there. I first want to say "Thank you!" for doing great software. I as an activist have some sweet advices for you on how to make your great software the greatest.
- First, please make good UIs. Make them that anyone can use the tool. You will not believe, how many people out there would use your great software if it was usable. Please remember, that not everyone outside who is on the ground is in the position to have the knowledge on how their machines work and how they get configured proper. Please do not create security problems because of a shitty UI. There might be a great algorithm but if most of the targeted user base is not able to use it the goal is not reached. To solve the UI problem - show the tool to your friends and family. Ask them if they could use it. If your non-technical aunts and uncles can use it, then the UI is done right. Done right means: Do not make it blink, no hipstereffects and no douchbaggery. Do not mess around with shiny stars and cosy animations. Animations are only appropiate if there is really somehting done and needed to be visualized (e.g. key genreation). If this things can be done without animation - leave animation out.
- Make good error messages that the users understand. Yeah, for you might a big NULL be enough but for the users it is not. Catch exceptions and translate them that normal people understand. It is not a problem if an error occurs, but it needs to be understandable.
- Please, when you do the UI - do it like the last Hello Kitty App - without Hello Kitty. Do not write "Activists Messaging System" on it. Use Nyancat in it if appropiate. Make it hipsterglitter without hipsters and glitter. You get the point.
- Second, please make easy configurations. I mean it. It is really nice if I can configure the complete behaviour of a tool but users on the ground do not have the time and (even worse) the knowledge to do it properly. Do as much autoconfiguration as possible. If you have to create configdialogues, please do not do an "Expert Mode". Many people consider themselves as experts but really do not have a clue what they are doing. Imagine, someone of these "experts" is doing it wrong and because of his own fault he or others get hunted down and injured or, even worse, killed. Make warnings if there is the need to enter a name (or any other identification thingything).
- Third, watch the security of your tool. Make it open source, release the source and let hackers all over the world audit it. If they find something and you can not solve the problem - ask for help! Please make sure that it is the most secure thing ever available for the purpose you wrote it. Please do not advertise it as "Activists Tool" before it is checked by several persons. Do some tests in a secure environment. Do some tests in the wild. Review the tests, talk to others about it. See which comments they have to the code and the test results.
- Fourth, make language files which are easy to use. Translations of your tool can be crowdsourced. It is nice if your tool has a well written english but activists in Tunesia or China might have problems with this language. It is always easier to use a tool in your native language rather than in a foreign one.
- Conclusion: Be awesome. Make it easy. Test. Crowdsource. Review. Make it more secure. Test. Be still awesome. Thank you.
RAW Paste Data