Challenge Overview

Challenge Objectives
RCS is an Asset Reliability Centered Business Performance Tool, specifically designed for Power Grids and Substations asset reliability management. For this project, we are going to run a series of prototype challenges to build a web based UI for the tool.
 
Challenge Objectives
For the purpose of this challenge, we need the community to help build the SWMS screens into the prototype using Angular 6 / Bootstrap / HTML5 / CSS, please check the documents in the forum to help you get started.
 
Please note that winner is responsible of raising a merge request to our code repo.
 
Bonus
$200 to each of the top 2 submissions if final score is over 90.
 
Technology Stack
  • Angular 6
  • Bootstrap
  • HTML5
  • Javascript
  • CSS
 
Challenge Requirements
The following screens are all in scope of this challenge, and we’ll provide sketch file which contains full design.
 
Entry to these screens is: Policy Screen (click the Shield icon on the top right corner) -> Check any row -> Click Edit -> Go to Procedure Tab -> Create new SWMS
 
SWMS - Step 1
9.1.0.1 Hazard definition
This is the first screen you see, clicking the edit icon will bring up 9.1.0.2 Hazard definition where user can edit title and description, updated values will be reflected back to the main page.
 
9.1.1 Hazard definition
  • Hazard list will be loaded from JSON object and if we add a new Hazard name, it should add in JSON too, developer is responsible for creating this json.
  • Hazard title will be Auto Incremented: Hazard 001, Hazard 002, etc.
  • In the Hazard box, user can start typing the Hazard name or select the Hazard from drop down. If typed result is not found in the list, plus button will appear like below screen and as soon as we click on the plus button, that value will be added in Json. This involves the following screens:
 
9.1.2.1 Hazard definition
  • Once the user fills the hazard Severity and Probability dropdown will appear and below that, will get box to Add new Hazard with title “Hazard 002”. Note the design just shows 2 hazards, but there can be more, you prototype needs to take care of that.
  • Risk Label value will be reflected from the value of  Severity and Probability selection. Rules will be provided by us.
 
9.1.2.2 Hazard definition
User can “add  Mitigation” or “Delete hazard” from here. And multiple Mitigations can be added in single Hazard, but for Multiple mitigations also, We will have single Severity and Probability box, this involves the following screens:  
SWMS - Step 2
9.2.1 Step definition
  • Once we click on next Button on Step 1, Step 2 screen will come.
  • Step name and description can be changed like step 1.
  • On click of define sld view, the prototype should ask the user to upload a local image, then the 9.2.1.1 Step definition | Define SLD view screen will show up. It will load sld image in the popup with below functionality:
 
9.2.1.2 Step definition | Define statement
On click of “Add New Statement”. Statement numbering is auto incremented. For example: This comes under step 2, so statement numbering will be 2.1,2.2, 2.3 and so on.
 
Whatever we fill in left panel will reflect in right panel, but right panel is not editable. If user clicks Edit SLD view button then 9.2.1.1 should show up again to allow replacing the image.
 
9.2.1.3 Step definition | Define statement
This screen is actually the same screen as 9.2.1.2 above, the view changes when the little left arrow icon is clicked. And view goes back to 9.2.1.2 if the right arrow icon is clicked.
Please note that users can still zoom in, zoom out or center the sld image.
 
SWMS - Step 3
Step 3 layout, flow and functionality will be the same as step 2 except that the “Define SLD View” Button will be hidden, the same image from step 2 will be shown for the 9.2.1.3 Step definition | Define statement of step 3.
 
The default step title and description are as below:
  • Step Title: “Disconnect all sources and secure against reconnection”
  • Statement Description: “Equipment must be disconnected from all possible points of supply and secured against reconnection”
 
SWMS - Step 4
9.3.1 Step 4
Top title and description can be edited like step 1, right panel will reflect the value of the left panel but can't be edited.
 
Remove the comment column from both sides (this is an error in design).
Checkbox should be there in left side table for all rows, and we should have a delete button in bottom(next to back). Select checkbox and delete should delete that item from the table.
 
When we click on the Add new item button, screen 9.3.1.1 Step 4 | Modal will show up.
 
SWMS - Step 5
Step 5 layout, flow and functionality will be the same as step 2 except that:
  • The “Define SLD View” Button will be hidden
  • Also we don't need SLD image to be shown, so only 1 panel would be there on the right side for this step (check 9.2.1.2 Step definition | Define statement).
 
The default step title and description are as below:
  • Step Title: “Carry out earthing and short circuiting”
  • Statement Description: “”
 
SWMS - Step 6
Step 6 layout, flow and functionality will be exactly the same as step 3.
 
The default step title and description are as below:
  • Step Title: “protect against adjacent live parts and take special precautions when close to bare conductors”
  • Statement Description: “”
 
SWMS - Step 7
9.4.1 Step 7
Top title and description can be edited like step 1, right panel will reflect the value of the left panel but can't be edited.
 
