This article makes the case for tackling complexity in web app development by creating multiple apps.
Example
Let's imagine how employees at an intergovernmental site monitoring carbon emissions might interact with their data.
- Big picture: charts, executive summaries, key stats, takeaways
- Analysis: interactive charts, models, scenarios, generating reports and new requirements, summarising data, picking out key data points and writing takeaways
- Data entry: inputting data, overseeing ingestion of data from disparate sources, editing data, validating data, fact checking reports
- Regulation: auditing data, verifying data, source-checking
- Political: ensuring commitments are made and standards adhered to, raising concerns, identifying problems, issuing warnings
- Public: oversight, providing criticism and feedback
The data may change little but the people using them, and the access they need, will.
The problem for the development team (and we use this term broadly to include everyone contributing to building, marketing and promoting the site), is to determine who sees what, when, and why. Nor is this a one way street; depending on their requirements, our analysts, statisticians, politicians and public may need to give up information about themselves.
Is it better to create multiple apps (data entry, analytics, dashboard, etc.) or variations on a single app? Whatever the decision (we will be putting the case for multiple apps), understanding the needs of users is necessary for writing less code and designing simpler interfaces.
If teams ignore differences at the outset, contradictions accumulate and complexity increases.
Analysis
How do we prevent this from happening? The first step is to consider all possible user flows and place them in groups. The number of groups is critical; the fewer the better so long as no one group becomes a bucket for miscellany.
Here's another way to break down our user segments:
- Who needs what data? Some users require high-level summaries (executives, public), while others need in-depth interaction with the data (analysts, auditors).
- How frequently do they interact with the app? For example, data entry might happen daily, while audits might occur quarterly.
- What level of technical expertise do they have? Data entry operators might need a simplified interface, while analysts may require complex data manipulation tools.
This work is not trivial. It benefits from expertise in UI and UX but ideally it should involve disparate team members, including people who understand human behaviour, data manipulation, HTML, screen readers, accessibility, performance, security, SEO, marketing, etc. It's a long list.
The matrix of needs
Writing down the needs of different users is a pretty clear requirement. How else would we know what to build? Once we have that information, we can use it in multiple ways because we are programmers and designers and studiers of human behaviour. We can show where there is overlap, which items are unique, what is universal, and we can rank requirements in multiple ways such as necessity, risk, development time, etc.
Discussion
Not everyone likes meetings but without informed, critical discussion, problems will emerge that could have been prevented. Here are some of the benefits of (long) meetings:
- Job titles become less important
- Everyone gets a chance to speak (if the meeting is sufficiently long)
- Solutions bubble up as workable ideas replace opinions
- Consensus is derived not imposed
- New thinking emerges
- Collaboration improves
Implementation
It's a principle, not only held by developers, that it's a bad idea to repeat yourself. This is a good argument in favour of components. Components are used multiple times. A button component might be used hundreds, or thousands of times, and it will allow for a certain amount of variety.
It's tempting to have one app because it feels like a lot of effort to have more. But it needn't be, especially if a team knows why they have multiple apps, and are comfortable building and maintaining them (working from, perhaps, a template generator). Apps aren't that hard to build; the problem is what to show and what not to show, and to whom.
The best way to stop a visitor going where you don't want them to go, or from doing what you don't want them to, is to remove that particular option. This is also a good rule for development teams.
Here is how we might tackle two of our apps.
The dashboard app
In our hypothetical app, we make everyone's life easier, by building a separate app for the dashboard. It consumes data (it's read only), it might not need a menu, and it can expand to fill the screen. It won't be hard to display data by region, and to work out how much the authenticated visitor is authorised to see. From the development perspective, that is what the dashboard boils down to: a filtered, read-only summation of data.
The data input app
Data input can be a tricky business and for this reason alone, it's best kept apart from everything else.
Inputting a tonne of data once a year is a different problem than frequent, small additions. Together with security, that's enough for one app.
Single purpose
It's much easier to maintain small apps that have a clear purpose. It is easier to manage new features, release dates, customer updates, etc. when there are fewer risks and people involved. Security assessments can be made according to risk, sustainability based on use and exposure, and accessibility tested more easily and more often.
Common approach
Our apps will have much in common: the same framework or strategy, common best practices and development processes, shared resources such as a design system and component library, authentication and authorisation control, and a single team. Beyond that, apps can and should be different; they (should) serve disparate needs and be tailored accordingly.
Reducing unnecessary interactions is essential for the improved performance, accessibility, security and sustainability (PASS) of complex web apps.