When building an application on CafeX there are a number of aspects that need to be considered in the design. Each of these items are described below.
Use Case
The use case of an application describes how it will be utilized by the users or systems that interact with it. In general the use case should call out:
- The Actors that make use of the system. This is the term for any external entity that interacts with the application, like other users or machines. Each actor can have 1 or more activities in the application.
- The “Activities” or “Processes” that make up the application. These are the actual tasks completed by the application on behalf of the Actors.
- For each activity and actor pair the inputs and outputs should be described. For example, what does the user provide to the search activity and what do they expect in return.
Defining an application with a user case helps scope the application and gives you a framework to work within.
Data Model
The data model of an application describes the data that is stored internally to the application. In CafeX, it's possible to build an application that only uses external data sources and hence doesn’t have a data model. However, in most cases the application will create and store additional data that augments that in the integrations.
When defining the data model you should consider the fields of data that are going to be stored, their types and how they are grouped together. With CafeX, the simplest model to use is the data table where the sets of data are modeled as spreadsheet like tables, a row is a record and a column is a field in that record. When modeling data as CafeX tables the data types include:
| Text | Textual content, e.g. names and descriptions |
| Number | Numeric values, e.g. age, cost |
| Date | A value to be treated and displayed as a date |
| Time | A value to be treated and displayed as a time |
| Checkbox | An indicator that the user can select |
| Multiple Choice | A value selected from a set of other values |
| URL | A link to a web page or other resource |
| Users | A list of system users |
| Assets | A file, link or other assets compatible with the CafeX platform. |
Integrations
The CafeX platform is designed to bring disparate sources of data and information together in a single active user focused application. When designing your application it is useful to determine the types of integrations you’ll be using and how you’re going to be able to connect them to your application.
Content Integrations
Content integrations link workspaces in the CafeX platform to content repositories such as Microsoft Sharepoint, Google Drive and Salesforce. These types of integrations make content available in these repositories available to users of the application by linking a user’s credentials for a remote service to the workspace.
Content integrations should be used when documents or records need to be viewed in their entirety within the application and constantly kept synchronized to the remote repository. Since content integrations require direct integration with the remote repository during the lifetime of the workspace they can be inconvenient to work with. However, you can alternatively upload the content manually directly into the workspace or use a Service Integration (described below) to automatically copy content from a remote system based on events.
A simple example of a content integration is providing documents from a Google Drive for viewing in an application. The user who has access to the documents can either manually or programmatically add the drive or individual document to the workspace as part of its assets list. Any user with access to the document will then be able to access those documents directly from the drive.
Service Integrations
Service integrations actively invoke remote systems or repositories to perform tasks. The results of these activities can be placed in the CafeX workspace either as raw data (in tables) or as assets. Service integrations connect CafeX applications via workflows to one or more of 100s of available integrations to services exposed by AWS, Microsoft, Google and other vendors. Workflows are triggered either by manual action in your application or by life cycle events on the workspace and its content.
Service integrations should be used when making use of remote APIs and applications as part of the events in your application. Service integrations are only invoked when a workflow is actioned and so must be re-invoked on any changes that might make changes to the results of the underlying service.
A simple example of a service integration is performing OCR (Optical Character Recognition) on a PDF document. A CafeX application can be configured such that when a document is uploaded by the user a workflow is invoked which in turn invokes AWS Textract. The result of this operation can then be stored as a text file in the application workspace making it possible to search and index a document that has been scanned in and uploaded.
User Interface
Most applications built on the CafeX platform have user interaction at their core and as such its key to design a user interface that supports their flows in the most efficient manner. CafeX provides a rich interface builder capabilities that allows you to drag and drop components into an application, connecting them to data sources, integrations and other platform capabilities all within the same tool.
User interface design is tightly linked to the use cases described above and is often an iterative process of design, followed by user testing, followed by refinement. The CafeX tooling makes refinement and re-imagining of your user interface an easy and natural process.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article