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

**URL:** https://farmos.discourse.group/t/design-improvements-the-hierarchical-data-model-vs-the-graph-like-ux/223
**Category:** Development
**Created:** [February 14, 2020, 12:03am UTC](https://farmos.discourse.group/t/design-improvements-the-hierarchical-data-model-vs-the-graph-like-ux/223 "2020-02-14T00:03:13Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![jgaehring](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/jgaehring/32/927_2.png) [@jgaehring](https://farmos.discourse.group/u/jgaehring)
#### Post date: [February 16, 2020, 1:05am UTC](https://farmos.discourse.group/t/design-improvements-the-hierarchical-data-model-vs-the-graph-like-ux/223/6 "2020-02-16T01:05:32Z")

</div>

> [@Lars](#):
>
> 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).

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.

> [@mstenta](#):
>
> 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).

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.

> [@mstenta](#):
>
> 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.

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.

> [@mstenta](#):
>
> 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.

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… 🤔 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.

---

_[View the full topic](https://farmos.discourse.group/t/design-improvements-the-hierarchical-data-model-vs-the-graph-like-ux/223)._