How to Make Bloated Software that Doesn't Suck

July 29, 2016

I like simplicity and ease of use, but I also like making software that accomplishes a lot.  I think it's a challenge to add robustness without adding complication and negatively impacting ease of use.  Ctitch is a prime example of this, and currently where it's at in it's development cycle, it's probably a little over-bloated.  However, I want all of the functionality that currently exists to stay, and I plan on adding more features in the future which could add to the overall bloatness of the product.  


I've been looking into ways to make Ctitch and my other projects as usable as possible, and these are my random thoughts on the subject so far:


Don't enable features by default

Keep things simple, but make it known that there is additional functionality if the user so desires it.  By not showing features that a user doesn't want, we remove visual clutter and cognitive load for them.  Ideally, we go beyond just hiding these elements from the user initially and actually don't load any of the html, javascript, and other assets since that just adds to the app load time.


Only show functions on interaction

Ok, I actually have mixed feelings on this, as I'm sure most UX people will as well.  I like clean, stripped down interfaces, and one way to accomplish this is to only show functionality if a user is working with a related element.  


For instance, when a user is logged in on Strymr, the latest websites they follow are presented in clean and simple tiles with just the article image, title, and description.  If the user mouses over a tile, additional options appear (like the ability to edit the post, add a comment, or delete it).  There are a couple issues with this, such as mobile devices where mousing over isn't a thing.  There is also something to be said of displaying everything to the user so they know all of the options that they have available to them and don't have to hunt around for functionality.  


Perhaps it's as easy as having a 'cluttered mode' where everything is displayed, and a 'clean mode' where we only reveal things as needed, but I'm pretty sure almost no one would change the setting.


Show help where it's needed

Instead of a large library of help pages and documentation (or perhaps in addition to), make sure to offer help wherever the user currently is.  For example, in Ctitch, a user can add a to do list to any of their folders, and there are keyboard shortcuts that make adding and formatting list items easier and quicker.  Instead of listing these shortcuts away in some repository of help documentation, I put in a little clickable help icon directly on the to do list that has all of this information easily accessible.  


In addition, for some of the shortcut actions, there are icons that the user can click on to accomplish the same task.  When mousing over these icons, a tooltip appears with a quick explanation of the task and the keyboard shortcut to accomplish the same thing.



There's more to learn

I'm continually building web applications, and I imagine they are going to continue to grow and become more robust over time, so there is still plenty more to learn about walking the line between simplicity and robustness.