Multiple skills, certifications or signatory can be added here and can be removed by clicking the “X” delete button, this involves the following screens:
  • 9.4.1 Step 7 | Add Skill
  • 9.4.1 Step 7 | add certification: Whatever a certificate is uploaded, its name will come under Select Certificate dropdown.
  • Add Signatory: Design will be provided during the challenge, it’s going to be a small popup and is in scope of this challenge.
    • Signatory: a maximum of 5 Signatories can be added.
    • Each signatory will contain a signature image.
  • Work Permit is a static section on the right side for now, just follow the design to implement that.
 
Resource Requirements - Documents
9.5.1 Resource requirements | Documents
On click of Next from Step 7, this screen will come.
 
Checkbox should be there in left side table for all rows (missing in design but need to be implemented), and we should have a delete button at the bottom (next to back) that’s only enabled when at least one row is selected, when clicked that should delete selected items from the table.
 
Format column will always just show PDF and only PDF can be selected to upload.
 
9.5.1.1 Resource requirements | Add Documents
User can add document.
 
Resource Requirements - Consumables
9.5.2 Resource requirements | Consumables
On click of Next from Documents or by clicking the tab header, this screen will show up.
 
This is a simple table similar to the documents one, same requirements apply (checkboxes, delete button, etc..)
 
9.5.2.1 Resource requirements | Add Consumables
User can add consumables.
 
Resource Requirements - Equipments
9.5.3 Resource requirements | Equipments
On click of Next from Consumables or by clicking the tab header, this screen will show up.
 
This is a simple table similar to the documents one, same requirements apply (checkboxes, delete button, etc..)
 
9.5.3.1 Resource requirements | Add Equipments
User can add equipments.
 
Work Method Statement (WMS)
9.6.1 Work method statement
9.6.1.1 Work method statement
 
This screen shows up when users click Next from Equipments screen. Right side will reflect what’s entered on the left panel and is not editable. The left / right arrow icon should work like the other steps (example: step 2).
 
There are 3 types of statements there, based on the selection of Statement type fields will be populated.
  1. Information: it's the first one, multiple images can be uploaded here. In this case only description box will come.
  2. Instruction: In this case, we can select the number of steps.
  3. Capture: In this type we can capture multiple type of values.
Category, Subcategory, Property and their respective values for “Type of input” and “Acceptance Criteria” will be loaded from JSON which we will provide.
 
Type Of Input:
  • Data Entry
  • Enumeration
  • Upload File
  • Number
 
Acceptance Criteria: values are coming from JSON.
 
Client Specific Requirements
1. Avoid ngx datatable for records display.
 
2. Please tell your developers to use the below example as reference.
Implement bootstrap in all pages – i.e. use the 12-column grid layout provided by bootstrap.
 
<div class = col col-sm-6 col-md-4 col-lg-3 col-xl-3> </div>
 
Col - screen size < 576px
SM - ≥576px and < 768px.
MD - ≥768px and < 992px.
LG - ≥992px and < 1200PX
XL - > 1200PX.
All pages must be responsive.
 
3. Support for the following browsers Chrome , Safari and Internet explorer-11 and above.
 
4. We need to make sure all the screens (except SLD) are responsive (bootstrap enabled) . Also there is no restriction on the size of the screen like 760PX etc.
 
In short they must be responsive using Bootstrap and should adapt to screens size.
 
Important Requirements
  • Bootstrap 4 should be used
  • Prototype should use configurable field names and validation messages (Key and Values are Defined in JSON file)
  • Properly implement internationalization-i18n. Please define the mechanism and provide all resources in English. Make all messages, labels, etc configurable. Please follow the same approach we have done in the base code.
  • Implement field level validation (error message should be displayed below the mandatory fields)
  • Show loading spinners when populating data from API / local JSON to UI
  • Implement popup for confirmation and warning messages. Do NOT use browser alerts, but use custom styles popups like the ones we have in the prototype
  • No linting errors
  • No errors with prod builds
 
General Requirements
  • Must use Angular 6 and follow the provided design.
  • The main content should have fluid width to fill all the available space.
  • Pagination should work whenever applicable.
  • Must follow Angular best coding practices
  • You are expected to create a detailed README file including information on how to setup, run and verify your application.
 
HTML Requirements
  • HTML should be valid HTML5 compliant.
  • Provide comments on the page elements 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 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.
 
Code Requirements
  • 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.
  • Do not create a single .css/.scss file for the whole app. Each component should have its own stylesheet file.
  • Ensure that there are no lint errors.
  • All CSS naming should not have any conflicts.
  • You’re free to choose between CSS & SCSS but you need to use flex instead of float.
  • Follow a clean folder structure.
  • Use CSS3 Media Queries to load different styles for each page and don't build different page for different device/layout.
  • Use CSS to space out objects, not clear/transparent images (GIFs or PNGs) and use proper structural CSS to lay out your page.
  • Make sure npm run build works without any errors.
 
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 and free for commercial use. MIT and Apache v2 licenses are ok, for any others please check with us to get 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.
 
Browser Requirements
Windows: IE 11+, Chrome Latest, Firefox Latest
Mac: Safari Latest, Chrome Latest, Firefox Latest
Tablets: Safari / Chrome on iPad, Chrome on Android Tablets

Final Submission Guidelines

What To Submit
  • Full code that covers all the requirements.
  • A detailed README file including information on how to setup and run your application.

ELIGIBLE EVENTS:

Topcoder Open 2019

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30084190