Register
Submit a solution
The challenge is finished.

Challenge Overview

Project Overview
 
Our partner is developing a state-of-the-art tablet based sales and order processing tool. Their sales team will be managing client visits, tasks, calendars, notifications, and order processing all through this tool. The platform is the Apple iPad. Want to learn Swift? Great - why not get paid for it, we need your help! There will be a long series of challenges over the coming weeks leading to the final product, so get involved now!
 
Setup
 
In order to obtain the code source to modify for this challenge, you will need to be added to the UNI-Mobile github repository. Make a request for access in the forums.
 
This contest will not require you to do any direct work with the Salesforce Mobile SDK, but it is a required element of the overall application. As such you will need to be able to login to Salesforce the first time you run the application in order to access the other components of the application. The credentials are as follows:
  • Username
    • cu@tc.com
  • Password
    • TCContest1
 
Again, you will not be required to utilize the Salesforce Mobile SDK for any of the customization you are doing in this challenge. But the application leverages it, so logging in is essential.
 
Contest Requirements
 
For this contest you will be required to create the Sales Manager Home Page, which is largely a modification of the already created Seller Home Page. The two have a number of smaller differences, but the user of the application will be directed to one or the other based on which type of user they are.
 
You will also be asked to create a collection of new ModalView windows for the “Coach To Win” functionality. This includes 3 different materials modals, that largely look like the previously created Presentations modal with minor changes - “Set Expectations”, “Progress/Performance”, and “Coaching Tools”. Additionally you’ll be creating a workflow of Modals for “Ride Along Evaluation”, which will be detailed in the detailed requirements below.
 
Detailed Requirements
 
Sales Manager Home Page
 
The Sales Manager Home Page features a number of small differences between itself and the Seller Homepage. Here is a detailed list:
  • Header Label - should be “Manage My Team”
  • To-Do List
    • No longer a collection of To-Do objects, is now just a large block UITextArea object
    • All Text typed in here should be persisted so that on start-up of the application, it shows the state that it was in when it was closed last.
  • Calendar
    • Filters removed. Only two buttons displayed
      • Today
        • When pressed, select today’s date as the active date for the calendar.
        • If today’s date is not in the currently selected month, change the month to today’s month.
        • If today’s date is not in the currently visible portion of the UICollectionView for days, scroll such that it is as close to centered as possible. e.g. Dates such as 1 or 31 that would require overscroll to be cenetered should only scroll to the begging or end of the collection.
      • Open All
        • Use the same interaction as on the Seller Homepage.
    • New Cell Type - Open Time Block
      • Make these visually match the cells shown in the UI Mockup.
      • These cells should be calculated by the Calendar View anytime that a date is selected.
        • From 00:00:00 (12:00 AM of the selected date) to 23:59:59 (11:59 PM of the selected date)
        • Sort Events chronologically by Start Date/Time.
        • Any stretch of time that does not have events should be designated as an Open time slot.
          • For instance if I have 3 events - 1 starting at 8:00AM and lasting 30 minutes, 1 starting at 9:00AM and lasting 90 minutes, and 1 starting at 4:00PM and lasting 120 minutes - I should end up with the following 4 open time blocks: 12:00AM - 8:00AM, 8:30 AM - 9:00AM, 10:30AM-4:00PM, 6:00PM to 12:00AM (when displaying, round 11:59:59 to 12:00AM of the next day).
      • Open Slots should render in order with the Events, with Tasks displayed below all time slots.
  • Sidebar
    • The Core Values and Our Promise Buttons should remain as they are on Seller Home page
    • Panel 1 - MGMT Tools
      • Coach To Win
        • Set Expectations
          • Open Set Expectations Modal
        • Coaching Tools
          • Open Coaching Tools Modal
        • Ride Along Evaluations
          • Open Ride Along Evaluations Modal #1
        • Progress / Performance
          • Open Progress / Performance Modal
      • Team Training
      • On Boarding
      • Recruiting
      • Nat. Acct. Database
    • Panel 2 - Analytics Tools
    • Leads (Same as Seller Home Page)
    • Approvals (Same as Notifications on Seller Home Page)
  • Global Menu Options
    • Search
      • Same as it does on Seller Home Page
    • Presentations
      • Open the Presentations Modal
    • Prospecting
      • Same as it does on Seller Home Page
    • Gmail
      • Same as it does on Seller Home Page
    • Calendar
      • Same as it does on Seller Home Page
    • Connect
      • Chatter
        • Same as it does on Seller Home Page
      • Google Hangout
        • Same as it does on Seller Home Page
    • Create New
      • Quote
        • Same as it does on Seller Home Page
      • Ccount
        • Same as it does on Seller Home Page
    • KPI
      • Same as it does on Seller Home Page
    • G+K
    • Contests
    • Manage Login
      • Display a UIPopover with a UIPickerView that displays a list of names.
      • “Myself” should always be an option.
      • This popover should reflect the design depicted in the mockup.
      • Maintain state of selected User on the Global Menu View Controller.
      • When the user clicks Save
        • If selected user has changed since last save
          • Close the popover.
          • If selected user is not “Myself”, open the Seller Homepage instead of the Sales Manager Home Page in the Global Menu’s Main Content Area
          • If selected user is “Myself”, open the Sales Manager Home Page in the Global menu’s Main Content Area.
        • If selected user has not changed since last save close the popover.
      • When the user clicks cancel, close the popover.
    • Home
      • If selected user is “Myself” go to Sales Manager Homepage in the Main Content Area of the Global Menu.
      • Else, go to the Seller Homepage in the Main Content Area of the Global Menu.
 
