"Universal" App implementation: OR("on the right track","barking up the wrong tree")?

Troubleshooting
1

I’m designing my first app for work. It will be used by several internal service departments within the company; the first will be maintenance, followed closely by IT. Other departments are pending.

My initial design draft was OK but not very flexible for multi-dept use; then I saw the “Universal” Inspection app by @MultiTech_Visions and thought that it may provide a better and more universal platform to be used by any of our service departments.

I’d like to get some feedback on my revised draft design (see below) and whether or not I’m on the right track or literally barking up the wrong tree.

---------My riff of the Universal App--------
An Entity Group groups similar Entities (tangible or intangible) and is associated with multiple Activities (corrective, preventative, training, procurement, administrative, safety, etc…) These Activities are tailored to the Entity Group through the context of referenced Categories/Sub-Categories, ensuring relevance and applicability.

An Entity, belonging to an Entity Group, is the subject of multiple Work Logs, which document the execution of Work (see below).

The Activity Catalog groups series of Activity Steps/Stages, ordered to define a coherent process/workflow. Steps/Stages may have expected completion times and escalations based on a priority matrix.

Activity Steps/Stages comprise a group of Activity Items/Elements which are required or situational data-points/actions to be completed before moving to the next Step/Stage. An Activity Step/Stage could be the execution of another Activity (e.g., “Diagnostics” or “Procurement” Activity within a “Corrective Action” Activity)

JTOs (Jobs/Tickets/Operations) are instances of Activities; JTOs can be created by users, techs, or via automation depending on the associated Activity. JTOs may have triaged priority which will set the time limits for the Steps/Stages. The triggering of another Activity within a JTO creates a “sub-JTO” assigned to the same/different Tech and may or may not require full completion of the sub-JTO before progressing.

The Work Log reflects the execution of Work, containing records of Work.
Work logs the resource utilization (time & materials) and completed data-points/actions of the instance of Activity Items/Elements within a JTO.

Other apps/tables such as Inventory, Vendors, Users, Techs, etc… would round out the “suite” which is tentatively being named “SOS” (Service Operations Suite).

I apprecaite any suggestions/feedback you can provide.
Thanks!

1 Like
2

Hey @Patrick

First off: welcome to the community! :raised_hands::tada: It’s always nice to see new people in here. :slight_smile:

In response to your formula:

  • OR(“on the right track”,”barking up the wrong tree”)

Both ¯\_(ツ)_/¯

“on the right track”

  • You’re on the right track with your data structure
  • Though you’ll eventually need more tables than this; at the very least you’ll need/want some helper tables, to hold things like categories, types, dropdown values, etc.
    • These help with scaling and ease of flexibility.

From what I’m getting, it looks like you’ve included an additional layer inside the Activity layer (what I called Catalogue) for the stages of the activity.

  • Main Layer: Activity
    • 2nd Layer: Groups/Stages
      • 3rd Layer: Actual activities to record

This will work nicely if you’ve got multi-stage data points to capture, which it looks like you do.

Even nicer is the fact that having a record for each stage will allow you some space to work during that stage.

  • By this I mean you’ll be able to build a UX around the stages, with “remaining steps” and things. :muscle: This will make these multi-stage activities much easier to keep straight.
    • So you might have “Remaining Stages” on the parent level, and “Remaining Steps” on the Stages level, giving your users an easy way of seeing what’s left to be done.

“barking up the wrong tree”

Okay, I included this as the answer because you’re not going to want to necessarily use the Universal App as your actual starting point. This app has a lot of peculiararities that you would not do in a normal building scenario. The reason the app is so different, is because it’s not made for one thing… it’s made for you to put what you want inside it, and it works with that.

  • But this means that traditional parent-child references aren’t built normally
  • Many-to-many relationships between helper tables aren’t there
  • A lot of the necessary “connective tissue” that makes an app work well, won’t be there.
    • This means that, down stream, you’ll face more difficulties due to this configuration.
What is the "nearly universal" app good for then?

The nearly universal app is really good for a situation where you need a quick way to make a todo list of sorts, when you need a way (on the fly) to put together something to keep track of something.

  • When I say “on the fly” I really mean that.
    • As in: I’m in the field (literally a farm field) and we decide we want to start keeping track of something. We can pull this app out, fill in some stuff real quick, and then we’re off.
    • Literally in minutes we can have something in place, that I can then have my people start using. (Very helpful)

Why not use it anyways?
You absolutely can! The difficulty you’ll run into is the fact that each data point is it’s own record, so the data is in a “vertical” format - as opposed to a “horizontal” format when you have a traditional table, with columns for the data points.

  • So because the data is in this format, it makes it much more difficult for certain computations
    • Then again, it also makes other computations much easier. :crazy_face:

But generally: the spirit of this app is

“I need to do something on the fly real quick”

What should I do then?

This app has helped you build out a basic data schema, now it’s time to take this and build your own tables specific for each purpose.

  • Entity tables (for the people, places, things)
  • Intent tables (for the actions, verbs, events you’re recording)
  • Helper tables (holding categories, types, dropdown options, etc.)

Once you start putting together the real tables, you’ll start to see the web of how things connect together.

With the appropriate reference connections between all the tables, you’ll be able to accomplish incredibly complex stuff with relative ease (and with minimal burden on the system).

You’ve got a great start mate!