Mercury Access Web Design Challenge

Welcome to “Mercury Access Web Design Challenge”! The goal of this challenge is to design the user interface for an administrator website that controls access between users and devices for desktop size.

We already have an existing wireframe, but we are looking forward to your UI and UX ideas to create an intuitive, elegant and easy to use application.

Round 1

Submit your initial designs for checkpoint review. Feel free to add any screens which are necessary to explain your concept.

1. Login
2. Register
3. Home
4. All Companies
5. Edit Profile
6. Administrators

Round 2

Submit your final designs plus checkpoint feedback implemented for the final round. Feel free to add any screens which are necessary to explain your concept.

1. Login
2. Register
3. Home
4. All Companies
5. Edit Profile
6. Administrators
7. Add Administrator
8. Keyholders
9. Keyholder Access History
10. Keyholders Locations
11. Devices
12. Register a New Device

Background Information
Our customer, Mercury, is offering key management solutions. They produce electronic keys that enable users to monitor entry to their locations and increase productivity. The inconvenience of having duplicate keys for several people is eliminated this way. The electronic keys are activated by PIN code. These keys can be a proprietary electronic device or a Key application running on a smartphone.

The applications for these keys are multiple: from access to different buildings, houses (real estate) to the automobile industry either for dealer managers or individual people, and even banks or ATM services. The keys let you know who opened the building entry / car and who was the last person that accessed them.

In this challenge, we are looking to create the wireframes for an application which will see which devices are accessed by which person and when. The application will have 2 personas: administrator and key holder. The admin will have access to all the system settings and configuration, while the keyholder is able to access a device through mobile only.

Glossary

• Administrator: has access to system, organization data, multiple site info, can define access permission for other admins, keyholders, devices and spaces. He can do any actions listed below.
• Keyholder (regular user/ individual): will have a mobile phone that needs to access the device. Depending on his permission, he might be able to add a new device and edit/delete it, and also create a space and edit/delete it
• Toolkit users are essentially a different type of customer using a "toolkit" to access their storage along with a phone. You can think of the ToolKit as an internet of things device
• Device: can be a door lock or padlock
• Space: is a group of devices. For example you might have access to a space which may include a main door and an office door. A space can have 1 or multiple users added to it.

User Story
Mike and his family (his wife Anna, and his kids Tim and John) are using the Mercury Keys. They have a house with 2 cars, 2 garages, a small office and several keys for each family member for the house and the garages. The keys can be accessed through a mobile application and on the electronic key based on credentials.

In this application we would like to be able to monitor and manage these users and devices/spaces, to see which member is accessing which item and when. Each member can name his device such as “Mike’s key”. The key will also have some unique identificator.  Mike will create a space for the house key where he will add all family members to it. He will aso create different spaces for the 2 garages, where he will add him and his wife to garage 1 (for their first car) and his both sons to garage 2 (for the second car).

The wireframes for this challenge can be downloaded from here or they can be seen on Marvel.

Note: we’d like to use the wireframe layout as it is - keep the same format and layout and reproduce the same functionality.

Below are the required pages for this application:

1. Login
This should be a simple page which will include the option to login with username and password.

2. Register
When registering, the user has to first validate his email by entering a code that was sent to him. After this he can register as usual, by showing a page where he can enter the name, phone number and password.

3. Home
The dashboard will show overall stats about the devices and controls such as:

• How many accesses happened in the last 24 hours
• Access history
• Overall stats of administrators, keyholders, devices and spaces
• Device Status and State
• Errors that appeared recently

Note: we would like to see the interactions displayed in wireframes as well such as hover actions for this page, top navigation elements and device access history.

