Display patterns
Introduction
There are numerous display patters we’ll reuse throughout the LiteFarm application. There’s a lot of value in creating and reusing a pattern. First and foremost, it allows users to develop an intuition about how to interact with new parts of the application based on their experiences in other parts of the app. Secondly, it makes creation of different parts of the application easier and faster for the design and engineering team to create. Rather from starting from scratch, we can ask ourselves a series of questions and land on an appropriate starting place. Here’s a rough guide to the right pattern:
Collection views
Collection views exist where we need to display many similar or dissimilar things to a user. For example, we would use a collection view when displaying locations on a farm map, crops in a crop catalogue, or types of activities that could happen on a farm. When deciding the appropriate way to represent these collections, we should refer back to our https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/78905350. What is the most accessible method to show something to a user? Does a map, picture, or verbiage most effectively convey the idea we’re trying to impart?
Map view
For almost anything that can be seen on a map or is best explained in the context of a map, we should… use a map! You can read more about the map here: https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/658178049
For example, showing the gate to this farm (on the right side) in relation to the rest of the farm locations is much, much more helpful for the user than displaying either a picture of the gate or a description of the gate in a collection of other pictures or descriptions.
Tile view
Tile views are best employed when an image of the “thing” will more quickly convey information about the thing and allow the user to differentiate and make a selection than showing it on a map or describing it in words. Images have the added benefit of being easily understood across different languages and contexts.
Since the above tile view only shows crops, we could describe it as a homogenous tile view.
A quick note: being able to show an image is not an invitation to eschew text completely! As shown in the image above, we still need to give additional context with other approaches as necessary.
List view
List views are best employed when a “thing” can’t be easily explained or distinguished from its' peers without some verbiage. An example of this pattern in practice is the switch farm interface:
In this case, what may help a user distinguish the “right” farm to access from a list could differ from farm to farm or user to user. In some cases, the name of the farm, the farm owner, or the address could be useful in making this distinction. Without knowing the geographical distribution of the farms on the list, we can’t say a map view is a good choice. Similarly, the system doesn’t have a single image that uniquely identifies farms against each other.
Since the above list view only shows farms, we could describe it as a homogenous list view.
A note on List Views: It is not acceptable to just throw a wall of text at the user. Any sufficiently large list view needs to come with additional usability considerations, such as a search capability, filter capability, a default or recommended selection, or a mix of all of these.
A note on homogenous and heterogenous collection views
There will be times when we want to show a collection of “things” that aren’t the same type (homogenous) in the same context. For example, when creating a task I should be able to either target a location (best displayed on a map) or a crop (best displayed with tiles). In these cases, we’ll need to employ some sort of mechanism to simplify the interaction. For example, a search interface that clearly defines which collection a “thing” comes from or a toggle to choose one or the other may work. However, this will be highly contextual to the situation.
Individual view
An individual view is a page dedicated to a particular “thing”. Individual views come in two varieties:
Detail view
Hybrid view
Detail view
Detail views are pages dedicated to a particular “thing” without any context conveying its' relationship to other entities. Detail views are a way to display all of the attributes of a particular “thing” in isolation. Detail views are best employed where:
The attributes of the “thing” are sufficient to identify or assess it on a standalone basis or…
Where the detail view is part of a larger flow that lends the user context to it’s existence
Furthermore, almost every time a user is creating, editing, or deleting a “thing” we’ll use a detail view. Consider the alternative: if we showed additional relationships related to the “thing”, the user might be confused as to what “thing” they’re creating, editing, or deleting.
To illustrate Case 1, we can think about the “edit user” screen. This screen shows only information about the user, because much of the context can be inferred (e.g. this user belongs to the farm I’m currently accessing) or is shown on the page (e.g. their role is “Farm Owner”). This screen also satisfies the “editing” use case, as any edits made here would only effect this particular user.
To illustrate Case 2, we can look at the “Add a point” flow.
The fourth screen of this flow is a Detail view. However, the screens immediately proceeding it give the user all the context they need in order to appropriately define this point within the wider context of the farm map. This example also satisfies the “create” use case described above.
Hybrid view
Hybrid views are pages dedicated to a particular “thing” that also show that things' relationship to other entities. They are a way to allow a user to view a “thing” and the important relationships for that thing in one place. Hybrid views are best employed where:
The “thing” can be thought of as a container, where the contents are as important or more important than the attributes of the container or…
Most of the actions a user performs on the “thing” actually take place on its' related entities
The most obvious example of a hybrid view is the Field hybrid view.
In the case of Fields, the attributes that describe the field itself (e.g. name, area, perimeter, etc.) are less important and less dynamic than the relationships that field has to other entities on the farm, such as crops and tasks. Most of the time when a user is looking at a field, they’re actually looking to understand what’s happening on the field - the tasks tab - or what’s growing in the field - the crops tab. Only rarely will the user be interested in viewing or modifying the attributes of field itself.
Also notice that there’s a different view for tasks and crops. The hybrid view determines that there is a mechanism (tabs) to differentiate from the “thing” itself and it’s relationships, but doesn’t define the view of the related entities. Since the hybrid view for fields has a related list view for tasks and a related tile view for crops, we could describe this as a heterogenous hybrid view.