Project Scorecard System | Identify UI Components | Part 2

Challenge Objectives

• Identify UI components from a design that will eventually be implemented in a UI Prototype

 

Project Background

• This project is to create a UI for creation of Review Processes and Scorecards

• Some terminologies used in the project are as follows:

  • Event: An event is an activity that takes place, usually closely related to a contest in Topcoder. Example - Registration phase started / ended, User has uploaded a submission etc

  • Review Step: A review step can be thought of as an app that plays a role in reviewing a submission. Example - an anti virus scan app, the scorecard that is currently used in Online Review to judge submissions (Not an automatic reviewer, but a review app nevertheless), CheckMarx scanner, SonarQube scanner etc

  • Review Process: A review process consists of one or more events, which in turn consists of one or more Review Steps

  • Scorecard: The scorecard that you - the submitter - can currently see in Online Review. This is the scorecard that is used to judge submissions. A scorecard is a Review Step too but it has special mention here because it has a UI of its own.

• There are two aspects of the Project. One is the UI for Review Processes and the other is the UI for Scorecards.

• Let’s begin with explaining the UI for Review Processes:

  • The landing page for this UI will display the list of review processes that exist in the Topcoder system (all review processes, not just the ones that the user has created)

  • User can create a new review process, or edit / clone / delete an existing one.

  • A review process consists of events and review steps under these events

  • Each review process is applicable to only one track (Design, Development or Data Science)

  • User will be presented with an “editor” with the list of predefined events and review steps when they are working on the Review Process

  • User can drag and drop events into the editor and review steps under these events and thus create a review process, where the user describes what should happen when an event occurs. Example, on submission upload (the event), immediately proceed to check if the submission has any viruses (the review step), followed by whether the submission has any lint errors (imaginary lint checker - the review step). Thus, this review process as 1 event and 2 review steps.

  • Once the review process is set up, the user then gives it a title and some description and saves it.

• Now, the UI for the Scorecard process

  • The workflow is very much similar to the Review Process.

  • Here too, the user will see the list of existing scorecards and can edit / clone / delete them

  • A scorecard editor requires the user to first define a group, and then sections under this and then finally the questions under the sections. Each of them has a weight and the sum of the weights of the sections should always be 100 under any group. Similarly, the sum of the weights of the questions should also be 100 under any section.

  • The sum of the weights assigned to the group itself should be 100

  • For reference, you can look at the scorecard assigned to this contest and compare it with the design to get a better understanding

 

Technology Stack

• Storyboook

 

Code access

We will share the storybook created from Part 1 contest in the contest forum

 

Individual requirements

Before we go into the individual requirements, it is recommended that you go through the Project Background section above and view the design assets shared in the contest forum to understand the project (and thus the requirements of this contest) better.

Identify UI components from a design that will eventually be implemented in a UI Prototype

• We will share the designs for the Scorecard UI in the contest forum. Note that we have already carried out the same activity for the Review Process UI.

• Update the provided storybook with the components identified from the Scorecard UI designs,

• Each component that you identify should have the following details in the storybook:

  • A screenshot from the design identifying that component clearly

  • What you would name that component

  • The component props (we will implement the UI using Reactjs 16) and type of the props and description of the prop

  • The dependent components (Components that need to be defined already before one can define the current component)

• You are expected to follow the current convention used in the Storybook where we have reusable components and non reusable components, that are then used to build the final pages

• Only the design shared in the contest forum is in scope.

 

Deployment guide and validation document

The storybook can be deployed locally by following the instructions in the README file and no updates are expected here. No additional documentation expected.

 

Important Notes

• You will NOT implement any of the components, only identify them for now.

• The expectation from your identified components is that we should be able to immediately create tickets in Github / Gitlab for each component and follow the approach that you have mentioned in the storybook in implementing the components in React and complete each ticket one after another.

  • This is why it is important that you define any dependencies between components

  • This is also why you organize the components in a manner that makes it easier to determine which component needs to be implemented first, which one after that and so on.

• You are not expected to define the inner workings of the component (Example - how a drag and drop component needs to work, if a button component is clicked, which component gets hidden etc). Your description should only be cosmetic / UI specific only.

• You have to update the provided Storybook with the additional components identified in this contest. Do not create a new one.

• You have to go through the provided Storybook and not define duplicate components / components that already exist. You are encouraged to make use of components already identified.

• Make sure that any updates to existing components do not alter the component definition as identified originally for the Review Process UI

• Lastly, kindly update the existing Storybook to use version 5.2 (latest version)

• The contest will have subjective review. We will still have appeals and appeals response phases. The reviewers will score you on the basis of the following:

  • Identification of components logically (25% weight)

  • Identification of reusable components logically (15% weight)

  • Organization of the component list in a manner that clearly describes which component needs to be implemented first and clearly describing the dependencies of the components (40% weight)

  • Listing the details of the components (screenshot, name and props) (20% weight). Dependencies of the components are to be taken up in the earlier point and not under this review point.

Final Submission Guidelines

Kindly upload the updated storybook as a zip file