Introducing Things: What your application is about

Thing Management

Things are the foundational elements of your application when using Kleeen. At first, this may seem confusing because the term Things is so vague in a technical tool. That is intentional because they can literally be anything that needs to be in a front-end application used for your business.

Think as if you were writing a use case about your subject, Things will be the subject of that sentence. In the screenshot below you will see how things are used as you build your interface to define Workflows based on user stories.

 

Getting Started with Things

You will need to define at least one Thing before you can move forward with designing a Workflow and launching a prototype. To get started, you will not need to define all the Things your software is about, but it is a good idea to create a logical grouping of Things upfront.

For example, in an application that is managing customer relationships, the first group of things you may want to build is the model of contact data for customers. You could then progress to other groupings, like order management or account ownership.  

As you build an application, you can add more Things at any time in the process. You can also refine things, change relationships and delete unnecessary ones as needed.

Remember you don’t have to get your Thing model perfect before moving forward and authoring is an iterative process best handled in logical sprints.

To get started with things select Thing Manager from the Kleeen menu.

The Relationship Between Things

The relationship between things is defined as you build your application model. This relationship is presented visually in the Thing views of the Kleeen.

These views will look familiar to users that build relational databases, but the concept is not a straight translation between the two concepts. In databases, these relationships are very prescriptive of data relationships while in the Kleeen these relationships are much more descriptive.

It may help to think of the application model in Kleeen as a semantic, or concept based, relationship more than relational. In this type of model, you are describing the meaning of Things more than prescribing a relationship. Using a conceptual data model to describe the relationship and types of Things the association is less restrictive than in a relational database. The model’s purpose is to describe the meaning of its objects.

As you build out a Workflow for your application these relationships will let you include the data needed based on the Things used to build that Workflow. If while building a workflow you discover that related data is not available because of a missing relationship, you can simply return to the Thing Manager and add that relationship or a Thing that defines the relationship.

It is also important to remember that you will not necessarily define data you display to users in the front-end application the same way that you do in the back end. For example, you may store an employee’s first and last name in the back end normalized in different fields with history but in the front end show it as one field with the most current name for simplicity. This will be defined by the JSON response you send the front end agnostic to how it is stored in the back end.

Examples of Relationships

If you are building an application to manage a fleet of vehicles, you will have Things to describe a vehicle such as: id, type, and status. Building a widget to describe the fleet you may create a Workflow that displays the number of vehicles and their availability(Available/Unavailable). This would require a Thing to identify the vehicle, probably a unique identifier like VIN or a company asset number, and a Thing for status. This relationship will likely be defined as many statuses for every vehicle and include a timestamp for that status. Using this data a number of visualizations can be built to show the number of vehicles by their status or time in that status, etc. Below are some examples of the Things in Kanban view and what a Status would look like.

In this same application, you may have built a model to describe drivers of vehicles as well. When building a dashboard of drivers if you haven’t related drivers to the usage of vehicles you will be restricted from showing this data. One fix to this problem would be to build a Thing called In Use and make it a time series Thing. By giving this Thing sample data like Checked Out, Reserved, and Checked In the time series will provide timestamps for the events around vehicle usage. Now the In Use Thing can be given a Has relationship of Driver and Vehicle so that vehicle use can be visualized.

It is important to remember that relationships between Things remain editable as you build your application and can be modified by adding relationships between existing Things or using a new Thing to connect them.

Views of Things

There are three main views of Things in the Kleeen, each one displays the objects used in your application in a slightly different way. You will be able to create, view, modify, delete, and link your things using each view as needed. Each view is designed to give you a unique view of the Things in your application to work effectively in a style that suits you.

Using the dropdown menu at the top of the screen you can quickly switch between the Kanban, Thing Overview, and Thing List.

The Add New Thing button will add a new thing to the view you are using without changing the view.

Kanban View of Things

The Kanban view is designed to help you work in an Agile fashion. By building Things using Kanban cards you can quickly sketch out the basic concepts of your application and their relationships. From the foundations, you create with the first few Things you can build as complex of a model as needed. One of the main advantages of this view is the ability to see relationships Things have with each other.

Thing Overview

This view is a graphical representation of the things in your application model, the data types, and how they are related in the front end. While this looks similar to a database relationship model, this view will not usually match your database schema exactly.

 

Understanding the Model

Blue circles represent Things identified by their names. Blue arrows will show the connection of things. The weight of the connecting blue line represents the type of relationship things have.

The red circles represent the da you may see seemingly unrelated Things connected by the shared datatypes.

Hovering over the connecting lines in the model will show the definition of the relationship.

 

Modifying and Adding Things

A single click on a Thing will give you the option to view and modify the details of that Thing or Create an attribute to that Thing.

When creating an attribute you can select Something New to create a new Thing or an existing Thing to build a relationship between them.

Thing Manager

This is a list view of the Things in your application. It provides useful insight into Thing relationships and abilities.

Column	Definition
Thing	The name of the Thing
Is A	The type of thing
Count Of Has	The number of related Things
Count Of Can	The number of actions assigned to a thing

By clicking on the Thing’s name you can access the screen to modify that thing.

Deleting a Thing

Things can only be deleted from the Thing List and only if they have had their relationships removed and are not in any Workflows^[b]. This is a safety measure to prevent corrupting your prototype and make it unbuildable.

To delete a Thing select it in the Thing Manager view and the trash can icon will be available. Before deleting a Thing you will be prompted to confirm the action.

If you have any questions about this, please contact [e-mail] and we will be happy to answer them for you.