November 27, 2015
Software attractiveness seems to be something out of our rational control, something related to emotions and moods, isn’t it?
May this sound pretty unpredictable, software attractiveness can be measured and anticipated, helping us to bring lots of visual and social satisfaction to an end-user.
According to the ISO 9126: 2001, 6.3.4., this quality attribute is defined by the capability of the software product to be attractive to the user.
The thing we should put our opinion on is that attractiveness is defined not by an engineer, but by an end-user, so, despite a huge amount of different researches (and we better not ignore them) concerning color, usability and functionality of a software, user questionnaires are the most effective and informative way of assuring application attractiveness.
The science of application attractiveness rests on design basics and our perception of the environment we live in. A common practice is to furnish a visually good-looking application with sounds and even vibration response (this practice is a sign of good manners at the mobile app market). Here, it bears mentioning that for a certain percentage of end users (or the majority of them, if we’re talking about some special applications) visual attractiveness might be dethroned with audial or even tactile, placing them atop.
Once again, through referring to the ISO 9126: 2001, we find out there’re two main metrics that require measurement to prove an application is ‘attractive’:
Interface appearance customizability
- Attractive interaction is measured with specially designed questionnaires. Their results are to be taken as absolute, and cannot be compared with another application polls. Questionnaires results are passed to UI/UX designers whose knowledge in usability and styling get enriched with current social preferences and actuality.
- Interface appearance customizability is assessed through testing that simulates human behavior and through observing a user behavior and gathering feedback. Actually, customizability (C) is a value that should aim for being equal to 1. It is calculated by simply dividing the number of interface elements customized in appearance to user’s satisfaction into the number of interface elements that the user wishes to customize. It needs no saying, we do rarely get a product with C=1, as it would require significant efforts to be created, coded, tested and maintained. Also, the more complex a product is the more
Once again, people with special needs (if they appear to be a part of core audience) should be at least taken into consideration as their interactive experience might differ from one of the average customer. Here, both questionnaires and customizability assessment must include items to evaluate whether these people have a chance to interact with the product gratifyingly.
This leads us up in general to such a quality attribute as operability, and in particular to its part called ‘individualization’. These aspects will be highlighted in our further posts. Stay tuned.
October 11, 2017 | Nikola Krastev
A microservices approach is not a silver bullet for all software architecture problems. It introduces tradeoffs and challenges of its own. However, process gains and improvements in human performance have been considered to be worth the overhead in technology. Here are some general arguments against using sophisticated SOA. Server performance and overhead in communication By […]
September 27, 2017
We are pleased to announce that CoreValue president Igor Kruglyak will participate in IT Arena 2017, to be held in Lviv, Ukraine, September 29 – October 1, 2017.