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?
