I recently had a discussion with a user that was really eye-opening to me in terms of how we could improve the UX (user experience). It made me realize how much of our UX decisions have been guided by our data model and the information hierarchy it follows. While I firmly believe that that data model is correct, I also believe that it may be a flawed assumption that that data should be displayed using a similarly hierarchical model. For instance, our core data entities are logs, assets and areas, and those entities break down into different types, and those types with different fields, etc. Thatâs fine, but then accordingly, when we lay out the UI in farmOS, we comprise our main menu of those three entities, logs, assets and areas, and those menusâ dropdowns break down by entity type, etc, etc.
The problem is that that hierarchical, data-oriented kind of design doesnât actually corresponds to most users expectations. Speaking with the same farmer, I realized that when sheâs looking for a particular seeding log, her mind doesnât start by thinking what kind of log she wants, sheâs just thinking that she wants something related to seeding and planting, and so she actually looks first under assets, pulls up the list of planting assets, selects the asset sheâs concerned with, then the appropriate seeding log that records the event she wants to review. I totally sympathize with this because it conforms more closely to her workflow then the data model itself does. Again, I donât think this means the data model itself is flawed, but merely that it should not be our guide to how we design the UX.
I think part of what is responsible here is that, while we have established a good hierarchical structure of data entities, there are also crucial relationships in the data that cut across those entities, in a more graph-like manner, such as the relationship between a planting asset and a seeding log, ie, the asset is the thing being planted that is the event that the log records. That connectionâthe edge, so-to-speak, between the nodesâis the aspect of the data that really resonates with the user, more than the entities themselves (ie, the nodes). So far, I think weâve tried to minimize the confusion these relationships tend to cause by distinguishing how we name assets and logs, eg, we name the asset a âplantingâ and the log a âseedingâ or âtransplantingâ, but I wonder if instead we should embrace these relationships, in order to present a more cohesive UX. Perhaps some sort of âmeta-typesâ or something that cross-cuts assets and logs (categories perhaps?), so that in the end we could present a menu to the user thatâs structured more like this:
| Plantings | Inputs | Maintenance | etc |
|---|---|---|---|
| Seeding Logs | Input Logs | Maintenance Logs | |
| Transplanting Logs | Input Assets | Equipment Assets | |
| Planting Assets |
I think thatâs still far from perfect, but seems more like a step in the right direction. I think this kind of approach would take a lot of user research to really get it right.
I should note too that @mstenta has suggested that we still present an option to view ârawâ records from somewhere, like a hamburger menu or something, and I think that is still a great idea for power users who have come to really intuit the farmOS data model and want to navigate according to that.
Anyway, Iâve rambled long enough, curious what others think.
Perhaps that becomes our long-term goal, after incorporating the component library into farmOS, that could gradually lead to the current UI being relegated to a sort of admin view.
Maybe some Reports should live under the higher-level asset menu. Thought being that the act of viewing a Report might be a part of a âworkflowâ if the results frequently lead to another user action.
) Initially I thought goals of this thread were for discussing alternative âcoreâ ways of viewing records (eg in a Graph-like UX) - but Iâm curious how generalized this can be. Obviously keeping raw-record input is one solution - but could mini âappsâ cover specific use cases that would benefit from a reactive UI, but add features that the core generalized UI canât support?
