Welcome to “
TOSCA Editor - Web Application Wireframe Challenge”. In this challenge, we are looking for your help to come up with wireframes and user flows for TOSCA (Topology and Orchestration Specification for Cloud Applications) Editor. This will be a web-based application and you will be focused on creating the concepts for desktop devices only.
We need to see intuitive and easy to use "wireframe concepts" that will let us design and build the final user interfaces on the next stage of this project. Think about what are the best UI/UX practices when creating this wireframe.
This will be the first challenge of a very large project, so have in mind that your initial concepts will be the starting point and the basement for this project.
Round 1
Submit your initial wireframes for checkpoint review.
01 Dashboard
02 Blueprint Editor
Feel free to add any screens which are necessary to explain your concept.
Round 2
Submit your final wireframes plus checkpoint feedback implemented.
01 Dashboard
02 Blueprint Editor
03 Validation
Feel free to add any screens which are necessary to explain your concept.
About the Client:
The Client of this challenge is a multinational telecommunications company, currently, they are in the 4g spectrum, and will soon be moving to the 5g spectrum - so in that case
- Instances have to be dynamically brought up
- Services have to be catered to and
- Services have to be fulfilled by some physical entities.
So, in order to fulfill the above,
network topology need to give that flexibility of telling you what needs to be done.
Tosca has its own domain specific language and has its structure in YAML (YAML is a human-readable data serialization language. It is commonly used for configuration files, but could be used in many applications where data is being stored or transmitted).
Wireframe Requirements:
- Please make sure you are capturing all the minute details in all the screens
- As this application could get complex moving forward, we are expecting you to provide a very simple UX, which is important judging criteria for this challenge.
- We are providing a couple of design concepts that we did recently (It will have these screens dashboard, Input, output, policies, workflow). NOTE: Please DO NOT COPY, we are not expecting you to recreate the screens as shown in these designs - we are expecting you to think through and come up with your version of screens / with the simple user experience. These screens should help you get started with the wireframes.
- We have also shared the YAML code for your reference.
Background Information
What is TOSCA?
Topology and Orchestration Specification for Cloud Applications (TOSCA) represents a standard created by the industry group OASIS. OASIS is a nonprofit consortium that is engaged in the development of open standards supported by most vendors and major players in the cloud world as well as the telecom market. TOSCA is known as one of the fastest growing standards in OASIS and has numerous use cases and implementations that have already been announced.
TOSCA uses domain specific language (DSL) to define the interoperable description of: Cloud applications, Services, platforms, infrastructure and data components, along with their relationships, requirements, capabilities, configurations and operational policies It helps to enable portability and automated management across the cloud providers regardless of underlying platform or infrastructure thus expanding the customer choice and improving reliability and time-to-value while reducing costs.
The following video shows a very similar editor. You can watch it as a reference but have in mind that we are not looking to clone this editor, so please DO NOT COPY. We are looking to create a better UX with a very simple UI:
https://www.youtube.com/watch?v=c6RWafVzA44&feature=youtu.be
Required Screens / Functionalities
A. Network Engineers
01 Dashboard:
This page shows a list of recently created blueprints, etc
Some information that needs to be included are:
- Overall Main Navigation
- Create New Blueprint
- Open Existing Blueprints
- Clone Blueprint
- Manage Types (applicable only to “Admin” user)
[NOTE: When we say type, it could be Node types, Relationship Type, List of API’s, Capability Type, etc)
- Provide a way for the user to go to their profile.
- The user will have the ability to search for blueprints, Yang Files and load them as required.
- Take a look at the provided design concepts for more ideas but we are not limited to that, we are open to thoughts on how effective this dashboard screen need to / think about user experience.
02 Blueprint Editor:
- Blueprint editor is shown when the user chooses to create a new blueprint, or creates a clone from an existing blueprint or opens an existing blueprint.
- Blueprint is a service and has the following structure (see below), the idea is to allow the user to create/edit this TOSCA structure in a simple, easy to use UI (so it is easy even for network engineers who don’t know how to create YAML code) and at the same time as they create the structure visually, the YAML code is generated in parallel.
TOSCA Structure
- Topology Name
- Metadata Information
- Imports - (A)
- Repositories - (B)
Topology Template
- - Inputs - (C)
- - Output - (D)
Node Templates (It has the nodes (ex: virtual machines, physical servers, etc) that constitutes the template.) - (E)
- - - Node Name
- - - Type
- - - Properties
- - - Capabilities
- - - Requirements
- - - Artifacts
- - - Interfaces
- Policies - (F)
- Workflow - (G)
- When the user clicks to create a New blueprint, we need to allow the user to enter a name for the blueprint.
- Topology Name, Metadata Information is automatically captured and need not be shown in the UI but can be shown in the YAML editor which is a part of blueprint editor.
- Within the blueprint editor, we need to show some kind of progress bar, to indicate the status of the blueprint being created and if the blueprint has the status “validated” then there might be some validation errors which need to be indicated / and the user can click to view the details of the errors.
- Once the user finishes creating a blueprint, they will validate the YAML code.
- Do we need to show any navigation here or do you think “Save and Cancel” button should be fine here?
- The overall page will need to have above sections marked from (A) to (G), these sections can be shown as tabs or a tree structure or any other way you recommend - so how you represent them in the UI is up to you. We have explained below on what needs to be in each of the section. (We have also shared more definition on each of the sections and also shared a sample YAML code as defined here)
(A) Import
- This is a simple import screen, the user will use this to import yang files and services /blueprints example of the imported file name could be like “create_scheme_node_definitions_v2.yaml”, note multiple files can be imported.
- The user will need a browse through the files and select the files to be imported for this blueprint.
(B) Repository
- A key and a value indicating the name given and the URL of the repository.
- Example yang_hub: https://jr.hub.com/
Topology Template
This has the below sections, how you want to show them in the UI is up to you
(C) Inputs:
There can be many inputs. So, provide a UI that allows the user to include as many inputs as possible, each of the inputs will need to include the following:
- Input Name
- Type (can be a drop-down and this will be normal data types like string, integer, float, Boolean, date or a complex Data Type)
- Description
- Required (yes or no) - can be a checkbox
- Default Value - This can be via a constant, or an API call. If it has a default value then “Required” should be a “no”
- Constraints: There can be multiple constraints, so we need a way to allow the user to view the constraint builder/editor.
YANG File Inputs Mapping:
- Allow the user to import YANG file, which when imported
- On import, it automatically maps the inputs available in the YANG file with the inputs defined above.
Constraint Builder/Editor:
This will be an editor where the user can add some codes
Provide an editor with intellisense that is as the user types the syntax or any reference variables, corresponding options to auto-complete need to be shown, so the user can select and auto-complete the code
(D) Output:
There can be many outputs, so provide a UI that allows the user to include as many outputs as possible, each of the outputs will need to include the following
- Output Name
- Value: There can be multiple values, so we need a way to allow the user to view the value builder/editor.
- Constraints: There can be multiple constraints, so we need a way to allow the user to view the constraint builder/editor.
Value Builder/Editor:
- This is the same as the constraint editor
- This will be an editor where the user can add some codes
- Provide an editor with intellisense that is as the user types in API names, we show corresponding options to auto-complete need to be shown, so the user can select and auto-complete the code
- The values can be from APIs, example @api($var1 , $var2 , get_ <input/property/operation_out>, constant) a sample API call showing various kinds of arguments that can be passed .
- - Get_inputs
- - get_property
- - get_operation_out
are special functions that have 3 arguments (SELF/file id, node or operation), the property under the node or operation.
- SELF indicates that the node or operations in the current file if the first argument is a file id the node or operation is from a different service file.
- There needs to be an option to search the file and associate the nodes to the get_<> functions
NOTE: This will be used universally i.e. wherever Value editor is mentioned, we will be using this Value builder/Editor.
Constraint Builder/Editor:
- This will be an editor where the user can add some codes
- Provide an editor with intellisense that is as the user types the syntax or any reference variables, corresponding options to auto-complete need to be shown, so the user can select and auto-complete the code.
NOTE: This will be used universally i.e. Wherever constraints are mentioned, we will be using this constraint builder.
(E) Node Templates:
Types Palette (has all types of nodes and nodes from other imported services):
- We need a palette with the node types and nodes (from the imported files) that allows the user to drag & drop onto the canvas. NOTE: Node type is a stencil (data structure) and Nodes are the real instantiation of the stencil.
This palette will have the following:
- Show the list of node types and also nodes from other imported services.
- There could be many nodes for each of the types (Artifact Type, Relationship Type, Capability Type, Data Type, Policy Type, Event Type)
- In the palette, we need a way to group the nodes, so for example, if the nodes imported belong to the same node type then it needs to be grouped in some way, by which the user experience can be improved.
- Provide a way for the user to search.
- When a type is dragged and dropped in the canvas, we need to show the definition of the “type” somewhere in the UI on what it is capable of, etc
Canvas
- The user will drag & drops, the nodes from the Tool Palette and drops them on to the canvas to start creating a topology template structure as defined below, so basically the code structure is captured/built in a visual way and in parallel we generate YAML code for what is being created.
- When a node type is dragged and dropped, it is an empty node without any requirement, capabilities, etc
- The user will need to select a node to fill in the “Node details”
- There needs to be a way to create relationship/link nodes
Node Details
A user can choose any of the nodes that were dropped in the canvas to start editing its properties which could include the following:
- Properties
- Capabilities
- Requirements
- Artifacts
- Interfaces
- We are looking for your ideas on how and where this needs to be shown
- This is one of the important parts of the UI, so think through the user experience.
YAML Editor:
- This shows the YAML editor, so the code is generated as the user drag & drops elements in the canvas and creates the relationship.
- We are sharing sample YAML code which you can use in your wireframes
- Provide a way to export the YAML code
- It can be 2 ways, visualization to YAML code and YAML code to visualization,
- Users can use the drag and drop or users can do the edit the YAML or load a new YAML, YAML to visualization, visualization to YAML.
(F) Policies / Policy Editor:
- This will be part of the overall blueprint screen but need not be part of the blueprint editor, instead, it can be shown as another tab or the like, and it has its own tool palette, list of policies associated, policy UI editor and YAML Editor (code editor)
- Multiple Policies can be associated with a blueprint.
List of Policies:
Show the list of policies that are currently associated, or provide a way to associate a new policy type with the blueprint.
The user can select a policy and view /edit details of the policy.
Policy Tool Palette:
This will include the Policy type and Event type
Provide a way to search the policy types and event types
The user can select a policy or event type to create an existing or new policy
Create/View/Edit Policy:
A policy is composed of:
- Policy type (Users will drag and drop the policy type here from the tool palette)
- Properties: User enters the properties
- Targets: There can be many targets and it is a mod-able entity, so a user can search for services and select services or they can select a SELF (which could be a node within this file).
- Triggers
- Event Type (Users will drag and drop the event type here from the tool palette or set it using a drop-down)
- Action
(G) Workflow / Workflow Editor:
- A workflow is a series of steps, one or more steps are triggered when a condition is matched.
- A Workflow is always associated with a policy, so we need a way to edit the workflow within the policy (it could be a tab or some other way to access the workflow editor)
- Usually, one policy will have one workflow, but that doesn’t stop the user from adding many policies in a single workflow.
Some of the basic elements that are required in a workflow page are below (NOTE: we have shared the basic code structure of the workflow), the idea here is to create a UI that will allow users to create the workflow visually and at the same time code is generated based on what is being chosen in the UI
- Workflow Name
- Pre-Conditions:
- - Target: There can be many targets and it is a modable entity, so a user can search for services and select any services (or) they can select “SELF” (which could be a node within this file)
- - Condition:
- - - Assert:
- - - - Workflow Name (allow the user to select a name)
- - - - Enable (This will be true or false)
The user can have multiple pre-conditions, so basically the user can repeat the details above as many times as required. So in the UI provide a way to include multiple conditions think on the best possible way to do this.
Steps:
- Step Name
- Constraints (Multiple constraints can be added with the help of constraint builder - please see above under “Inputs/Output”)
- Target: We need 2 fields here:
- - - Mod-able entity = SELF or a file id, the file can be searched opened and then the node selected
- - - Target is a node in the same file or the file with the file id
- Filter
- - Assert
- - - - Workflow Step Name (allow the user to select a name)
- - - - Scheme State
- Activities:
- - - Call Operation: User will include the “node.interface.operation.apicall” the node should normally be the target node
Example: newEquipmentScheme.StartFundamentalPlanning.progressSchemeSFp.saveSchemeState
The user can have multiple steps, so basically the user can repeat the details above (Constraints, Target, Condition, Assert, Workflow name and enable) as many times as required. So in the UI provide a way to include multiple conditions think on the best possible way to do this.
Though the above information is captured in the UI, in parallel - the user should be able to see the YAML editor to see the code that has been generated and there should be a way to way to edit it directly and the editor will have intellisense feature which will help users save time by allowing them to auto-complete the code / showing the appropriate syntax and reference API/node names, etc
03 Validation:
- Every Blueprint that was created needs to be validated.
- Once the blueprint is created, users can go to the validation tab or the like and click on a button “Validate” to being the validation process or we can have validation and normal mode, if in validation mode it's like always validate.
- Once the validation process is complete it needs to show the validation errors in a visual way within the canvas (maybe the node can be highlighted in red, it’s up to you) as well as in an editor/ code error.
Example of errors could be like:
Error : Unexpected characters near " AND @notNull($MUXSoId)'".
Line: 149 runTimeCondition: '@notNull($EADSoId)' AND @notNull($MUXSoId)'
So, assume we have the above error is shown in both visual as well as text, then we could do something like when the user hovers over this particular error then the corresponding error can be highlighted in the canvas).
B. Admin
An admin can access the same screens as that of other users in addition to that they can access the below
Manage Types Page:
All “types” information is managed by the admin on this page, list of types include:
- Node types
- Artifact Type
- Relationship Type
- Capability Type
- Data Type
- Policy Type
- Event Type
- List of API’s (normal or custom API’s)
- Provide a way for the user to select and edit a type
- The user may in some cases get a request to create a new type, so there should be a way for the user to create a new type.
- Each of the types has an associated icon, provide a way to associate an icon with the type and there should be a way to configure the color of the icon (assuming the icon will be an SVG).
Target Users
- Network Engineers, Admins
Tools Sketch / HTML:
- You can also work with static images but you must include a fully navigable prototype in HTML.
- NOTE: If you are designing in the sketch or Adobe XD then it is mandatory that you create the flow using Marvelapp / Invision as we are expecting to see a clickable wireframe in this challenge.
- You are also allowed to submit pure HTML wireframes
Judging Criteria
- User Experience of the application/editor
- Completeness and accuracy of your wireframes
- How well your wireframes provide a consistent user flow
Submission & Source Files
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
Wireframes should be built in HTML or Axure
Source Files
All original source files of the submitted ideas. If you would like to submit notes please include notes.txt file.
Final Fixes
As part of the final fixes phase, you may be asked to modify content or user click paths
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.