Set Expectations Modal
 
This modal is identical to the “Presentation” modal, except for the page title should be “Set Expectations”, and that there should be no filters, or key to denote between read only / template items.
 
Coaching Tools Modal
 
Ths modal is identical to the “Presentation” modal, except for the title is “Coaching Tools”.
 
Progress / Performance Modal
 
This modal is identical to the “Presentation” modal, except the title is “Progress / Performance” and there should not be a search or filter options.
 
Ride Along Evaluation
 
This modal is going to be more similar to our Fit Session modal in that there are multiple flows involved with this modal.
 
When called, it should slide in from the bottom, and start with only the “Ride Along Evaluations” label, and a drop select for the user to choose one of their Team Members. Use the same drop select control as used in the other screens of the applications.
 
The ideal implementation for this screen is to have a scroll view in the entire area beneath this original drop select, with roughly 15pts of padding beneath it. We will load other views into this Scroll View.
 
When a Team Member is Chosen:
 
Create a function to handle the post-Team Member selection setup. In this method, generate dummy Evaluation History data (Date, Account Name, Type [Approach, Discovery, Present/Close, or Install Prep]) to show in the Evaluation History table. Then display the Evaluation history table, and the “Select a Ride Along Form To Complete” drop select. The options for the Select a Ride Along Form to Complete drop select should be “Select a Ride Along Form to Complete”, “Ride Along - Approach”, “Ride Along - Discovery”, “Ride Along - Present/Close”.
 
The Evaluation History Table should be able to stretch to the bottom of the screen, if it would overflow here, it should scroll within itself - the header of the table should not. The columns should be sortable. Date should go chronologically, Prospect / Account should be Alphabetically by Account Name, and Type should be ordered Approach > Discovery > Present/Close > Install Prep or in reverse. The Scroll View that Evaluation History should display in,  should not scroll in this case.
 
If any row is tapped, another modal window should slide in overtop of this one. This new modal should be pointed at http://www.salesforce.com.
 
When a Ride Along Form is Chosen:
 
Create a function to handle the post-Ride Along Form selection setup. This function should be called only when the actual selected value is changed. Do nothing if the user opens the drop select and dismisses or chooses the previously chosen option.
 
In this function, if any option not “Select a Ride Along Form to Complete” is selected the lower section should be hidden, to be replaced with the respective form. A footer should now be displayed over the bottom of the modal that has a cancel button. When that button is pressed, change the selected value of the Form Select to “Select a Ride Along Form to Complete” and handle the change as normal.
 
If the “Select a Ride Along Form to Complete” option is selected, the lower section should be hidden, and replaced with the Evaluation History displayed originally when the Team Member was chosen. The footer should be hidden.
 
The Forms
For the purposes of this UI Prototype, all of the forms should be built with the same questions and fields. If these will need to be different in the integration, the changes will be defined then. The only major differences for this UI Prototype is the label text should be “Ride Along - Approach”, “Ride Along - Discovery”, “Ride Along - Present/Close” respectively.
 
These forms should scroll within the parent Scroll View.
 
On each of these forms, Prospect Name will be a type-ahead assistive search field. As you type, an action to search should be done in the background. For the purposes of this prototype, fake this by returning the same list of string results regardless of what the user has typed. When the results come back, they should be displayed in a popover-type overlay beneath the text, with 5 results visible and the ability to scroll for more.  While the popover is displayed, the user should still be able to type. When any row of the suggestions is tapped, replace the text within the Prospect Name text field, and dismiss the keyboard.
 
The Date field should display a Date Picker as used on other forms throughout the app.
 
Beneath the Prospect Name and Date fields, build the Rating Key view in the left column as shown in the mockup. This corresponds to the reusable Rating Question item that you will need to build for the forms.
 
Rating Question Object
  • Should have a configurable Question String to display in the left portion.
  • Should have 4 tappable buttons going from black to a light gray in a progressive gradient in their inactive states
  • The active state for all of these buttons is Red backgrond with White Text.
  • When one of these buttons is tapped, all other buttons in the rating question should be set to their inactive state, and the tapped item set to red.
  • The Rating Question object should have a property for retrieving the selected value.
 
Questions
  • Left Column
    • Preparation
      • Utilized Salesforce to plan the call or meeting
        • Rating
      • Had all necessary tools & support material
        • Rating
    • Presentation
      • Matched solutions to the prospect’s expressed needs.
        • Rating
      • Linked solutions to the prospect’s task & personal motives
        • Rating
      • Utilized appropriate presentation format and support materials
        • Rating
      • Utilized appropriate presentation format and support materials
        • Rating
  • Right Column
    • Two things that went well:
      • UITextArea
    • Two things that could be improved:
      • UITextArea
    • Result of the call or meeting:
      • UITextField
 
When any field is changed, fire a validation step to see if all form fields have been input. If they have, display the Next button on the Footer of the modal window.
 
When “Next” is tapped, display the min-Dialog “Send A Private Message To Your Team Member”.  If the user taps the X on this modal, simply hide that modal and allow them to continue editing. If they click “Share This”, call a method to serialize the form values into a Dictionary object, and then hide the mini-modal and transition the user within the Ride Along Modal to the Confirmation Screen.
 
Confirmation Screen
 
This screen should be rendered to appear as shown in the Mockups. The name “John Snow” should be replaced with the name of the Team Member from the previous screen.
 
All Red text on this page should be a button.
  • Name
  • Create a related To-Do for this team member
    • Pass the value of the Team Member to the Team Member To-Do modal.
  • Return to Ride Along Evaluations
    • Transition the user to the beginning state of the Ride Along Evalution modal (option to select Team Member).
  • Return to Home Screen
    • Close this modal.
 
Team Member To-Do
 
Render the form as shown here. All drop selects will be defined in the Integration phase of this screen. For now, Display “Acme Subject 1” “Acme Subject 2” … etc for the options.  “Create a New To-Do for John Snow” should display the Team Member’s name rather than “John Snow”.
 
When the user clicks cancel if they have input any information, display an alert “Are you sure you want to cancel this To-Do?”, if they confirm dismiss this modal otherwise stay on it. If the Save button is tapped, call a method that would be used to save the To-Do, and then dismiss this modal.
 
General Guidelines
 
The Data Model objects referenced in this challenge should all be created in the Model subproject within the UNI Repository. If you have any questions, please ask in the forums, we will help you determine if additional objects not pre-built may be necessary.
 
“?” icons will trigger tooltips (style defined previously) with two sentences of lorem ipsum (to be edited later).
 
For this challenge if you would like to pull in third party form generation frameworks, that is allowable in order to satisfy any requirements asking for ease of configuration or reusability. If you do incorporate 3rd party frameworks for the construction of these forms, please ensure that these frameworks are Open Source software, and are available with an MIT or similar distribution License. Code submissions that use 3rd party frameworks will be judged based on the ease of use and extensibility of those frameworks.  
Environment Setup
 
GIT: The project will use a code repository at Github, please see additional details and participant responsibilities under Submission Guidelines.
 
Xcode: All code development should be done in Xcode 6.1 and tested in the simulator.
 
Framework: Code should be developed with the Cocoa Touch framework using Swift and must compile against iOS SDK 8.0 with a deployment target of iOS 7.1.
 
Get Started
 
- Request access to the project in the challenge forums
- Fork this project: git@github.com:cloudspokes/UNI-mobile.git
- Checkout this branch: https://github.com/cloudspokes/UNI-mobile/tree/workstream5-mgrhome
- Write and submit your code as a zip file


Final Submission Guidelines

Submission Guidelines
 
- Cocoa Touch framework Xcode 6.1 project with well commented code
- Code must compile against iOS SDK 8.0 with a deployment target of iOS 7.1
- Upload all source projects as a zip
- After submission phase has completed, make a pull request targeting this branch
- Provide documentation of any special configuration required to run your code.
 
GIT Guidelines and Requirements

All code for this project will be maintained at Github. Challenge participants will have to request read-only access to the repository during the challenge and are expected to fork and do their coding on the challenge branch. Once contest submission closes, the project owner will update the code in the challenge branch to reflect the current state of development. The winner of the challenge will then be required to update their fork to the current state of the development repository and will be responsible for handling merge conflicts when updating their fork. They will then create a pull request.

ELIGIBLE EVENTS:

2015 topcoder Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30048122