Over the years, people have developed various conceptual models for building graphical user interfaces (GUIs) for desktop, web, and now mobile systems. With the advent of LLMs, it seems that we are finally transitioning to the next phase of human-computer interaction: conversational user interfaces (CUIs). To avoid reinventing the wheel, let’s review these popular conceptual models, in the hope that we can learn something for building CUIs.
Procedural or Flow-based Model
A flow-based approach is a method for creating UIs by defining the sequence of events that occur when a user interacts with the interface. This is achieved by creating a flow diagram that illustrates how the UI will change in response to user actions. The flow diagram shows how the steps are connected to each other, and how the flow of execution can branch or loop depending on certain conditions. Because flow-based approach defines a sequence of steps that must be followed in order to complete a task, it is considered procedural or imperative.
Building a user interface using the flow-based approach is popular mainly because it is relatively easy to learn and use. Since we need to model user input into the interaction flow, this approach can be very effective when the expected user inputs are limited, which is always the case for simple use cases. The flow-based approach is generally effective for building GUIs, as developers can control what the user can input on each page, thus limiting user inputs to an extent that is reasonable. Unfortunately, it is not a good choice for building conversational user interfaces, as users can and will say anything at any turn, and developers can do nothing about it.
Object-Oriented, component-based model
Object-oriented GUI development emphasizes representing GUI components, such as widgets, buttons, windows, and controls, as objects with attributes and methods. The main benefit of object-oriented paradigm is its reusability and maintainability.
OOP allows developers to create reusable code by encapsulating functionality within objects. This means that developers can create objects that represent different parts of the GUI, such as buttons, menus, and windows. These objects can then be reused in different parts of the GUI or in different applications altogether. This aspect is also known as component-based modeling, where the ability to build complex behavior by composing smaller and simpler components together is emphasized.
The public interface of a class defines what it does, instead of how to do it. By clearly separating what from how, OOP code is better organized and modularized, thus generally easier to maintain than procedural code. It is thus no surprise that most of the GUI development is either OOP based, or it is derivative of that.
The public interface of a class defines what it does, rather than how to do it. By clearly separating ‘what’ from ‘how,’ object-oriented programming (OOP) code is better organized and modularized, making it generally easier to maintain than procedural code. Therefore, it is no surprise that most GUI development is either directly or indirectly based on OOP.
Event-Driven Programming
Event-driven modeling focuses on responding to events. Events are occurrences that happen in a system, such as a user clicking a button, receiving a network message, or a timer expiring. When an event occurs, the system responds by performing some action. Clearly, event-driven programming is a style of coding where a program’s overall flow of execution is dictated by events, and it employs the event loop as follows:
1. The program loads, then waits for user input events.
2.As each event occurs, the program runs particular code to respond.
It should be no surprise that event-driven programming is common in web development and modern desktop applications, as it is a direct modeling of GUI. Developers define event handlers to specify how the application should react to events. In the context of GUIs, the resulting system responds to events, including user actions like clicks and keyboard input, as shown below.
Event-driven programming is compatible with Object-oriented programming since delivering an event to an object is essentially calling a method on that object in the most basic sense.
Model-View-Controller (MVC) Model:
Model-view-controller (MVC) is a software design pattern commonly used for developing user interfaces that divides the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
Here is how three elements working together:
- View: The view is responsible for displaying the data from the model to the user. It is typically implemented as a graphical user interface (GUI), but it can also be a text-based interface or another type of interface. The view is also the place where user can create event for controller to handle.
- Controller: The controller handles user interaction and updates the model accordingly. It also tells the view how to display the data from the model.
- Model: The model represents the data of the application. It contains the application’s business logic and is responsible for storing and managing the data.
The MVC pattern is designed to make UI applications more modular, reusable, and maintainable. It also makes it easier to test different parts of the application in isolation. MVC is commonly described in the context of object-oriented programming. It is so popular that there are many variants available, such as Model-View-ViewModel.
Reactive programming
Under event driven programming, the user interface was updated only after some user action. It was an endless loop and was responsible for handling user input and updating the user interface. When the handling of some event takes too long, the GUI can become unresponsive.
The solution is to decouple the event handling from the GUI update. The decoupling is done by introducing an event queue and parallel event processing. Reactive programming is a programming paradigm that focuses on responding to changes in data. Reactive programming uses streams to represent data changes. A stream is a sequence of data elements that can change over time. When a data change occurs, the reactive program responds by updating the UI.
Reactive programming is often considered to be a better approach for complex UIs because it can make the code simpler and more maintainable.
It is no surprise that most of the modern GUI framework are based on this.
Parting words
While it is tempting to think that a flow-based model is sufficient for building GUI applications, the reality is that people continue to develop new conceptual models for GUIs, as evident from the non-exhaustive list above. These modern UI frameworks are typically declarative in nature, allowing developers to focus on what they want to achieve rather than how to implement the desired behavior. Component-based modeling is also widely promoted in these UI frameworks, along with reactive programming.
Considering that CUI is a lot more complex than GUI, maybe it is time for us to let go of the flow-based approach. A type-based approach that focuses on the schema of the API or model can be more productive.
Reference:
