Design Improvements: the Hierarchical Data Model vs the Graph-like UX

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.

6 Likes

This is pretty exciting topic! I suspect your observation is true that the ways most users think about or need to work with their data will often be different than the underlying farmOS data model. (Without necessarily making the farmOS data model a bad choice.)

To provide another example of that, I can share some small samples of records my folks have kept in the past few years.

In my opinion, the key take-away from these is that - at least for their use-case - there is a need to make the same kind of record/observation/measurement with similar fields many times associated with different assets/plantings/etc. A tabular format is conducive to that, but clicking/tapping around between different pages between capturing each record isn’t.

2 Likes

Oh these records are awesome! Thanks for sharing! It’s always so insightful to see what a farmer does with a blank canvas, really reveals a lot about their thought process.

Yea, that would be the ultimate prize if we can craft a method of data capture that reduces the amount of repetition there can be in that process. I think the data model we have is actually very helpful in that, because it creates a way of creating specific entities and associating them with other entities that share some kind of relationship. But the job is only half done if those relationships cannot be easily surfaced to the user within the UI, ultimately. I’m confident we’re getting there though!

1 Like

This is a really great post that points to a similar “problem” that I mentioned in my ‘general setup’ post General setup - using logs, groups and tags templates

As a farmer interested but not capable in real programming I understand why you need the structure that farmOS uses. However, it feels like one has to try to develop a tagging system for them self which might hinder farmers from getting into farmOS and staying with it (this open system can also be a good thing since it enables lots of use cases).
For example the group membership and linage for plantings are still a bit confusing to me. I use them but I am not sure if its really needed. Somehow a lot of time is spend with tagging since you never know how you might want to structure something in the future. Maybe I tag too much but if there is a option to tag I try to add some information.
It might be a good idea if less structure is displayed or tagging is done automatically. For example if some machine purchase is added it adds the machine to the equipment side or if equipment is added with a price and date of purchase it adds it to the purchases.

Maybe it would make sense to show one crop/ bed… recording ‘log’ that has all information in it.

Cabbage Bed 123

  • Seeding: Date, Amount …

  • Transplant: Date, Density…

  • Fertilizer: Date, Type, Nutrient amounts

  • Harvest: Date, Amount, Calculated return, Calculated nutrient export :wink:

Well it looks like it might be a bit much information but it would be nicer than jumping between logs to get to the information that’s needed. I agree that having the option to see and edit the ‘raw’ data is very important. However, some layer on top with the main/ basic information presented might be saving time for data input and could be helpful for quick data checks.
Another option would be to auto-generate one ‘log’ from all related logs that contains just the main information with links to drill down to the detailed logs.

2 Likes

So glad to see this conversation happening! It’s exactly the type of natural UI evolution I hoped would take place as real-world needs and use-cases bubble up.

I think there are a LOT of ways to go about this, and we are already experimenting with a few of them: quick forms (for quick data entry), dashboards (for organizing access to conceptually related records), reports (for aggregating and summarizing specific things), plans (for organizing specific assets, areas, and logs around a specific purpose/prescriptive workflow).

@jgaehring specifically talked in chat about the main menu bar (and that seems to be what really kicked off this forum topic). One idea I have been toying with is to take the existing menu items, which represent the raw record types (Areas, Assets, Logs, People), and putting them into a sub-menu called “Records”. Then we could start to build out the main menu with other useful things that are currently scattered about in odd places, like the dashboard tabs, reports, quick forms, etc. It makes sense for those to be on the top-level menu, and not as tabs on the dashboard, in my opinion. It seems like the next logical step, and is something we could do right now.

Beyond that, I’m also really excited about the ideas we’ve been discussing in Field Kit around Field Modules. But to take it a bit further: I’m really interested in thinking about how we can take the same approach in farmOS itself, perhaps by integrating Field Kit directly into the main farmOS UI. This would allow us to leverage the full frontend power of Vue.js that we’re using in Field Kit on the server as well.

We’ve so far been making a distinction by saying “Field Kit is for quick data entry in the field” and “farmOS (the server UI) is for full data management, planning, etc”. But I think we can break down that distinction a little bit, and think about how we can use some of the nice frontend “app” ideas developing in the form of Field Modules for the farmOS UI as well.

I can imagine a set of “server-side” Field Modules that are available as mini apps that combine a lot of the needs currently being served by quick forms, reports, and plans.

And all the while, we can still have the “Records” menu item which has the raw lists of areas, assets, and logs - so you can always see EXACTLY what’s going on in the data model itself.

2 Likes

Yes, I think these kinds of tags are similar to what I was referring to as “meta-types”, in other words, relationships or connections between the core entities that bring additional semantic value to the entities. I’d love to hear more examples of the sorts of tags you would find most useful.

I should familiarize myself more with some of the dashboards and reports you’re working on. Those could be a good place to experiment with new UX ideas, before possibly integrating them into more central farmOS layouts.

I still think the best way to approach this would be to start using the component library I’m building up for use in Field Modules, but in farmOS itself. I think that would be a good way to introduce some of the design ideas to farmOS and gradually move towards a more integrated look & feel between farmOS and Field Kit.

This just makes me think… what if we had an alternative “core” library for farmOS itself, the way that Field Kit does, but that would accept the same Field Modules that Field Kit does? So instead of the “core” library being the app shell of a SPA, the way it is for Field Kit, it could be a library that loads the modules in from the server and integrates them with the regular farmOS UI. Does that make sense? I can definitely see some interesting possibilities there… :thinking: 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.

1 Like

Great ideas here! @jgaehring I really like the framing for this as looking beyond a “hierarchical data-oriented design” !

I agree, this seems like a logical next step!

I’m curious how all this might fit into the “Farm Setup” process (mentioned in @Lars other issue!) It seems like there will also be a need to configure which of these additional UI workflows are displayed to users. In general, I think this is the idea behind the “Farm Setup Wizard” - but it should certainly be connected to these UI design considerations!

Something that comes to mind: how to organize these “non-hierarchical” views. For example, continuing to put “Reports” and “Plans” under those menus makes sense - but will we need another “workflow” menu for these UI “apps” ? Or can all of the “Planting workflows” live in a sub-menu under Plantings, “Animal Workflows” under animals, etc… quick sketch of a menu: (edited to a table)

Plantings Animals Reports Plans Records
Create a planting View Grazing Map Analyze Field Inputs Forestry Plan Areas
Add field inputs Manage dairy inputs Average animal weights Grazing Plan Assets
View successions Soil Test Plan Logs
Schedule Harvests People

Doing this just made me think :slight_smile: 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.

In general, I’m curious how customizable this menu structure could and should be?

I think this concept makes sense, but I’m curious about the technicalities behind it! Which is perhaps a larger technical question (for another post) of how to get Vue.js into the Drupal UI - can it be rendered on the server and use the Drupal module system to integrate our frontend “apps” into the UI? Or are we embedding a SPA? (if thats possible? haha)

While writing this, and generally throughout this thread, I couldn’t decide on one term for the following - “non-hierarchical views”, “UI workflows”, frontend “apps”, “mini apps”, etc… Which raises a question…

  • Aside from some core views in farmOS, are these really mini “apps”?
  • Could they be presented to the user as “apps” they can enable/install via the Farm Setup Wizard?
  • Might also be a good way for community to contribute 3rd party apps??
  • Also an extension of the idea for Field Kit modules being “Apps” you can install on the server. So an app could provide Desktop Features, and/or Mobile Features
  • To go a step further, a 3rd party (I’m thinking Pasture Map or CFT here) could provide a farmOS app that:
    1. Adds OAuth Client for integration with 3rd party services
    2. Admin views for configuring integration, desktop analytic features
    3. Mobile views for inputting data, offline use cases, etc.

(@jgaehring your thoughts on loading modules from the server, and @mstenta’s mention of “mini-apps” led me down this thought process :smiley:) 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?

  • eg an app requires that records are in the “Organic” category for it to provide some Organic Cert reports
  • or a Soil Testing lab could provide additional insights with their soil tests via a UI in farmOS, but only on soil tests logs that are created from their lab
1 Like

Great thoughts, @paul121!

I guess I’m sort of thinking of these relationships between entities (or edges between nodes) as just loosely described collections of similar user stories. I hadn’t really thought of them as being so self-contained as to be their own “apps”, per se, but rather a set of visual and verbal cues that guide the user to the proper place, whether it’s a log, or an asset, etc. Perhaps “pathways” would be an appropriate term?

I guess a separate discussion is the incorporation of Field Modules into farmOS itself, because I do see those more as little micro-apps in their own right (I’ve alternatively referred to them as microclients as well, and there is a general concept of micro-frontends emerging these days). I guess I’d still be inclined to think of those as nodes in the graph, which could be placed on a certain pathway(s) as well.

As far as the technical requirements go, yes, there will be many, but getting Vue itself into Drupal shouldn’t be much of a hurdle. I think the real question is along what lines do we want to carve up Field Kit into chunks to pull into farmOS? The two most obvious options are the Field Modules themselves, and the individual Vue components. I think we can’t go wrong using the individual components, but there are some major questions we have to consider when it comes pulling in FM’s: how do their predefined routes work? do put all those routes behind some namespace for all FM’s? what does farmOS do with the drawer and dashboard components that each FM provides? does each field module need to supply something similar for the farmOS UI? how do Field Modules get their data within farmOS? do they still rely on AJAX? will we want offline capability from within farmOS? etc, etc…

Honestly, I don’t know that I want to start guessing until we have some more concrete use cases, and I think those will start to emerge if for the time being we just start with individual Vue components, then build our way up from there.

2 Likes

Ah okay! Yea, I agree that wouldn’t be an “app” itself. I guess I was thinking about what happens once the “pathways” are put together and bubbled up to higher menu structure. Seems like there would be a core set of pathways that replace the current data model-based approach of viewing & creating records. One of which might roughly resemble something like the Planting “quick-form” and the various record types it handles?

Other workflows that are more specific might not fit a general model, which is where they could be added as part of an “app”. I think that does fit more into a separate discussion of Field Modules into farmOS though

2 Likes

Hey folks, I’m new to the forum but have been using FarmOS on a crop/livestock operation for over a year. We recently had a conversation with @mstenta about ways to enhance FarmOS’s data query capacity and, while I think there are meaningful opportunities there, I’m also realizing that some of our hurdles are purely UI-related. As I become more fluid with searching logs vs. assets vs. quantity reports (and respective CSV files) to pull targeted data, I’m seeing the ways in which a lot of the capacity I’m looking for is already built in. All this to say @jgaehring that I think you’ve tapped into something important. And it would certainly help the average farmer/landowner if the menu bar matched the terminology we more commonly use.

In case it’s helpful to have one more example, here’s the first layer of folders we choose between when archiving documents:

  1. Plants / Crops
  2. Livestock
  3. Marketing
  4. Environment (Soils / Water / Wildlife)
  5. Equipment / Infrastructure
  6. Maps
  7. Research
  8. Photo / Video
  9. Misc.

Thanks for stoking a good conversation!

2 Likes

That is really helpful to see how you break it down!

I’d love to see more farmers share what kinds of categories are most useful when organizing their farm’s operations. I imagine there’s a lot of overlap between different farms, though I’m sure no “one-size-fits-all” solution. I wonder if we could have some way of customizing pathways like that, but still keep them somewhat standard?

In any event, great to see what works for your farm, @gregoru2, it’s an excellent start!

1 Like

Cross-posting this on the GOAT/OpenTEAM forum:

1 Like

Just signed up for a trial of FarmOS this week and I’m trying to learn as much as possible - such a great concept and I’m really hoping to use it for our farming business. I apologise if I my comments are not helpful becuase I don’t understand FarmOS well enough.

I have used a few farm management products and I think the best way of accessing records is:

  • for Field Kit: via the field. The main UI realestate is the farm map, Zoom/scroll, select the field/area, this leads to a list of records/logs for that field in the current season. Older seasons require more effort to get to on the mobile app version.

  • for the FarmOS web/desktop version, the same applies but you can get to the detail in the logs via multiple paths. There is room for more drop down lists (like the current design of FarmOS)

I guess my suggestion is, the better record keeping software products I’ve used concentrate on the field/plot/area as being the initial choice in the heirachy, then season (defaults to ‘current season’), then operation (plant, spray, fertilise, harvest etc), then individual logs of activities or observations.

2 Likes

This is great, @EdC! Your willingness to document your experiences even when you’re new to farmOS is actually one of the most helpful things anyone can contribute. It’s hard to get insight into that crucial moment of a user’s experience, when they’re trying to get up to speed and evaluate whether farmOS will work for their farm. Many thanks!

I like this approach. So far, the only maps we have in Field Kit are fairly deep into the UI and take several clicks to get to, and only after you’ve made some choices about what logs you want to look at etc. I could see potential for a Field Module that opens with a map as the primary means of navigation.

I think this reinforces what I’ve heard other users say here and elsewhere. :+1:

This all makes sense. I’d love to experiment with new navigation layouts that put this into practice to see what this kind of workflow would really look like.

I’m wondering, when you’re prompted to open up a mobile app to make or view a record, how often do you find yourself in close proximity to the actual location you want to make/view a record of?

1 Like

Thanks @jgaehring.

I’m wondering, when you’re prompted to open up a mobile app to make or view a record, how often do you find yourself in close proximity to the actual location you want to make/view a record of?

I would probably answer that with ‘often’. If it was easy enough to use the native location services in the phone and centre the map based on cuurent location then that would be a great feature, but, I dont think it is critical to do what some of the tractor manufacturors do and build in features where it will automatically populate heirachy details into logs based on whether you are sitting within a field boundary. Not sure if that is where you were angling with that question??

Partly, but also just trying to understand the conditions you’re working under. Thanks!

1 Like

All great ideas @EdC!

If it was easy enough to use the native location services in the phone and centre the map based on cuurent location then that would be a great feature

We DO have something LIKE this! Or a first step at least. :slight_smile:

In Field Kit, when you are editing a log, you can find nearby areas based on your device’s GPS. This is still relatively new (this winter), standing in my field and it will tell me which beds are nearby with good accuracy! I’m looking forward to using it this spring when the ground thaws. :slight_smile: