Challenge Overview
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
-
Google Docs / Word (To write the document)
-
Angularjs / Reactjs / “Component” based development experience
Code access
No code here. We will share the design assets 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 Review Process UI in the contest forum. Scorecard UI is not in scope for this contest.
-
Your task is to prepare a document in Google Docs where you have identified each UI component that needs to be implemented. In other words, think like an Angular or React developer and come up with components that the UI needs to be broken down into.
-
Each component that you identify should have the following details in the document:
-
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 need to organize the document logically too. How you would organize it is left to you. Some approaches that come to mind (you are free to go with a different approach too as long as it is organized well) that you can choose from:
-
Start with a “group”. List all basic components in this group. Next start off with another group that builds off the components from the basic group… and so on.
-
Write each component one by one, starting off with the component that has no dependencies and then describing components that are dependent on these earlier components and continuing in that manner until you finally end up with the topmost component - the entire app.
-
Considering that there’s a component hierarchy, you can start off with either the top-to-bottom approach or the bottom-to-top approach.
-
-
Only the design shared in the contest forum is in scope.
Deployment guide and validation document
There isn’t anything to deploy or validate. No additional documentation expected.
Important Notes
-
You will NOT implement any of the components, only identify them for now.
-
The expectation from your Google Doc 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 your Doc 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 are not obligated to use Google Doc. Microsoft Word or any document that results in PDF Is also fine. Excel / Google Sheets is also fine
-
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.
-