I’ve been involved in many different code bases over the years aimed at giving users rich and easy access to information for running a business. Today this is done with Web technology, since it is widely available, but it deals with challenges and solutions that have been ongoing for decades. Relevant and very intelligent architectural concept date back as far as the 1960s. (Bret Victor - The Future of Programming) https://www.youtube.com/watch?v=8pTEmbeENF4
Many Frontend developers have less than 5 years professional experience. This means that they only know a world where the default choices were React and Angular. They mostly don’t understand the underlying technologies, so faced with core technology problems they come up with the wrong fixes.
In the beginning of a project performance isn’t seen as a big issue. “We can fix it if it gets out of hand” people say, but some issues will always be baked in by the fundamental choices that you make. No tweaks can change the weight of a Jet to that of a Car i.e. If your library is 3Mb you can’t shrink your application to 500Kb(the total payload Google amusingly recommends for achieving an all round well performing website).
As you add features, combinations of them can make the cost of maintenance explode. Let’s say that you present data taken from a server and represent them as charts. If you offer a single chart per dataset this will scale linearly with the number of datasets that you add support for. If you have 3 datasets and add a 4th it’s no big deal to code that one specifically, but if you have 10 and plan to add another 50 over the next couple of years, you should think about how to represent them more generically to simplify maintenance. Now if you consider representing the data using multiple chart types, you really want to move towards common implementation logic and declare the variations using configuration.
A common pushback that I’ve seen over the years is against the simplicity of the Web User Interface model. The Web browser revolutionised software in ways that were not intended. It sought to support the browsing, reading and linking of documents. In 2005 Gmail demonstrated how a web page could do what would then have been made as a Windows App the race was on to convert Desktop Applications into Web Apps. As demonstrated by websites like Facebook the scrolling document paradigm can support a large quantity of information as well as user data entry. While overlapping windows is a very powerful concept it is not made for a dedicated single purpose interface. If you have a general purpose computer it makes sense that you will be use it for completely unrelated tasks in parallel. Overlapping windows is a good candidate for that case. Even so windowing is often attempted within web pages, but once implemented the drawbacks become obvious.
On most profession Web UIs I’ve helped implement we’ve created dashboards to some extent, which is one of the strong alternatives to windowing. It has been tried in many variations with some failed flashbacks on the way to variants such as user free resizing. It turns out that users have a job to do and if you give them too much rope to fiddle with their set-up they end up hanging themselves.
User Interfaces have been created by engineers writing the software for most of the history of computing. This has lead to many concepts derived from the technical implementation. Some of these offer poor usability to anyone that haven’t gotten used to it through having it hammered into them. We tend to forget how much resistance Windows and other GUIs met from people used to DOS and Terminal interfaces. Just like many today expect overlapping windows to be a magic solutions, many also assume inputting data by forms with a submit button is the solution to feeding data into a computer.
A traditional interface concept for inputting data comes from CRUD (1983) https://en.wikipedia.org/wiki/Create,_read,_update_and_delete, which is conceptually about collections of records. You can view, search, change using lists and detail view of these records. These views are largely identical, making them hard to tell apart, with the content dictating the minor differences between them. This similarity can be both a pro and a con. Another issue is the lack of process. Core to CRUD is the idea that there is a body of resource types, i.e. Person, Family, Address, Workplace, Book, Decor-piece, where for each you can view and enter records. This approach is immensely powerful as it allows intelligently going through the current data and correct or verify it. It however fails to support standard processes and to present a coherent view. As an example dynamic document layouts can very powerfully combine information into a single interactive view that can enable in-place modification. We do not have to limit ourselves to UI concepts created for computers with 1000th of the power we have in todays mobile phone.
In the end with the modern interfaces that we’re trying out on modern Smartphone Applications we are finally moving forward towards interfaces made for good decision making. A good example of such attempts are demonstrated by The Humane Representation of Thought
I’ve been involved in many different code bases over the years aimed at giving users rich and easy access to information for running a business. Today this is done with Web technology, since it is widely available, but it deals with challenges and solutions that have been ongoing for decades. Relevant and very intelligent architectural concept date back as far as the 1960s. (Bret Victor - The Future of Programming) https://www.youtube.com/watch?v=8pTEmbeENF4
Many Frontend developers have less than 5 years professional experience. This means that they only know a world where the default choices were React and Angular. They mostly don’t understand the underlying technologies, so faced with core technology problems they come up with the wrong fixes.
In the beginning of a project performance isn’t seen as a big issue. “We can fix it if it gets out of hand” people say, but some issues will always be baked in by the fundamental choices that you make. No tweaks can change the weight of a Jet to that of a Car i.e. If your library is 3Mb you can’t shrink your application to 500Kb(the total payload Google amusingly recommends for achieving an all round well performing website).
As you add features, combinations of them can make the cost of maintenance explode. Let’s say that you present data taken from a server and represent them as charts. If you offer a single chart per dataset this will scale linearly with the number of datasets that you add support for. If you have 3 datasets and add a 4th it’s no big deal to code that one specifically, but if you have 10 and plan to add another 50 over the next couple of years, you should think about how to represent them more generically to simplify maintenance. Now if you consider representing the data using multiple chart types, you really want to move towards common implementation logic and declare the variations using configuration.
A common pushback that I’ve seen over the years is against the simplicity of the Web User Interface model. The Web browser revolutionised software in ways that were not intended. It sought to support the browsing, reading and linking of documents. In 2005 Gmail demonstrated how a web page could do what would then have been made as a Windows App the race was on to convert Desktop Applications into Web Apps. As demonstrated by websites like Facebook the scrolling document paradigm can support a large quantity of information as well as user data entry. While overlapping windows is a very powerful concept it is not made for a dedicated single purpose interface. If you have a general purpose computer it makes sense that you will be use it for completely unrelated tasks in parallel. Overlapping windows is a good candidate for that case. Even so windowing is often attempted within web pages, but once implemented the drawbacks become obvious.
On most profession Web UIs I’ve helped implement we’ve created dashboards to some extent, which is one of the strong alternatives to windowing. It has been tried in many variations with some failed flashbacks on the way to variants such as user free resizing. It turns out that users have a job to do and if you give them too much rope to fiddle with their set-up they end up hanging themselves.
User Interfaces have been created by engineers writing the software for most of the history of computing. This has lead to many concepts derived from the technical implementation. Some of these offer poor usability to anyone that haven’t gotten used to it through having it hammered into them. We tend to forget how much resistance Windows and other GUIs met from people used to DOS and Terminal interfaces. Just like many today expect overlapping windows to be a magic solutions, many also assume inputting data by forms with a submit button is the solution to feeding data into a computer.
A traditional interface concept for inputting data comes from CRUD (1983) https://en.wikipedia.org/wiki/Create,_read,_update_and_delete, which is conceptually about collections of records. You can view, search, change using lists and detail view of these records. These views are largely identical, making them hard to tell apart, with the content dictating the minor differences between them. This similarity can be both a pro and a con. Another issue is the lack of process. Core to CRUD is the idea that there is a body of resource types, i.e. Person, Family, Address, Workplace, Book, Decor-piece, where for each you can view and enter records. This approach is immensely powerful as it allows intelligently going through the current data and correct or verify it. It however fails to support standard processes and to present a coherent view. As an example dynamic document layouts can very powerfully combine information into a single interactive view that can enable in-place modification. We do not have to limit ourselves to UI concepts created for computers with 1000th of the power we have in todays mobile phone.
In the end with the modern interfaces that we’re trying out on modern Smartphone Applications we are finally moving forward towards interfaces made for good decision making. A good example of such attempts are demonstrated by The Humane Representation of Thought
Ready to take off?
