When developers, designers, startups, etc. think about User Experience, they often imagine simple GUIs, great graphical design, gratifications, bells and whistles and whatnots. Basically, all things that would guide end users towards getting revenue (or other goals). For the sake of this post, let's call it these UX features part of the User Land (UL).
A lot of times, what is delivered in a UL product or service caters to their creators' needs, mindset, etc. A mix of catering to their own pain points and their own expertise. This can result in amazing results, true. But, more often that not, they scratch a single person's own itch.
These concepts can also be applied to an oft forgotten place: Developer Land (DL).
Software, nowadays, is highly complex. It's a mix of creativity, off-the-shelf components and libraries, glued together in a perfect (dis)harmony. The high-burden and error-prone process of creating applications leads to reusing – and correctly so – existing components and libraries. The humungous landscape that is the software libraries world (frameworks, classes, generators, development environments, etc.) can be daunting for a lot of developers.
But several developers create libraries to cater to their own pain points, and believe other developers have the same expertise. While this can result in a good software library, things can get pretty messy easily. Hence, DL end users (i.e., those using software libraries in their own applications) face the same problems as UL end users. Confusion, insatisfaction, not meeting their goals. That is, developers also experience bad UX in DL.
So, without further ado, here's a small list of best practices to provide a good UX in Developer Land:
- Proper APIs: whenever possible, classes, functions, parameters, data types, and any other identifiable naming schemes, should have clear, concise names, including clear naming in REST-style APIs. Even further, they should be self-documented, so that even seasoned developers don't need to RTFM every single time they need to use a particular feature.
- Documentation: it's never enough to stress this point. Documentation provides detailed explanations not just on how to use each class, function call, etc. (although proper APIs partially fullfil this requirement), installation, configuration, building instructions, etc. must be sane and descriptive. Developers shouldn't assume that everyone knows every tiny bit detail about library X that should existing in path location Y, in order to have something working.
- Tutorials/Guides: when software libraries are more complex than a Hello World, in can be (it usually is!) daunting to dive right into APIs and reference documents. This is where tutorials and guides appear. They provide easy, step-by-step instructions on how to use libraries, i.e., step by step examples on creating something useful. These positive reinforcement activities do allow for better learning experiences.
- Examples: while tutorials and guides exemplify usage, they cannot cover every single detail about using all the features provided by a software library. Hence, proper APIs should be complemented with example usage – not just a piece of code, but a detailed, explained step by step usage of each feature.
- Error handling: let's face it, errors do happen. Even when software is correctly implemented (i.e., bug-free), it can fail due to external stimuli. Thus, software libraries shouldn't fail silently, nor crash abhorrently. Error handling should be built from the ground up, and exposed in a graceful way: less of the C's function-return-error-value, and more of the errors-are-exceptions-on-control-flow.
- Sandboxes: when libraries really do get complex and tricky, developers are less confident on trying out their features. This gets even worse when libraries handle information-sensitive features (e.g., posting messages to social networks), or which can trigger payment activities. In these cases, developers should provide safe environments – sandboxes – where DL end users can try, test, tweak, and fail on using libraries without penalties.
- Gratifications: the oft-forgotten realm of inside jokes embedded in software code, comments, etc. They don't offer anything practical, regarding their stated purpose (i.e., functions, etc.). But they do provide a sense of accomplishment – and good laughs – to those who delve and inspect the source code.
And, that's it for now. Happy coding!
