Information architecture (IA) is the structural design of shared information environments.
In this document:
In APS applications, IA contains compiled data collected and built in the previous design steps. In accordance with the MVC concepts, data models are defined in the application backend, that is in its provisioning logic, whereas the user interface (UI) part is implemented in the application frontend, that is in the presentation logic.
IA design contains the following steps:
To aid in design, architects can use 3rd party modeling software specially developed for IA.
IA should define the following IA systems:
Taking the above into account, there are several basic steps in organizing IA for an APS application:
Taxonomy is the science and practice of classification. In information architecture, a taxonomy is a hierarchical organization of content categories, using a specific, carefully designed set of descriptive terms.
In this section, we will touch some aspects of taxonomy.
To be consistent and clear for users, the application UI should have a consistent set of terms and names in the form of a controlled vocabulary that must become a fundamental element used throughout the application UI and documentation.
The template for the controlled vocabulary may look as follows:
Name and aliases | Abbreviation | Comments (optional) |
---|---|---|
Virtual private server
Server
|
VPS | - |
Memory
Random access memory
|
RAM | Measured in MB |
… | … | … |
In the platform, there are the following locations for embedding application UI.
UI structure must be presented by a diagram containing screens with navigation links between them.
Chunk the UI content into logical units with a consistent modular structure and outline the UI content as hierarchical trees. This influences the static structure of navigation trees. In control panels, usually it is not necessary to have a tree with too many levels. Usually up to 3 level hierarchy is quite sufficient. Keep the following principles:
APS allows you to link screens in a sequence or in a hierarchy. Combination of both types is allowed as demonstrated in the following diagram.
Such a diagram contains all application screens used in the particular location.
There are some techniques for implementing this design step such as card sorting and whiteboard sessions.
For each screen, implemented later as a view on the development phase, define its content that users will view or configure along with navigation controls to go to other screens.
The outcome is a table with UI entities for each screen.
Entity | Type | Default value | Description |
---|---|---|---|
Purpose | String | “This is a 1st view in the VPS creation wizard” | Not visible anywhere - just for the developer |
Title | String | “Virtual private servers” | Title on top of the screen |
Unique ID | String | “servers” | Declared in meta and used for navigation |
Offer link | Link | “offer” | Required link with an offer used by the VPS |
Host name | String | “” | The name of a VPS |
… | … | … | … |
Next | Navigation control | N/a | Navigates to the second step of the wizard |
For each APS type declared in the resource model, define the following data in accordance with the Type Definition document.
In the Offer Management demo project, the APS application resource model looks as follows.
The obtained service allows the customer to manage the structures and properties of a VPS in accordance with this diagram:
From this input data, you can compile the following tables that describe the information architecture
of the /offer-mgmt/vps
APS type (not all properties are presented below).
Type name | Description | Type ID |
---|---|---|
Resource |
Mandatory implementation of the core resource | http://aps-standard.org/types/core/resource/1.0 |
Name | Relation Type | Related APS type | Backward relation | Description |
---|---|---|---|---|
context |
required, singular | /offer-mgmt/context | vpses |
Allows the application executables to find all VPSes in the subscription through the management context |
offer |
required, singular | /offer-mgmt/offer | vpses |
Needed to get limitations specified by the related offer |
Property | Type | Description |
---|---|---|
name |
String | VPS name |
description |
String | Detailed description of the VPS |
state |
Boolean | VPS state, either stopped or running |
cpunumber |
Integer | Number of CPU cores assigned to the VPS |
ram |
Integer | RAM space allocated to the VPS |
disk |
Integer | Disk space allocated to the VPS |
cpu |
Structure | Contains the cpunumber property to specify the CPU power |
hardware |
Structure | Contains ram , cpu , and disk properties to specify the hardware configuration of the VPS |
Roger should identify all needed operations by analyzing user scenarios and present them all in a table similar to the following:
Name | Arguments | CRUD or custom | Description |
---|---|---|---|
provision |
- |
CRUD | Provisions a VPS on the application side using its native API.
No arguments are needed, since the APS controller sends all VPS properties
in the body of the REST request.
|