×
Back to book

Identifying Users

A guide on how to identify potential uses of the Users behaviour.

We have found that there is often a knowledge gap between theoretically knowing what a behaviour does, and actually recognising its potential use in an application. It is the aim of this article to help you recognise and identify uses of the Users behaviour.

About Users

Before you begin, it is important that you have an understanding of the basics of the Users behaviour so that you know it's capabilities and limitations. For developers, this also means having an understanding of the technical aspects of your functionality so that you know what it is and is not capable of achieving with the help of custom code.

Since the focus of this article is on identifying the User behaviour, not teaching you about it, make sure you read the User Behaviour Overview article if you haven't already. If it has been awhile, make sure you read over it once more to get a refresher.

It is particularly important that you focus on the content at the top of the article, which covers what the behaviour excels at, and what it is ill-suited for. For techies, we recommend that you also start exploring the code behind how it works. Whether you just fiddle with the code in a dummy application or complete the User Behaviour qualification (coming soon), it is important that you have a level of familiarity.

Identifying Potential Users

When it comes to identifying this particular behaviour, it is relatively simple, and almost every application will use it. In fact, it is currently a requirement to use it in the bot's applications, since you need it to be able to have administrative access to the app and its data. Essentially, Users is required any time you need some form of login or account registration on your site.

However, don't mistake the registering of an email address for a newsletter subscription as the same as registering with the User behaviour. Users is only required when there is a need for logging in or controlling user access levels, not simply for getting a list of emails (have a read of the Forms Behaviour Identification if that is what you want).

Examples of Users

Depending on how you use it and how much custom code you want to write, it can get a simple as having a basic login/registration form to control user access, to as complex as using Active Directory to control user accounts and then only showing certain parts fo the page depending upon what group the user belongs to.

Login / Registration / Forgotten Password

Consider a social media site like Facebook; excluding the administrative login and backend which undoubtedly exists, everyone on the site shares the same login page. From that login page, users can login, new users can register an account, and existing users can also reset their forgotten password.

Controlled Access

In more complex application, the User behaviour can be used to control who has access to certain pages. Have you even been on a site and when you click on a link it says that you have to login before you can proceed? That is an example of controlled access. Likewise, if you try to edit something and it says that you don't have permission to do that.

In Codebots, this is controlled in the security diagram. For every use of user behaviour, you can dictate which pages and entities users of that type can view or manipulate.

Tailored Views

If we take it one level deeper, instead of restricting access to certain pages or interactions, we can use the behaviour to instead change how something is displayed based upon who is viewing it. On a Dashboard for example, a sales team member may see their sales for the quarter. On the same page, their manager may see the same graph but instead of showing an individual's stats, it displays them for every team member combined.

You can use the behaviour to check the user's access level and alter what is displayed to suit their needs.