Challenge Overview
Welcome to the Mjolnir Web App Prototype Challenge #3. In this UI Prototype Challenge, we need your help to create a responsive HTML5 prototype for our client’s web application. This is the continuation of a previous challenge but you don’t need to have joined the previous one in order to complete this competition. You are provided with a baseline code and new features to develop.
Tips for Success: Asking questions early and getting Copilot or PM's feedback is very important for the success of this challenge.
Background Overview
Dental offices and patients meet the ultimate application to help them finding the perfect match for their needs! We leveraged the Topcoder community to come up with a fun and engaging design in earlier challenges. Now, we want to translate the design into a responsive UI prototype. This is the first out of the two challenges that we’ll be running to build out the UI prototype.
Application Users
The application will be used by two types of persons, employer (also referred to as business user) (dental practical office) and employee. Both of them are searching for matches to either hire or to be hired respectively.
Note that an application user can be both dental practical office and employee at the same time.
Assets provided in Forums (available on registration)
- Prototype.
- MarvelApp Link.
- Design Sources
Primary Goal
- Create desktop UI Prototype based on provided designs.
- Please match the storyboards as close as possible.
- Please comment your HTML/JavaScript/CSS/etc code. We need a clear explanation of the code to help us figure all the code functions and make it easier for future developers and the client to understand what you have built.
Target Devices
- Desktop: only for the web app.
- Mobile: phones only (see requirement #8).
Competition Task Overview
The main task of this competition is to develop a desktop HTML5 prototype based on the provided storyboard designs. Your prototype must work properly in all the required browsers.
On this challenge we are focusing on completing the employee profile pages and the mobile landing page.
Screen Requirements
Overall
- Only screens mentioned below are in scope for the challenge - see this folder for specific screens in scope.
- Replicate the design of the approved Storyboards (PSD or Ai Files) for all pages mentioned below.
- Your pages must match the colors and structure of the provided storyboards.
- Ensure your pages display correctly in all browsers. It is your responsibility to make sure the pages display correctly.
- Data for UI (forms, details views, etc) should come from JSON in order to easily integrate with API responses.
- Ensure your submission clear of HTML and CSS Validation error and warning.
- Test in all the required browsers.
- At this stage, we need to show both employer and employee role pages. Mock up the authentication mechanism in order to see both workflows separately. Create a fake employee login for the employee role, right now, there's a fake login for employer role (sss@sss.sss / sss). Make sure to document this in the README file.
- The following command must not generate any errors `ng build --prod`.
1. Employee Notifications
- See Employee folder, screen from 4.1 to 4.6 screens.
- This functionality already exists for the Employer profile. It’s mostly content replacement for the Employee user view.
- Notifications must still support online mode (small flying popouts from the right) and offline mode (overlay from bell icon on the top right).
2. Employee Main Menu
- See Employee folder, 2.5 menu screen.
- Activities, settings, offices pages and functionality are the same as the existing Employer profile (just create them and adjust for the Employee user view).
- There is a design inconsistency. The user picture and data should correspond to the header, it should be Ricky Cardenas instead of Lyanna.
3. Employee Benches
- See Employee folder, from 2.3 to 2.5 bench screens.
- Benches pages and functionality are the same as the existing Employer profile (just create them and adjust for the Employee user view).
- In bench expanded view (2.4) update the images so they match the storyboard.
4. Employee Search
- See Employee folder, from 3.0 to 3.5 search screens.
- Search pages and functionality are the same as the existing Employer profile. Make sure to update/replace the content for the Employee user view.
- Tabs read friends and opportunities for Employee user (instead of potential hires - design typo)
5. Employee Friends
- See Employee folder, screen 2.2.
- Friends pages and functionality are the same as the existing Employer profile (just create it and adjust for the Employee user view).
6. Employee Profile - viewed by Employee (edit mode)
- See Employee folder, screens 5.3 to 6.3.
- Profile page and functionality work very similar to the existing Employer profile. Make proper adjustments for this Employee user view.
- The text fields shouldn’t be editable until the user presses the edit pencil as in the employer profile edit mode.
- Boost overlay shouldn’t have blurred background, it should follow the same one as the Employer (design inconsistency, please fix).
7. Employee Profile - viewed by Employer (read only)
- See Employee folder, screen 5.1.
- Profile page and functionality work very similar to the existing Employer profile. Make proper adjustments for this Employee user view.
- In the current employer dashboard page (/profile route), clicking on a card should open 5.1 mentioned here.
8. Mobile Landing Page
- See 0.6 and 0.7 screens.
- The mobile landing page will be displayed only when the device is a mobile phone browser, Android (screen 0.6) or iOS (0.7). Create the proper script to handle this behaviour in the home page for the desktop webapp home (detect device > display android or iOS respective versions of the page).
- The mobile landing min-width is 375px. It must cover up to 480px wide (fluid width).
- Notice this mobile landing page is not the responsive equivalent of the desktop webapp. Meaning that if you open the webapp from a desktop browser at a low width (e.g. 400px) it should still display the original webapp version, no changes to that behaviour needed.
- Clicking on “View Full Site” will allow the user to use the desktop webapp zoomed out.
Specific HTML/CSS/JavaScript Requirements:
HTML/HTML5
- 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 on the scorecard.
CSS3
- 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 creating 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
- It is mandatory to use Angular 2.0 for this challenge. Please use Angular CLI - clean scaffolding. Tests are NOT required.
- All JavaScript must not have a copyright by a third party.
- It is fine to use GPL/MIT/Open Source code.
- 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.
Browsers Requirements (Latest versions of)
- Chrome
- Safari
- Firefox
- IE11 and Edge
Tips for Success: Asking questions early and getting Copilot or PM's feedback is very important for the success of this challenge.
Background Overview
Dental offices and patients meet the ultimate application to help them finding the perfect match for their needs! We leveraged the Topcoder community to come up with a fun and engaging design in earlier challenges. Now, we want to translate the design into a responsive UI prototype. This is the first out of the two challenges that we’ll be running to build out the UI prototype.
Application Users
The application will be used by two types of persons, employer (also referred to as business user) (dental practical office) and employee. Both of them are searching for matches to either hire or to be hired respectively.
Note that an application user can be both dental practical office and employee at the same time.
Assets provided in Forums (available on registration)
- Prototype.
- MarvelApp Link.
- Design Sources
Primary Goal
- Create desktop UI Prototype based on provided designs.
- Please match the storyboards as close as possible.
- Please comment your HTML/JavaScript/CSS/etc code. We need a clear explanation of the code to help us figure all the code functions and make it easier for future developers and the client to understand what you have built.
Target Devices
- Desktop: only for the web app.
- Mobile: phones only (see requirement #8).
Competition Task Overview
The main task of this competition is to develop a desktop HTML5 prototype based on the provided storyboard designs. Your prototype must work properly in all the required browsers.
On this challenge we are focusing on completing the employee profile pages and the mobile landing page.
Screen Requirements
Overall
- Only screens mentioned below are in scope for the challenge - see this folder for specific screens in scope.
- Replicate the design of the approved Storyboards (PSD or Ai Files) for all pages mentioned below.
- Your pages must match the colors and structure of the provided storyboards.
- Ensure your pages display correctly in all browsers. It is your responsibility to make sure the pages display correctly.
- Data for UI (forms, details views, etc) should come from JSON in order to easily integrate with API responses.
- Ensure your submission clear of HTML and CSS Validation error and warning.
- Test in all the required browsers.
- At this stage, we need to show both employer and employee role pages. Mock up the authentication mechanism in order to see both workflows separately. Create a fake employee login for the employee role, right now, there's a fake login for employer role (sss@sss.sss / sss). Make sure to document this in the README file.
- The following command must not generate any errors `ng build --prod`.
1. Employee Notifications
- See Employee folder, screen from 4.1 to 4.6 screens.
- This functionality already exists for the Employer profile. It’s mostly content replacement for the Employee user view.
- Notifications must still support online mode (small flying popouts from the right) and offline mode (overlay from bell icon on the top right).
2. Employee Main Menu
- See Employee folder, 2.5 menu screen.
- Activities, settings, offices pages and functionality are the same as the existing Employer profile (just create them and adjust for the Employee user view).
- There is a design inconsistency. The user picture and data should correspond to the header, it should be Ricky Cardenas instead of Lyanna.
3. Employee Benches
- See Employee folder, from 2.3 to 2.5 bench screens.
- Benches pages and functionality are the same as the existing Employer profile (just create them and adjust for the Employee user view).
- In bench expanded view (2.4) update the images so they match the storyboard.
4. Employee Search
- See Employee folder, from 3.0 to 3.5 search screens.
- Search pages and functionality are the same as the existing Employer profile. Make sure to update/replace the content for the Employee user view.
- Tabs read friends and opportunities for Employee user (instead of potential hires - design typo)
5. Employee Friends
- See Employee folder, screen 2.2.
- Friends pages and functionality are the same as the existing Employer profile (just create it and adjust for the Employee user view).
6. Employee Profile - viewed by Employee (edit mode)
- See Employee folder, screens 5.3 to 6.3.
- Profile page and functionality work very similar to the existing Employer profile. Make proper adjustments for this Employee user view.
- The text fields shouldn’t be editable until the user presses the edit pencil as in the employer profile edit mode.
- Boost overlay shouldn’t have blurred background, it should follow the same one as the Employer (design inconsistency, please fix).
7. Employee Profile - viewed by Employer (read only)
- See Employee folder, screen 5.1.
- Profile page and functionality work very similar to the existing Employer profile. Make proper adjustments for this Employee user view.
- In the current employer dashboard page (/profile route), clicking on a card should open 5.1 mentioned here.
8. Mobile Landing Page
- See 0.6 and 0.7 screens.
- The mobile landing page will be displayed only when the device is a mobile phone browser, Android (screen 0.6) or iOS (0.7). Create the proper script to handle this behaviour in the home page for the desktop webapp home (detect device > display android or iOS respective versions of the page).
- The mobile landing min-width is 375px. It must cover up to 480px wide (fluid width).
- Notice this mobile landing page is not the responsive equivalent of the desktop webapp. Meaning that if you open the webapp from a desktop browser at a low width (e.g. 400px) it should still display the original webapp version, no changes to that behaviour needed.
- Clicking on “View Full Site” will allow the user to use the desktop webapp zoomed out.
Specific HTML/CSS/JavaScript Requirements:
HTML/HTML5
- 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 on the scorecard.
CSS3
- 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 creating 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
- It is mandatory to use Angular 2.0 for this challenge. Please use Angular CLI - clean scaffolding. Tests are NOT required.
- All JavaScript must not have a copyright by a third party.
- It is fine to use GPL/MIT/Open Source code.
- 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.
Browsers Requirements (Latest versions of)
- Chrome
- Safari
- Firefox
- IE11 and Edge