Challenge Overview
Welcome to Quartz - Database Cleaning Webapp Prototype Challenge.
We need your help to create the prototype of a simple web application we’re building to help users with a database cleaning process to eliminate duplicate data following certain criteria defined by the user.
Best of luck!
Project Overview
The goal of this challenge is to develop HTML/CSS/JS code to build a prototype of an application which will be powered by Angular. This means that you must use Angular in your solution already. By the end of the challenge, we expect to have a very clean and lean scaffolded project.
You are provided with the storyboards screens and source files which you’ll use to build up the working prototype.
Problem in a Nutshell
Background
A massive amount of information related to wells is stored in a known service called Hadoop. This type of data store is generally used when data volumes are too big for a single disk to store the data and/or when a high-performance processing is needed to query and process large data sets.
Duplicate Data
Quartz has a problem with this data, there are many duplicated columns that are getting pushed into this data store and our clients are looking for automated ways to dedupe and clean it.
The deduping process, for the most part, is pretty simple. Duplicate columns are easily identified in the database. They have a root name and then dup_0, dup_1, dup_2, etc is concatenated to the end of the column name.
Solution
Our app will review the data in the columns and resolve these duplications by some set of processing rules. Basically, the application will look at the best column of data and when there is a clear "winner" we'll copy that to the master column in an automatic way.
However, there will be times where user intervention will be needed because the tool won’t be able to resolve those cases automatically. More than one column might be right or there might not be a column of data among the dupes provided that satisfies the minimum conditions. In this case, we'll need human intervention; this is when the solution comes into place.
Prototype Requirements
Overall
- All screens provided in the storyboard are in scope and required.
- Your prototype must match the approved design, in look and functionality. It must also support/represent the provided flow of pages.
- Use the latest stable version of angular.
- Use Angular-CLI to create the project structure. Unit tests are not necessary, don’t include that.
- UI data must be pulled from JSON files in order to easily integrate with API responses.
- Charts can be created using D3.js.
- The following command must not generate any errors `ng build --prod`.
- Loader animations must be included in the data tables and buttons as displayed in the storyboards.
- Header/footer backgrounds must extend across the view no matter the screen dimension, content must stay centered for large screen scenarios. Desktop breakpoint: 1280px.
1. Home
See 01 - 07 screens range.
- User should be able to sort/group the data by well and stage number only (add an arrow to stage number, it’s missing in the design).
- User should be able to select multiple items to apply actions at the same time e.g. process now.
- Each stage should have a status field: Completed, Needs Manual Review, or Not Processed.
- User can click process all button to initiate automatic processing on ALL rows which status is not processed.
- The Not processed rows should have a “Process Now” button or link. After a User clicks “Process Now” there are two possible outcomes. Either the batch will be completed in a completely automated way and the status of the Stage row will be changed to “Completed” (screen 06) OR the there will be some ambiguity with the data which will require manual intervention from an admin. In that case, the record status will be changed to “Needs Manual Review” (clicking review on this case goes to screen 09 - review with selected well data) .
- Completed rows should have a link a toggleable report (screen 07).
2. Review Results
See 08 - 14 screens range. Clicking review from the top menu comes to screen 08.
- User can see a chart with each column represented (column value vs time axis).
- In the chart, user can select which lines to see (10_01). User can compare multiple points simultaneously through hovering (10_02).
Validation Overview
After validating conflicting records, user should be able to see a quick report of the performed actions, screen 14. This occurs when user selects a column in the drop down at the bottom of the page, then clicking Apply.
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. Do not build different page for different device/layout.
- You may use SCSS in the project.
- 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.
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.
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. If a library is not commercial friendly you will 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 browser.
- Mobile not supported, not required.
Browser Requirements
- Desktop: IE11+, Latest Firefox, Latest Safari & Chrome Browsers (Mac & Windows).
We need your help to create the prototype of a simple web application we’re building to help users with a database cleaning process to eliminate duplicate data following certain criteria defined by the user.
Best of luck!
Project Overview
The goal of this challenge is to develop HTML/CSS/JS code to build a prototype of an application which will be powered by Angular. This means that you must use Angular in your solution already. By the end of the challenge, we expect to have a very clean and lean scaffolded project.
You are provided with the storyboards screens and source files which you’ll use to build up the working prototype.
Problem in a Nutshell
Background
A massive amount of information related to wells is stored in a known service called Hadoop. This type of data store is generally used when data volumes are too big for a single disk to store the data and/or when a high-performance processing is needed to query and process large data sets.
Duplicate Data
Quartz has a problem with this data, there are many duplicated columns that are getting pushed into this data store and our clients are looking for automated ways to dedupe and clean it.
The deduping process, for the most part, is pretty simple. Duplicate columns are easily identified in the database. They have a root name and then dup_0, dup_1, dup_2, etc is concatenated to the end of the column name.
Solution
Our app will review the data in the columns and resolve these duplications by some set of processing rules. Basically, the application will look at the best column of data and when there is a clear "winner" we'll copy that to the master column in an automatic way.
However, there will be times where user intervention will be needed because the tool won’t be able to resolve those cases automatically. More than one column might be right or there might not be a column of data among the dupes provided that satisfies the minimum conditions. In this case, we'll need human intervention; this is when the solution comes into place.
Prototype Requirements
Overall
- All screens provided in the storyboard are in scope and required.
- Your prototype must match the approved design, in look and functionality. It must also support/represent the provided flow of pages.
- Use the latest stable version of angular.
- Use Angular-CLI to create the project structure. Unit tests are not necessary, don’t include that.
- UI data must be pulled from JSON files in order to easily integrate with API responses.
- Charts can be created using D3.js.
- The following command must not generate any errors `ng build --prod`.
- Loader animations must be included in the data tables and buttons as displayed in the storyboards.
- Header/footer backgrounds must extend across the view no matter the screen dimension, content must stay centered for large screen scenarios. Desktop breakpoint: 1280px.
1. Home
See 01 - 07 screens range.
- User should be able to sort/group the data by well and stage number only (add an arrow to stage number, it’s missing in the design).
- User should be able to select multiple items to apply actions at the same time e.g. process now.
- Each stage should have a status field: Completed, Needs Manual Review, or Not Processed.
- User can click process all button to initiate automatic processing on ALL rows which status is not processed.
- The Not processed rows should have a “Process Now” button or link. After a User clicks “Process Now” there are two possible outcomes. Either the batch will be completed in a completely automated way and the status of the Stage row will be changed to “Completed” (screen 06) OR the there will be some ambiguity with the data which will require manual intervention from an admin. In that case, the record status will be changed to “Needs Manual Review” (clicking review on this case goes to screen 09 - review with selected well data) .
- Completed rows should have a link a toggleable report (screen 07).
2. Review Results
See 08 - 14 screens range. Clicking review from the top menu comes to screen 08.
- User can see a chart with each column represented (column value vs time axis).
- In the chart, user can select which lines to see (10_01). User can compare multiple points simultaneously through hovering (10_02).
Validation Overview
After validating conflicting records, user should be able to see a quick report of the performed actions, screen 14. This occurs when user selects a column in the drop down at the bottom of the page, then clicking Apply.
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. Do not build different page for different device/layout.
- You may use SCSS in the project.
- 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.
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.
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. If a library is not commercial friendly you will 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 browser.
- Mobile not supported, not required.
Browser Requirements
- Desktop: IE11+, Latest Firefox, Latest Safari & Chrome Browsers (Mac & Windows).