Challenge Summary
Welcome to the Cedar FROTZ Data Quality Assurance Admin Wireframe Contest! The goal of this contest is to build an Admin UI wireframe of the FROTZ Data Quality Assurance module. This module is currently pure back end service with no user interface, in short it only provides RESTful services. We want to build a graphical user interface for these RESTful services so that we can call the services on the website instead of writing codes.
At the end of this contest we are looking for a process flow, plan and layout design of the admin UI with the features mentioned in the contest details. Include your thoughts or notes to help improve the user experience.
Please note that this is the first Studio contest of the client, and we want to show them what TopCoder Studio can do for this Admin application so that they can show off to their superior and eventually keep using TopCoder for other UI projects.
Round 1
1) Intial wireframe of all the features mentioned in the Primary Goal
2) Any note for the client about your submission
Round 2
1) Final wireframe submission plus any Checkpoint updates
2) Any note for the client about your submission
Primary Goal
FROTZ is in the business of Content Ingest and Delivery (CID). The application has the purpose of storing in organized manner and delivering large amounts of content to its customers, it is intended to ingest, store, and deliver large and growing collections of digitized content to users and other applications the files and derivatives of files for publications. This application is broken into several modules, and one of the modules is DQA (Data Quality Assurance), as the name implies, it provides the data quality assurance part. Currently, this module only provides RESTful services with no graphical user interface.
The primary goal of this contest is to build the wireframe for the user interface of DQA module that would eventually utilize the mentioned services, this services are outlined in the provided Application Design Specification document.
Create the wireframe based on the provided Application Design Specification (ADS) and Application Requirements Specification (ARS) documents focusing on the REST API service found in ADS document, these are:
1. Entry Point
- this API service has no request field but it will return the URL to be used by the other services
- the return will be in JSON format with "URI" field for each "assertions" and "check"
- the URI value for "assertions" is used to list all existing assertions (GET) and add/update assertions
- the URI value for "check" is used to perform DQA checking.
2. Get Assertions
- the URL for this request is revealed from the Entry Point API request
- there are also no request field for this service
- this request will return all the assertions data
3. Define Assertions
- the purpose of this request is to Add or Update an assertion
- to add or update an assertion, the request will post an assertion class
- example of an assertion class can be found in the Appendix A section of the provided ADS document
4. Delete Assertions
- the purpose of this request is to delete an assertion
- the URI for this request including the identifier came from the "Get Assertion" API request
5. Perform DQA Check
- this request to create a DQA check transaction at the server side level
- the json format and its fields to do a request and the corresponding return format are defined in the Appendix A of the provided ADS document
Check the "Appendix A – Sample REST API Communication" section of the provided ADS document for sample of request body fields and returns of each RESTful service to further help you visualize what each request do.
Please note that ultimately, we want to have the best user experience with these RESTful services
Target Audience
- FROTZ Administrators
Judging Criteria
Your submission will be judged on the following criteria:
- User Experience
- Completeness and accuracy of the wireframe as defined in the requirements.
- How well your wireframes provide a consistent user flow
- How well you implement the required data and any suggestions, interactions and user flow you recommend (provide any notes or comments for the client)
Submission & Source Files
Preview Image
Create your preview image as one (1) 1024x1024 JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
Generated HTML files with all the requested contest requirements stated above.
Source Files
Wireframes should be built in Axure. The resulting files should have generated HTML files. Also, all the content must be listed and the pages are linked together to show page flow.
Final Fixes
As part of the Final Fix phase, you may be asked to remove, update, or change some features of the wireframe.
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.