Build a Hybrid Mobile App to provide an immersive Support Experience

Requirements

 

The objective of this contest will be to deliver the following key requirements:

 

1. A Krakenjs (server) , MongoDB (data store), Angular.JS (webviews/interfaces) application. You can build this on a Heroku instance or provide your submission with instructions to build/deploy/configure as part of your submission if you do this on your standalone systems. Krakenjs is an opensource framework extension of Node express.

 

2. The Data Model we need to build for this application will need to be as described here:

    Tables/Collections:

         - User {UserId, FirstName, LastName, SmallPhotoURL, FullPhotoURL, Email, MobilePhone, Title, UserProfile[Exec, SS, Admin], LanguageLocale, IsActive (Y/N), Confirm Code {unique}}

         - Request {ReqId, ReqType, ReqDetail, ReqLoc, ReqBy(User), ReqOwner(User), ReqStatus[Open,In Progress, Closed], ReqRating[1,2,3,4,5], ReqFeedback}

         - Request History (ReqId, StartTime, EndTime, ReqAction, )

         - Announcements (AnnId, AnnDesc, IsActive, LanguageLocale)

         - Configuration (ConfigName, ConfigValue) * Use this collection/table to manage the configurable Texts across the Application interfaces. (e.g. Canned values for commonly encountered issues, Canned values for frequently used status updates, etc.)

3. The Required interfaces expected for this Applications "Use Case Scenarios" are as described here:

 

1. Initial Setup / Onboarding the Users (Support Specialists and Exec Users)

 

 

 

2. SMS Flow

Ignore SMS Flow. Out of scope for this application.

 

3. OnSite Flow (Exec User Activity):

 

The entire application is focussed on providing the best User experience for the Exec user, and the following is the expected flow of events for a request originating from an Exec user:

 

a. An Exec User would use this Application as the entry point to requesting IT support, As noted above, the home page of the Application offers 3 paths, When they select the "Onsite" option, the user is presented with a view where they can either select from a list of commonly requested items for Support, or provide more information by typing into the Textarea box describing the help they need.

 

b. Given that this is onsite request, they would be able to provide their location too where they need support, the location would default to their current location (*which is likely to be the case most of the times), however, they also have the ability to provide a different location where they would like the support specialist show up for help.

 

c. User would then hit the "I'm ready" button, this is when the Request is created into the backend system, and an email alert to a "distribution list" (*mainly composed of the Support Specialist team) will be sent that a new Request has been created by "Exec User". This will prompt a Support Specialist to get into the App, and view the Request Queue (* Support Specialist Activity flow described below).

 

d. Assuming the Support Specialist has picked up the request, the Exec User (assuming they are on the application page), would be shown a "Request Status Page", which refreshes with updated Status values on the request as and when the Support Specialist updates the Request Status. This data is to be recorded in the Request History, and the Request should always show only the current Status.

 

e. Once the Support Specialist updates the last status on this request (i.e. I m here!), the view for the Exec user should switch to the "Visit Completed" view, where the Exec User would press the "Visit Completed" button acknowledging that the Support Specialist is with him now. This update is also to be recorded in the Request history.

 

f. Once Visit Completed is pressed, the view for the Exec user should present a Unique QR Code on the Interface, which is available for the Support Specialist to Scan to identify the unique Request, and mark it as "Closed". A Request can only be marked closed by the Support Admin or by scanning the QR Code generated on the requestors view, and needs to be scanned by the Support Specialist (Request Owner).

 

g. Once the Support Specialist has scanned the QR Code and hence marked the Request Closed, the Exec users interface will prompt the user to provide a Feedback / Rating for their Support experience.

 

 

 

4. Phone Flow:

Ignore Phone Flow. Out of scope for this application.

6. Support Specialist Flow:

 

a. A Support Specialist User would use this Application as the entry point to monitoring the Open Requests queue (* which they would be notified on everytime a new request has been logged). The Support Specialists home page always shows the Request Queue organized by "the latest Unassigned Open" requests first, followed by the "Assigned and Open" and then the "Closed Requests". This User may either Start on a request by clicking on the Start button next to the request in the list view, or they may Release a Request that is currently owned by them, just so that another Support Specialist can pick that up. Clicking on "Start" should set the Request history record with the appropriate status, and hence notify the requestors view too.

 

b. Given that this is onsite request, the Support Specialist would view the request detail for understanding the issue, and identifying the location they need to get to in order to support the requestor.

 

c. The Support Specialist on having "Started" the request is presented with a Request Status update view, where they would either be selecting a canned response to communicate to the requestor the current state of their request, OR they may simply type in the message they want to communicate over the Status view. This shows up on the Requestors view as the "Date/time" - "Status Message".

 

d. Once the Support Specialist is there, and the Requestor has been presented with the "Visit Completed" view, the view for the Support Specialist changes to "Scan QR Code" to mark the request complete. Assuming all is resolved, the Support Specialist would scan the QR Code and the view on the Support Specialist would suggest requesting feedback, however no further action is required, and this would mark the end of the flow for the Support Specialist supporting the request.

 

 

 

6. Notifications Page:

Users may tap on the 'Notifications' alert blue strip at the footer of all the interfaces screens, this will navigate to a list view of Notifications page. These Notifications are managed by Support Admin, and the notifications presented on the pages should only show Active notifications.

 

7. Miscellaneous Tasks:

 

We would like to have this built out as a Single Page Application with directives and routes using AngularJS.

Model as many of the Application Text on the interfaces in the Configuration Object, such that they can be easily managed.

Google Maps: it should trigger the device "show user current location" alert.