Technology is becoming increasingly integral in our daily lives, almost as much as the air we breathe and the house which keeps us warm at night. This is going to continue to be a long-standing trend, barring some unforeseen calamities, and the wheels of progress will not stop turning during that time, either. This means that software will forever evolve and change, as will ideologies behind how it is designed and how we should interacted with it. This makes application usability a constant challenge.
As new designs and trends come and go, new systems and devices rise into novelty and then mediocrity, standards and expectations for how software should look, think and act change constantly, almost in rebellious reaction to standards being founded. As a result, it can make the lives of software designers and software companies rather unpleasant, as users berate and judge them for failed experiments or failing to keep with trends that never hold still.
In the spirit of this, let’s take a look at the top five challenges of application usability and why we should all give the programmers a little slack. As users, perhaps if we have an understanding of this, we can also learn to provide proper feedback as to not confuse those who try to forecast our needs into creating another 3DO or another Windows 8. These were our faults, by the way.
#1 – Platform Disparity
It may seem like the Cloud and smart web design are changing how platforms affect software design, but in truth, they’re nowhere near negating this issue, and are at least a century from doing so. Platforms are a problem, and no two, be they operating system or physical device, are truly the same. Contrary to what many believe, one Android smart device is not identical to all the others, architecturally, and the disparity grows when it moves to whole other systems such as Windows Phone or iOS.
This increases more when you factor in different devices, all of which have different mindsets and interface themes. PCs require a different approach from smart phones, which require a different approach from tablets, which require a different approach from smart gaming consoles and so on. This means that unless unique redesigns of applications are made for each platform, a unified design and concept has to be created that works moderately well for all at once. This is a compromise, and the definition of a compromise is an agreement where nobody is 100% happy, yet, software must be approached in this manner for the time being.
#2 – Aesthetics
Aesthetics are a problem for application usability, because as a consumer base, we like things to be pretty and shiny. Alas, some interfaces just are not conducive to this, due to screen real estate, processing power or simple practicality.
Overly-aesthetic designs hinder usability, make the programs harder to understand, and result in a bad, overly-engineered design that, while really attractive, slows the machine down or simply isn’t workable on a practical level. Again, see Windows 8 as an example of aesthetics getting in the way of functionality. Users did not like the look of Vista or 7, and as a result, an obsession with aesthetics has resulted in the utterly useless Windows 8.
Many mobile applications are beginning to suffer from this as well, and it’s worse here with screen real estate already at a premium. Some compromise must be accepted by users where a clean, elegantly simple look with functionality is acceptable, over a gaudy, impossible to use piece of software.
#3 – Productivity
With limitations in screen real estate even on PCs and large displays, there is the challenge of making productivity possible, and making features and tools within the application easy to find and use. The drive for this has created some trends in software that customers love to complain about, but have nonetheless resulted in increased productivity.
Two famous examples of this are the hatred of the ribbon interface that most Microsoft applications utilize now, which while ugly and awkward, does work, and the docking system used by most mobile systems. These make it easier to use the program, but users often balk at them, citing how they inconvenience them, or how they just liked old methods better. Once this mentality is overcome, only then will application usability be properly rated.
#4 – Complexity
This plagues business and artistic software more than anywhere else, but it can be seen in mobile applications too. The problem is that some software is immensely complex and powerful and simplifying the interface just isn’t possible for them. This causes the software to be very confusing and intimidating at first glance. Often, the software isn’t difficult to use once the user has time to learn the order of approach, but many users don’t give this a chance, resulting in them running away and complaining that the software’s just impossible. Obviously, this is a misjudgment of application usability.
#5 – Feature Centricity
This is partially the fault of the design industry, but as users, we should share the guilt on this. Many programs and applications become bogged down in additional features that can drown out the core functionality the software was intended to serve. This is because of the demand for integration of these features, primarily the case with the demand for social networking functionality being built into everything. Once, everything had a custom browser, now it is social functionality. It’s our fault as users for supporting this, but also the fault of programmers for not knowing when to actually disregard what users say. A prime example of this is Skype and Windows Live Messenger, which are becoming less like communication tools and more like social network desktop and mobile apps as the years go by.
These are just a few reasons application usability is a difficult thing to achieve properly for programmers this day and age, and as users, we must remember these things. Perhaps the next time a change or innovation is made in our software, we should think about these before complaining too vociferously, or before berating the updates too strongly. The changes are probably our faults for confusing developers to begin with.