The Magic Framework Problem

This happens when two ways of thinking collide.

• The framework developers create lots of “super smart” components. These components are so good at their job because they hide the underlying complexity and deal with major issues very well.
• The designers have an imperfect understanding of the challenges they face. This is normal – design usually happens before most challenges come up. So they design with what they know, and often with a preconceived notion of how things work.

Mix the two together: The designers assume the framework will deal with all the design issues automatically. In other words, magic.

Getting Back to Fundamentals

To use those toolkits effectively, the designers and developers must have an understanding of the fundamental problems. The fundamental problem is leaning on the OData protocol to do a lot of the “heavy lifting” and therefore forcing the user to wait for operations to complete.

Any designer who doesn’t include a model of every asynchronous operation that occurs in the program flow is making this mistake. Any call to an API, data source, or server, is going in incur some cost. Those costs must be clearly identified – or the real experience won’t match the one in the blueprints.

Let’s take this even further, however. Two major things:

• Don’t design around the frameworks. The frameworks aren’t magic. If the design is agnostic, and just discusses the implications, then the developers can solve those problems using the frameworks (TL;DR: Don’t put the cart before the horse).
• Focus on the user. The user experience is often lost in the functional requirements. Software that hits all the requirements, but is hard to use, is a maintenance nightmare.

The Frameworks Are Great, but They Are Just Tools

A toolkit works best when it has very powerful, advanced features. Those features should take care of issues and problems, and even better if they take lots of code and centralize them. This is definitely the case in asynchronous operations, like the ones I was describing.

I’ve also found the best way to discover the greatest, most hidden, features of a framework is to look for a way to solve a problem.

In conclusion, Angular, React, and UI5 can solve these problems for you. But first, make sure you know the problem exists.