Challenge Overview
General Requirements
- The app supports 3 roles: Standard, AppOwner or Admin.
- User Access Management to be done via the ‘Manage User Access’ screens which should be accessible to Admin users only.
- User(s) with ‘Admin’ is responsible for managing other users’ access and roles.
- User(s) with ‘AppOwner’ is responsible for managing Applications, Instances, Jobs and Dashboard screens.
- User(s) with ‘Standard’ has a readonly view to Applications, Instances and Jobs and Dashboard screens.
- Users with different roles should be defined and demonstrated properly in your submission
- Application has an 'aggregration' relationship with Instance. Whereas, Job has only an 'association' relationship with Instance. For example, if I delete an Application, then all the Instances related to that Application would get destroyed. If I delete a Job then it shouldn't affect the related Instances at all.
- The app supports 3 roles: Standard, AppOwner or Admin.
- User Access Management to be done via the ‘Manage User Access’ screens which should be accessible to Admin users only.
- User(s) with ‘Admin’ is responsible for managing other users’ access and roles.
- User(s) with ‘AppOwner’ is responsible for managing Applications, Instances, Jobs and Dashboard screens.
- User(s) with ‘Standard’ has a readonly view to Applications, Instances and Jobs and Dashboard screens.
- Users with different roles should be defined and demonstrated properly in your submission
- Application has an 'aggregration' relationship with Instance. Whereas, Job has only an 'association' relationship with Instance. For example, if I delete an Application, then all the Instances related to that Application would get destroyed. If I delete a Job then it shouldn't affect the related Instances at all.
Page Requirements
00 - Login/Register Page
- User is able to login on this page.
- User is able to register with App Owner, or Standard role
01 - Dashboard Page
- The dashboard is displayed after login
- The left menu is collapsible
02 - Application Page
- User is able to search, filter, add, edit, and remove the applications
- On the table view, user is able to manage columns (e.g. sort data in columns, show / hide specific column)
03 - Instance Page
- User is able to search, filter, add, edit, and remove the instances
- On the table view, user is able to manage the columns
- the storyboard doesn't have all the pages, but it should be similar as the application pages for all the actions.
04 - Jobs Page
- User is able to search, filter, add, edit and remove the jobs
- On the table view, user is able to manage the columns
- the storyboard doesn't have all the pages, but it should be similar as the application pages for all the actions.
05 - Results Page
- User is able to search, filter the results
- On the table view, user is able to manage the columns
- the storyboard doesn't have all the pages, but it should be similar as the application pages for all the actions.
06 - Users Page
- Admin is able to search, filter, add, edit and remove the users
- On the table view, user is able to manage the columns
- the storyboard doesn't have all the pages, but it should be similar as the application pages for all the actions.
Prototype Requirements
- Please create a mockup backend using json-server, the API details and json payload will be provided to you, and your mockup should follow that. And for anything that's not covered by the API details, you can make proper assumptions.
- The options for the checkboxes should come from local JSON files instead of hardcoded on the pages.
- Must use Angular 6+ and Material Design components
- The pages should clearly indicate invalid input data to users, for example: on login screen if users hit login without entering username, the textbox should be highlighted in red with an error message too
- Please use Angular Hi-Chart library
- Must follow Angular best coding practices
- Create README.md file that explains your UI prototype structure
- Your submission must follow the Responsive UI best practice
HTML Requirements
- HTML should be valid HTML5 compliant.
- Provide comments on the page elements to give clear explanation of the code usage. The goal is to help future developers understand the code.
- Please use clean INDENTATION for all HTML code so future developers can follow the code.
- All HTML code naming should not have any conflicts or errors.
- Element and Attribute names should be in lowercase and use a "-" or camel naming to separate multiple-word classes (i.e.. "main-content", or "mainContent)
- Use semantically correct tags- use H tags for headers, etc. Use strong and em tags instead of bold and italic tags.
- No inline CSS styles- all styles must be placed in an external stylesheet.
- Validate your code- reviewers may accept minor validation errors, but please comment your reason for any validation errors. Use the validators listed in the scorecard.
CSS Requirements
- Use CSS3 Media Queries to load different styles for each page and don't build different page for different device/layout.
- Provide comments on the CSS code. We need CSS comments to give a clear explanation of the code usage. The goal is to help future developers understand the code.
- Please use clean INDENTATION for all CSS so developers can follow the code.
- All CSS naming should not have any conflicts.
- As possible use CSS3 style when create all styling.
- Use CSS to space out objects, not clear/transparent images (GIFs or PNGs) and use proper structural CSS to lay out your page.
- Only use table tags for tables of data/information and not for page layout.
- Use SCSS / SASS for styling
Javascript Requirements
- All JavaScript must not have a copyright by a third party. You are encouraged to use your own scripts, or scripts that are free, publicly available and do not have copyright statements or author recognition requirements anywhere in the code.
- Use typescript and linter for code quality
Licenses & Attribution
- Third-party assets used to build your item must be properly licensed or free for commercial use. MIT, some modified BSD, Apache 2 licenses are ok, but if a library is not commercial friendly you need to get our approval first.
- Sufficient information regarding third-party assets must be present in your documentation. This includes the author, license info and a direct link to the asset online.
Screen Specifications
- Must support desktop.
- Must support retina display.
- Layout width should be fluid.
Browser Requirements
- Desktop: IE11+, Latest Firefox, Latest Safari & Chrome Browsers (Mac & Windows).