Navigation: in addition to the elements shown in the side navigation, that you should add, we need to add another navigation item, called Access History. There is no need to show that page for the scope of this challenge (but that page will show the different devices accesses sorted by date from the latest one.

4. All Companies
This screen will have a list of all the companies using the Mercury’s keys with data about each and a map with their locations. Last access data will also be shown as per wireframes.

5. Edit Profile
On this page the user has the option to perform the following:

• Modify username to email address
• Add way to change email address
  • Verification email will be sent
  • Once verification is complete email will be update
• If Enabled as a Toolkit User
  • Show Toolkit Serial Number
  • Display mobile app download links  
  • Add a way to create a Toolkit auth code
  • Add a way to email the auth code

6. Administrators
Here we can see who all the administrators are and a few details for each of them:

• Creation date
• ID
• Name
• Email
• State (Active, Invited, Inactive, Disabled)
  • If disabled, show reason
• Status (show as Primary and Backup)
• Permissions
  • Administrators – Read/Edit
  • Keyholders – Read/Edit
  • Devices – Read/Edit/Configure
  • Spaces – Read/Edit
  • Configuration – Read/Edit

The user has the ability to filter the administrators.
The page will also show a way to get the most recent Administrator actions taken on the website see the most recent Access History.

7.Add Administrator
To add an Administrator, you enter the email address, name, permissions, toolkit enabled/disable, and click invite

If the user  is a toolkit user, we must be able to generate an auth code, and be able to email that auth code to the Administrator.

8. Keyholders
This page will show a list of the keyholders with different data for each of them:

• Creation date
• Key Serial Number
• Name
• Email
• PIN code
• State (Active, Inactive, Disabled)
• If disabled, show reason
• Status (show as Paid and Unpaid)
• Most recent device accessed (link to Access History)
• Associated devices
• Associated spaces
• Most recent access (link to access history)

Other Notes:

• Can only enable or disable a Keyholder – inactive is generated by system if the keyholder has not accessed a device in recent history
• A keyholder will have access to a device or a space
• We need to have the ability to generate and email an auth code to a keyholder
• Keyholder will have a key serial number too

9.Keyholder Access History
For a particular keyholder, we would like to see the history of the places he access such as locations and dates.

10.Keyholders Locations
Here we would like a way to display the last access location of the filtered Keyholders in the result set on a Google Map (This would be in a context where a family may share multiple access to different resources in different locations. It may also be looking to cover scenarios including remote opening)

11.Devices
This page will show a list of existing devices for a user.

• Ability to register device is only available to administrators that have Toolkit enabled
• Devices have:
• Registration date
• Serial Number (not editable)
• Name (editable, required, unique)
• GPS Location (editable, optional)
• List of associated spaces
• Last Accessed by (link to access history)
• State
  • Active
  • Unregistered
  • Tampered
  • Inactive
  • Low Battery
  • Error
  • Disabled
• Status (customizable/editable, show as Occupied, Available, Needs Maintenance)

12. Register a New Device
There are a few steps that are performed when registering a new device:
1. Create a new device by entering Device Name (required) and Description (optional)
2. Provide links to iOS App Store and Google Play Store, for download of installation toolkit mobile app, add option to email them the link to the app store
3. Display their PIN code and ask the user if they want to reauthorize their installer account:
   - If they do want to reauthorize, provide user with a new authorization code, DNS, and PIN code
4. Provide instructions on how to perform the device installation using mobile app
- Page will spin and check if device has been installed,
       -> If installed, show success and a link to the device details
       -> All user to go back to reauthorize and get mobile app

Branding

• Please follow the Mercury Style Guide and make sure to keep your design consistent. In terms of buttons and form elements you are free to improve them (make them more modern) but keep same color palette.

Size:
Desktop size -  width: 1400 px x height as much as needed

Target Users:
The customers who visit the site and want to find out more about our services

Judging Criteria
- User Experience of the application
- How exciting is the design looking
- Completeness and accuracy of your design

Stock Artwork (Photo and Icons)
Stock artiwork is allowed as per Topcoder rules (icons, photos).

Marvel Projects
If you need a Marvel project, please request in the forums.
You MUST include your Marvel app URL as a text file in your final submission labeled “MarvelApp URL” (in your marvel app prototype, click on share and then copy the link).

Final Deliverables