Can we dig deeper into the UX model?


[Admin: This content comes from the original mobile-friendly PDF.]

Implementing UX: Can we dig deeper into the UX model?

Of course! As I just mentioned, the model is used “to retrieve the data and trigger the business logic”. To be clear, this is where you can define your models in whatever way you see fit to fulfill your business needs. First, you must define your models before you can develop your views.

Each model can be made up of the following components:

  • Data Sources.
    • Child Data Sources.
    • Related Data Sources.
  • Data Source Fields.
  • Data Source Actions.

Before we look at some screenshots, here are some longer descriptions.

Component Description
Data Sources You can define data sources, child data sources, and related data sources to pull together all of the data needed for a model. A data source can be one of several types:

  • Business Object: This type identifies a single record. Traditional scenarios include persistent Create, Update, and Delete interactions.
  • Current User: This type identifies a single user. Traditional scenarios include language, time-zone, and date-time interactions.
  • In-Memory Business Object: This type stores data in a non-persistent scenario.
  • List: This type identifies a collection of values. Traditional scenarios include list-value interactions.
  • Query: This type identifies a collection of records. Traditional scenarios include table (grid), list, and search interactions.
  • Resource Calendar: This type identifies an array of calendar events for resources.
  • Security Information: This type delivers permission information of the current user to the UX application.
  • Smart Section: This type identifies an associated business record. Traditional scenarios include smart section interactions.
  • UOM: This type identifies a collection of units of measure. Traditional scenarios include area, length, and currency interactions.

If you have any questions about these data source types, feel free to check out the Application Building for the IBM TRIRIGA Application Platform 3 user guide.

Child Data Sources Child data sources are not required, but can also be powerful in shaping the user experience.

They are identical to other data sources, but they operate as children at a lower level beneath their parent data source. In fact, you can add several levels to build a hierarchy of data sources.

To illustrate, let’s say that you defined Spaces Query as your first-level data source. Then you might define Space BO and People Query as second-level child data sources, where the Space BO would be a related (contextual) data source for People Query. Lastly, you might also define Person BO as a third-level child data source of People Query.

  • Level 1 Data Source: Spaces Query with 2 children.
  • Level 2 Data Source: Space BO.
  • Level 2 Data Source: People Query with related Space BO and with 1 child.
  • Level 3 Data Source: Person BO.

With this hierarchy, a user can (1) see a list of spaces, (2) drill into a single space and see people assigned to that space, and (3) drill into a single person record. In our classic framework, this scenario could only be achieved by using many workflows to set variables. In our UX framework, we can achieve this with zero workflows!

Related Data Sources Related (or contextual) data sources are not required either. But they can be just as powerful in filtering the results of one data source, based on the context of another data source. Imagine that!

To illustrate, let’s say that you defined Work Task as one data source. Then you might define Responsible Organization as another data source with the related data source of Work Task. You might also define Manager of Organization as yet another data source with the related data source of Responsible Organization.

  • Data Source: Work Task.
  • Data Source: Responsible Organization with related Work Task.
  • Data Source: Manager of Organization with related Responsible Organization.
Data Source Fields Each data source must define at least one field. Each field corresponds to a field in the data source type.

To illustrate, let’s say that you defined a data source with a Business Object type. Then each field in your data source references a corresponding field in the business object.

Data Source Actions With data source actions, you define which business rules or workflow logic can be triggered by your data source.

For convenience, your actions can also be grouped together into action groups.

Here’s a basic diagram of the data source hierarchy and its relationships.

20160108b

Next, here’s an example of a blank model metadata form, where you define your model and add its data sources. In case you’re wondering, while new UX applications will use MVC views, the UX metadata will use traditional forms until our UX framework matures. So stay tuned!

20160108c

Here’s an example of a blank data source metadata form, where you define your data source and add its fields, actions, and child data sources.

20160108d

Continue reading →

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s