The importance of user interface technologies and frameworks often is underestimated completely . This may result in a successfully delivered application with a top backend but one large problem: lack of acceptance by the users. And lack of acceptance usually results in finger pointing between customer and vendor since the customer blames the development team for having build an application which does not meet their expectations and the development team insists on having implemented all requirements. And quite often this is the end of a relationship between customer and vendor.... There are many things which can be done wrong when deciding for a UI technology and these wrong decisions might cause situations as the situation described above. This article chalks out typical drivers for wrong UI decisions and points out solutions how to sail around these frontend traps.



One of the most common reasons for lack of user acceptance is performance. If the application keeps the user busy by showing the sandclock the user will judge the application is not what he expected, even the application mirrors hundred percent the underlying process. Performance is one of the killer arguments which puts blinders on the users eyes - the users will not judge anymore the apllications contents, a performance issue causes users to decline an application completely. A developer might reply: "but take a look at our highly optimized DB querries! It takes about 5ms to execute a query - that's close to world record!"...but the user is not interested in what is going on behind the curtains, he only knows that a table with 500 entries takes about five second until the data finally appears in his browser - and that is too long for him! So what went wrong? One reason could be the devleopment team decided for a UI-framework they knew pretty well from a previous project, but in the previous project they did not deal with large tables, major focus have been forms and fields...so they did not notice the framework always loads table data initially instead of offering partial load or servers side scrolling or something simila. The consequnece: even the backend performs extremely good the frontend keeps breaking the application since table loading and rendering is not the best dicipline of the framework which has been chosen. The situation described here gives us two rules for developers when choosing a UI technology or framework:

1) Knowing a framework good is not enough reason to decide for the framework in a project - especially the tricky requirements need to be covered by the framework! Step through the requirements as early as possible and pick out the ones which are "non default ones" and which might cause loading or rendering issues. Build these tricky requirements and test beyond the borders of the localhost!

2) Never cling to a UI technology just because you know it, keep an open view! Of course it takes time to evaluate a new framework and it takes some time to get up to speed with a new technology - but at the end of a project you will benefit from this time!

The second major reason for lack of acceptance of an application is usability (...one of the most subjective terms in the 21st century...). If a UI-framework is chosen because it provides for a good backend binding and is currently "standard" this not automatically a garant for good UI results and usability. Developers should always get familar with a UI-framework by using the framework in "real-world-scenarios" and not just playing through the always working default examples provided by the framework vendor. This is the only way to prove whether the framework matches the requirements or whether essentials are missing which result in the usage of heavy workarounds. Small workarounds can be accepted, such as using a tree and a list as single controls instead of having a tree-list control, but if you start to fall from one workaround to the next the framework might not be the best choice. Using the framework in order build some screenflows in advance is as well good practice to establish a feeling regarding times required to implement the application. This results in another rule:

3) Evaluate a framework by using the framework! Create some screenflows from the requirements, you will notice pretty fast whether the framework matches or whether you should switch...

Finally it happens quite often that there is not much attention being payed to the user interface part of an application. Developers prefer focusing on the "real important" things of an application which are somewhere in the backend from their point of view...but this is a completely outdated view! The user interface is the only thing of the application directly "in contact" with the user - and the user will decide about an application based on this user interface as this is the only thing he can judge. So there is another rule which is one of the most important ones:

4) Do not underestimate the user interface part of an application! It is the only thing honored by the user - choose a technology which enables you to create magnificent GUIs with a solid backend binding for your requirements and the users will love you! Chose a technology with good backend binding but weak UI results and the users start railing about your application (and you!).

Our conclusion: chosing a UI technology or framework is difficult, the probability to decide for an 70% solution is much bigger than hitting the bullseye. Especially the huge amount of different technologies in the space of UI development is a challenge for every project. That's the reason you either have to stay up to date regarding current UI technologies and frameworks or you have to seek experts advice - richability is a good place to look for both, so keep reading our infospace or simply contact us in case of interest for an UI discovery workshop!