Challenge Summary
Welcome to Anemoi - Data Pipeline - Components - Design Concepts Challenge!
This challenge is focused on creating visual designs and ideas for an application which manages Big Data analysis systems. It is responsible for acquiring data into the system and then coordinating the storage and analysis of that data. It additionally provides standard patterns for data logging and metric collection.
We are looking for an innovative, easy to understand, and intuitive user interface and user experience to visualize and interact with the data source processing pipeline. The UI should be easy to understand, clean, modern, and intuitive to user familiar with the process and data.
Previously we ran a design concept challenge to build the screens needed for this tool, and you will be provided with the screen designs we built.
Note: Please use the existing screen designs as a basis for adding the new functionality described below. Your designs must be consistent with the style and guidelines of the existing screen designs.
1. My Components
2. Component Catalogue
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
1. My Components
2. Component Catalogue
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
IMPORTANT NOTE:
We found out that members from certain countries are restricted from working on this challenge, due to the client’s company policies. Challenge submissions cannot be accepted from members registered in a country with a score of 37 or less according to Transparency International's Corruption Perception Index 2015.
If your country is highlighted in red in the following sheet your submission WILL NOT be accepted, unfortunately. This is NOT a new Topcoder policy or something that will become a normal part of future challenges. This is an isolated policy and requirement for this specific client and their challenges. Thank you for your understanding.
https://drive.google.com/file/d/0B9lpcmurgZ35WlkyWUV2OW9IRjQ/view
Challenge Description:
The existing screen designs for this application focus on managing a set of pipelines for processing data. The application allows the user to configure a pipeline, as well as management previously built pipelines.
The goal of this challenge is to design additional screens for managing a set of components. Components are not related to pipelines. The application should allow the user to build a system consisting of components with configurable settings, as well as manage previously deployed components.
When building a system or deploying components the application will assist the user by offering defaults, suggesting options for dependencies, and offering visual clues on outstanding configuration choices.
Branding Guidelines:
We have created a Design Direction site that has downloadable storyboards, branding guidelines, additional information, and inspiration. Use this site as a one-stop-shop for all of your input into this challenge: https://projects.invisionapp.com/boards/KX14M76UTHWAG/
Design Considerations:
- Please use the existing styling found in the existing screen designs
- Do not use modals and consider using alternatives, such as slide-out panels.
- The designs colors need to be easily editable via css. For Example: All CTAs should have the same colors, etc. Think about easy updatability when designing.
- It will be best to keep a clean neutral color scheme to allow for future branding updates and changes.
- We need to make sure there is good contrast between font colors on their background. This is for accessibility reasons. A 20% difference in contrast is a good rule to follow.
Screen Size Requirements:
Desktop Responsive:
- Small Desktop: 1280px wide (Height can expand. Keep important information above 766px if possible)
- Large Desktop: 2560px wide (Height can expand)
We are interested in seeing how the layout can adapt between these 2 sizes. What information, panels. etc. can be hidden on the 1280px screen? How does the layout change and respond to the much larger 2560px size? How can the larger size make creating a pipeline for the user easier? Or reveal additional useful information?
Component Deployment and Management:
The user interface allows a user to deploy a specific set of software services to a system. Together these services are referred to as a component. As well as controlling which components are deployed the interface also reports the status of each service, allows services to be stopped and handles service configuration. The application should allow the user to browse a catalogue of components and deploy a specific instance of that component with configurable settings, as well as manage previously deployed components.
The challenge is to design a user interface which provides a way to select and submit services for deployment, report their status/health and manage the dependency requirements between services within a component.
Key terms
System - A system is comprised of multiple components which work together
Component – a set of related services which together perform a specific function within a larger system. Components are intended to run in an isolated manner. Once deployed services may interact via their public interfaces
Interface – a service which exposes a public API and is a required service within a component
Capability – an internal, optional set of one or more services within a component
Implementations – each interface or capability may have multiple implementations available for deployment
Service – a piece of software which provides a specific capability or API
Configuration – every service has a set of configuration parameters some of which apply to all services and some of which are specific to the service. Each parameter may have a set of validation rules
Component Definition Principles
How components are defined in the component definition file is governed by a list of guiding principles:
- Services have dependencies on Interfaces
- A Service can be dependent on any Public Interface
- A Service can only be dependent on a Private Interface if it is grouped within the same Implementation
- A Component is defined by one or more Implementations
- An Implementation consists of one or more services
- The Implementations selected for a component must provide all of the Component's public interfaces
- Some Implementations may not provide an Interface
- Services may be shared by Implementations within the same Component
- Services may not be shared by Implementations within different Components
Example scenario
The following component definition illustrates a number of important concepts. It describes a definition for a single component called monitoring:
- The component has two interfaces and a capability
- The Monitoring::Storage interface has two different implementations specified, each comprising two services
- The Monitoring::Query interface comprises a single service which has a dependency on the Monitoring::Storage interface. This means one of the Monitoring::Storage implementations must be running/selected before the Monitoring::Query interface can be run
- The component has a single capability
- The Monitoring::Monitor::Host capability has a dependency on the Monitoring::Storage interface, which means those services must be running/selected before the capability can run
- Each interface and capability specify which implementation is the default one
- There are user interfaces made available by the component, once its required services are running. These user interfaces allow the user to monitor that particular service
The ‘monitoring’ component is one example. Other example components include, ‘logging’, ‘authentication’, ‘data-processing’.
Note: There will be roughly 10 to 40 components in the system at any one time. Make sure your UX and UI accounts for navigating and viewing that number of components in an efficient way.
Additional requirements to consider:
- When starting a component it should only be possible to start all services within an implementation rather than individual services
- Services which have a dependency should only be allowed to run if their dependencies are running or are selected for deployment
- Once a component is running, individual services can be stopped/started
- It should be possible to select whether or not to deploy an optional dependency
- The interface should indicate the status of each service: Active, Inactive, Deploying, Errored
- The status of the component itself should be indicated: Active, Inactive, Deploying, Errored
- In the example the storage-access-service has configuration options, which should be accessible and editable
- A service can only be started once all its configuration validation rules have been met. The UX should provide visual clues on the completeness and validity of configurations
Screen Requirements:
Use the provided screen designs as your guide for specific functionality and features that must be included in your designs. Layouts can change if their is a better solution for organizing and presenting the content.
Tab 1 - My Components tab (this could be positioned next to ‘My Pipelines’ tab)
Sub-tab 1a - Deployed Components (default)
- List view and grid view of deployed components
- Search and Filtering capabilities (similar to the functionality for ‘My Pipelines’)
- Quick link to “Deploy Component”
- Multiple views/ tabs of components; based on status or groupings (‘All’, ‘Inactive’, ‘Active’, ‘Errored’)
- High level stats, information, and action items for each component
- Expandable view of a component for view additional information: health, history/ activity, etc.
Sub-tab 1b - Component Catalogue
- List view and grid view of components available to be deployed
- Search and Filtering capabilities (similar to the functionality for ‘My Pipelines’)
- Each component has a description and details of the different service options
- Ability to deploy an instance of a component with deployment options available for that component e.g. mandatory and dependent services, optional services, number of ‘CPUs’ and number of ‘Instances’ (refer to ‘Component Management and Deployment’ section of this spec for details). Do not use modals - slide out panels are preferred
- When deploying a component configurable parameters available
Additional Input and Resources:
- Existing screen designs: The main source of input for this challenge. Use this as your guide for functionality, features, UX, and flows that MUST be included in your designs.
- We’ve compiled some additional inputs, resources, and examples into an InVision Board used for the previous design concept challenges. Use this to view and download additional information and assets that will be useful for your designs.
Important:
- Keep things consistent. This means all graphic styles should work together.
- All of the graphics should have a similar feel and general aesthetic appearance
- Keep your designs open, modern and clean
- Make sure you are colors and styles in a way that allows for each updates in the future via CSS styles. For example: all CTAs should use the same color.
- Use the storyboards as your base structure for features, functionality, UX and user flows.
Target Audience:
Anemoi employees who are going to manage components and are familiar with the data and information
Judging Criteria:
- Overall User Experience and UI design
- Completeness and accuracy of the designs as defined in the attached requirements.
- How well your designs provide a consistent user flow and style
- How well your designs captures all the requirements.
- Any suggestions, interactions and user flows you recommend (provide any notes or comments for the client)
- Wow factor! We want to be impressed with the overall design and execution.
- Innovative ideas and ways to interact and handle the content. This could be via functionality and/ or UI elements.
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
Submit JPG/PNG for your submission files.
Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop and saved as layered PSD file, or Adobe Illustrator as a layered AI file.
Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback. See more information about Final Fixes
This challenge is focused on creating visual designs and ideas for an application which manages Big Data analysis systems. It is responsible for acquiring data into the system and then coordinating the storage and analysis of that data. It additionally provides standard patterns for data logging and metric collection.
We are looking for an innovative, easy to understand, and intuitive user interface and user experience to visualize and interact with the data source processing pipeline. The UI should be easy to understand, clean, modern, and intuitive to user familiar with the process and data.
Previously we ran a design concept challenge to build the screens needed for this tool, and you will be provided with the screen designs we built.
Note: Please use the existing screen designs as a basis for adding the new functionality described below. Your designs must be consistent with the style and guidelines of the existing screen designs.
Round 1
Submit your design for a Checkpoint feedback1. My Components
2. Component Catalogue
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
Round 2
Final design plus Checkpoint feedback1. My Components
2. Component Catalogue
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
IMPORTANT NOTE:
We found out that members from certain countries are restricted from working on this challenge, due to the client’s company policies. Challenge submissions cannot be accepted from members registered in a country with a score of 37 or less according to Transparency International's Corruption Perception Index 2015.
If your country is highlighted in red in the following sheet your submission WILL NOT be accepted, unfortunately. This is NOT a new Topcoder policy or something that will become a normal part of future challenges. This is an isolated policy and requirement for this specific client and their challenges. Thank you for your understanding.
https://drive.google.com/file/d/0B9lpcmurgZ35WlkyWUV2OW9IRjQ/view
Challenge Description:
The existing screen designs for this application focus on managing a set of pipelines for processing data. The application allows the user to configure a pipeline, as well as management previously built pipelines.
The goal of this challenge is to design additional screens for managing a set of components. Components are not related to pipelines. The application should allow the user to build a system consisting of components with configurable settings, as well as manage previously deployed components.
When building a system or deploying components the application will assist the user by offering defaults, suggesting options for dependencies, and offering visual clues on outstanding configuration choices.
Branding Guidelines:
We have created a Design Direction site that has downloadable storyboards, branding guidelines, additional information, and inspiration. Use this site as a one-stop-shop for all of your input into this challenge: https://projects.invisionapp.com/boards/KX14M76UTHWAG/
Design Considerations:
- Please use the existing styling found in the existing screen designs
- Do not use modals and consider using alternatives, such as slide-out panels.
- The designs colors need to be easily editable via css. For Example: All CTAs should have the same colors, etc. Think about easy updatability when designing.
- It will be best to keep a clean neutral color scheme to allow for future branding updates and changes.
- We need to make sure there is good contrast between font colors on their background. This is for accessibility reasons. A 20% difference in contrast is a good rule to follow.
Screen Size Requirements:
Desktop Responsive:
- Small Desktop: 1280px wide (Height can expand. Keep important information above 766px if possible)
- Large Desktop: 2560px wide (Height can expand)
We are interested in seeing how the layout can adapt between these 2 sizes. What information, panels. etc. can be hidden on the 1280px screen? How does the layout change and respond to the much larger 2560px size? How can the larger size make creating a pipeline for the user easier? Or reveal additional useful information?
Component Deployment and Management:
The user interface allows a user to deploy a specific set of software services to a system. Together these services are referred to as a component. As well as controlling which components are deployed the interface also reports the status of each service, allows services to be stopped and handles service configuration. The application should allow the user to browse a catalogue of components and deploy a specific instance of that component with configurable settings, as well as manage previously deployed components.
The challenge is to design a user interface which provides a way to select and submit services for deployment, report their status/health and manage the dependency requirements between services within a component.
Key terms
System - A system is comprised of multiple components which work together
Component – a set of related services which together perform a specific function within a larger system. Components are intended to run in an isolated manner. Once deployed services may interact via their public interfaces
Interface – a service which exposes a public API and is a required service within a component
Capability – an internal, optional set of one or more services within a component
Implementations – each interface or capability may have multiple implementations available for deployment
Service – a piece of software which provides a specific capability or API
Configuration – every service has a set of configuration parameters some of which apply to all services and some of which are specific to the service. Each parameter may have a set of validation rules
Component Definition Principles
How components are defined in the component definition file is governed by a list of guiding principles:
- Services have dependencies on Interfaces
- A Service can be dependent on any Public Interface
- A Service can only be dependent on a Private Interface if it is grouped within the same Implementation
- A Component is defined by one or more Implementations
- An Implementation consists of one or more services
- The Implementations selected for a component must provide all of the Component's public interfaces
- Some Implementations may not provide an Interface
- Services may be shared by Implementations within the same Component
- Services may not be shared by Implementations within different Components
Example scenario
The following component definition illustrates a number of important concepts. It describes a definition for a single component called monitoring:
- The component has two interfaces and a capability
- The Monitoring::Storage interface has two different implementations specified, each comprising two services
- The Monitoring::Query interface comprises a single service which has a dependency on the Monitoring::Storage interface. This means one of the Monitoring::Storage implementations must be running/selected before the Monitoring::Query interface can be run
- The component has a single capability
- The Monitoring::Monitor::Host capability has a dependency on the Monitoring::Storage interface, which means those services must be running/selected before the capability can run
- Each interface and capability specify which implementation is the default one
- There are user interfaces made available by the component, once its required services are running. These user interfaces allow the user to monitor that particular service
The ‘monitoring’ component is one example. Other example components include, ‘logging’, ‘authentication’, ‘data-processing’.
Note: There will be roughly 10 to 40 components in the system at any one time. Make sure your UX and UI accounts for navigating and viewing that number of components in an efficient way.
Additional requirements to consider:
- When starting a component it should only be possible to start all services within an implementation rather than individual services
- Services which have a dependency should only be allowed to run if their dependencies are running or are selected for deployment
- Once a component is running, individual services can be stopped/started
- It should be possible to select whether or not to deploy an optional dependency
- The interface should indicate the status of each service: Active, Inactive, Deploying, Errored
- The status of the component itself should be indicated: Active, Inactive, Deploying, Errored
- In the example the storage-access-service has configuration options, which should be accessible and editable
- A service can only be started once all its configuration validation rules have been met. The UX should provide visual clues on the completeness and validity of configurations
Screen Requirements:
Use the provided screen designs as your guide for specific functionality and features that must be included in your designs. Layouts can change if their is a better solution for organizing and presenting the content.
Tab 1 - My Components tab (this could be positioned next to ‘My Pipelines’ tab)
Sub-tab 1a - Deployed Components (default)
- List view and grid view of deployed components
- Search and Filtering capabilities (similar to the functionality for ‘My Pipelines’)
- Quick link to “Deploy Component”
- Multiple views/ tabs of components; based on status or groupings (‘All’, ‘Inactive’, ‘Active’, ‘Errored’)
- High level stats, information, and action items for each component
- Expandable view of a component for view additional information: health, history/ activity, etc.
Sub-tab 1b - Component Catalogue
- List view and grid view of components available to be deployed
- Search and Filtering capabilities (similar to the functionality for ‘My Pipelines’)
- Each component has a description and details of the different service options
- Ability to deploy an instance of a component with deployment options available for that component e.g. mandatory and dependent services, optional services, number of ‘CPUs’ and number of ‘Instances’ (refer to ‘Component Management and Deployment’ section of this spec for details). Do not use modals - slide out panels are preferred
- When deploying a component configurable parameters available
Additional Input and Resources:
- Existing screen designs: The main source of input for this challenge. Use this as your guide for functionality, features, UX, and flows that MUST be included in your designs.
- We’ve compiled some additional inputs, resources, and examples into an InVision Board used for the previous design concept challenges. Use this to view and download additional information and assets that will be useful for your designs.
Important:
- Keep things consistent. This means all graphic styles should work together.
- All of the graphics should have a similar feel and general aesthetic appearance
- Keep your designs open, modern and clean
- Make sure you are colors and styles in a way that allows for each updates in the future via CSS styles. For example: all CTAs should use the same color.
- Use the storyboards as your base structure for features, functionality, UX and user flows.
Target Audience:
Anemoi employees who are going to manage components and are familiar with the data and information
Judging Criteria:
- Overall User Experience and UI design
- Completeness and accuracy of the designs as defined in the attached requirements.
- How well your designs provide a consistent user flow and style
- How well your designs captures all the requirements.
- Any suggestions, interactions and user flows you recommend (provide any notes or comments for the client)
- Wow factor! We want to be impressed with the overall design and execution.
- Innovative ideas and ways to interact and handle the content. This could be via functionality and/ or UI elements.
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
Submit JPG/PNG for your submission files.
Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop and saved as layered PSD file, or Adobe Illustrator as a layered AI file.
Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback. See more information about Final Fixes
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.