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
There’s an important module called SLD (Single Line Diagram) editor in the tool, which is an editor used to create diagrams.
In the previous challenge, we have implemented the basic functions of the SLD editor using GoJS and a demo web app in Angular.
For the purpose of this challenge, we need the community to help polish the implementation and add more features. Please keep reading to find out details.
Technology Stack
Challenge Requirements
Fixes & Improvements
The following fixes & improvements are needed to the current implementation:
New Features
The following new features need to be implemented in this challenge:
General Requirements
The following requirements should already be covered in the previous challenge, just make sure you don’t break any of them:
HTML Requirements
Code Requirements
Javascript Requirements
Licenses & Attribution
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
Documentation
Register to download the following documents we provided in the forum
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
There’s an important module called SLD (Single Line Diagram) editor in the tool, which is an editor used to create diagrams.
In the previous challenge, we have implemented the basic functions of the SLD editor using GoJS and a demo web app in Angular.
For the purpose of this challenge, we need the community to help polish the implementation and add more features. Please keep reading to find out details.
Technology Stack
- GoJS
- AngularJS 6
- HTML5
- Javascript
- CSS
Challenge Requirements
Fixes & Improvements
The following fixes & improvements are needed to the current implementation:
- Get rid of the bottom panel and make the SLD editor full screen.
- When mouse is hovering on a widget, show the name of the widget as tooltip or using some kind of overlay text
- Ensure the submission works on all browsers mentioned in this spec
- Update the UI style so it’s clear which of IEC and ANSI is currently active
- Make text widget resizable
- Make the edit metadata popups more user friendly, they should not just clear or automatically change the values users enter even if they are invalid
New Features
The following new features need to be implemented in this challenge:
- When creating a new diagram, give it a new name, which will be used below.
- When a widget is added to the designer, assign a unique name to it (type + some unique id), this name will be used below.
- Implement the following right click menus in the workspace
- When user right clicks on empty work space of the design window (without no widget in selected state), context menu with the following items should appear:
- First menu item would show the name of the diagram:
- clicking it will bring up a popup dialog for user to edit the name for the diagram, and two buttons: Cancel and Submit. Menu should reflect the latest entered name of the diagram.
- Show grid:
- it should show the graph view on editor space (check our screencast to see how it works)
- Add label:
- We can add label on anywhere on workspace (check our screencast to see how it works)
- First menu item would show the name of the diagram:
- When user right clicks on empty work space of the design window (without no widget in selected state), context menu with the following items should appear:
- Implement the following right click menus on the selected widgets:
- First menu item would be show the name of the widget
- Clicking it will bring up a popup dialog for user to edit the name for the widget, and two buttons: Cancel and Submit. Menu should reflect the latest entered name of the widget.
- When multiple widgets are currently selected, this menu will say “Multiple equipments” instead and this option will be disabled
- Switch open / close if applicable to the widget, this menu is only enabled if only one widget that supports the statuses is selected
- This should work like the current tool (check our screencast to see how it works)
- Show / hide label
- This should show or hide the name of the widgets on the diagram (check our screencast to see how it works)
- Reliability figures, this menu should only be enabled if only one widget is selected
- It will open a popup which will show some static information, just show 3-4 labels showing some text info is enough for now.
- Simulate
- It will show 3 sub menus: Simulate clear fault, Simulate isolate fault, Simulate isolate for maintenance. For now it will just change the color of diagram (3 different colors)
- Select outage area
- We can draw outage area by selecting one or more equipments, outage area will appear in blue box (draw a rectangle to enclose the selected widgets)
- First menu item would be show the name of the widget
- Implement 3.2 from the specification. Please create all the menus present in spec but only the mentioned ones will be active:
- Equipment registry: Find equipment (Ctrl + F), It should find equipment from designer window and let user to go to that widget, implement name based search (check the screencast to see how current tool works)
- Configuration:
- Import SLD: Inactive Menu
- Export SLD (will export a static json file that we provide)
- Import equipment data: Inactive Menu
- Export equipment data (will export static excel file that we provide)
- Export SLD as image
- Print diagram (Ctrl + P): It's already done, just need to be integrated here
- Edit: most of these menus functionalities are already implemented, move them from current context menus here
- View:
- Implement Show in full screen, Show grid (Ctrl + G)
- Analysis: Just implement the inactive menus
- Help: sample text should come
General Requirements
The following requirements should already be covered in the previous challenge, just make sure you don’t break any of them:
- Make this editor reusable as an Angular 6 component, and demonstrate this using an Angular 6 based web app. We plan to integrate this editor into another bigger Angular 6 web app later so making it reusable / easy to integrate is important.
- You don’t have to worry too much about the overall look & feel of the editor / web app, just make sure the above mentioned features are working properly on a simple UI.
- 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 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. We should try to keep gojs core library untouched and only create extensions to support what we need.
- 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
- Developers need to follow GoJS licensing terms.
- 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
Documentation
Register to download the following documents we provided in the forum
- Widgets to be used in the editor
- Functional Spec for SLD (reference only)
- Screencasts of existing SDL Editor
Final Submission Guidelines
- Full updated code that covers all the requirements.
- A detailed README file including information on how to setup and run your application.