NASA HATTB Researcher Part 1 Wireframe Challenge Specifications

Welcome to the NASA HATTB Researcher Part 1 Wireframe Challenge!

The scope of this challenge is to create interactive wireframes for a software application to run tasks evaluating operator performance and workload.

HATTB (Human-Autonomy Teaming Task Battery) is intended to provide a simplified version of the real-world tasks performed by remote operators monitoring and controlling vehicles with varying levels of automation (a.k.a. pilots controlling drones). The primary use case for HATTB is a psychology researcher studying the performance of participants as they complete specific defined Scenarios. In the future, the application could be extended to many use cases outside of drone operation.

For this challenge we are looking for a true interactive wireframe solution to describe content and functionality. Your solution must allow interactive click-thru of functional elements and screens. The branding and visual design of the UI for this application will be addressed in future challenges.

Please read the challenge specifications carefully and let us know if you have any questions in the forums.

This is the first in a series of wireframe and UI design challenges to design a full software application. Jump in now to get a good start!

Round 1

Submit your initial wireframes for checkpoint review. Feel free to add any screens which are necessary to explain your concept.
1. Experiment Library View
2. Scenario Library View
3. Familiarization Library View
5. Experiment Authoring View

Round 2

Submit your final wireframes plus checkpoint feedback implemented. Feel free to add any screens which are necessary to explain yoI tur concept.
1. Experiment Library View
2. Scenario Library View
3. Familiarization Library View
4. Questionnaire Library View
5. Experiment Authoring View
6. Familiarization Authoring View
7. Questionnaire Authoring View

CHALLENGE OBJECTIVES

• Interactive wireframes for a responsive desktop application.
• Design for use only on Apple Mac computers (iMac and Macbooks). UI Design must follow Apple’s Human Interface Guidelines.
• Provide an end to end flow for the Researcher’s workflow as described in the specification.
• Important: Screenshots will be provided for understanding of the application, we are looking for your concepts and effective solutions to the functionality described (do not copy reference screen design)

APPLICATION OVERVIEW
With the HAATB application, researchers are able to conduct experiments that evaluate the performance of research participants as they monitor simulated autonomous objects. A Researcher is responsible for setting up experiments and configuring all the parameters for the tasks they wish to have included.

The overall interface should be as flexible as possible and have a modular approach to be easy to update in the future. The desired outcome is a software application which provides a simple, intuitive interface while offering an extensive set of highly configurable research capabilities.

• The majority of the application features are intended for the Researcher. With the application they will create experiments, manage multiple components and configure them for Participants to complete.
• The Researcher will have the ability to create new components or select from existing (Familiarizations, Questionnaires, Scenarios)
• To create a Scenario, the Researcher will use the application to plan and set-up multiple tasks for the Participant to complete. Each task will require various levels of automation and decision making. The application will allow the user to create extensive Scenarios with highly configurable variations.
• Functional Note: The application is NOT browser based, but operates locally on the target device. The software does not require an internet connection for any functionality, as the software does not connect to any servers. The only necessary connections are device-to-device and the various connection options associated with sharing files.
• Note on sharing: The format to be shared should be human readable (e.g. JSON, CSV) and editable outside of the software. Additionally,  users should be able to quickly determine that they have the same version of an element on separate devices (e.g. unique short code or word).

AUDIENCE
The full application will address two (2) user roles: Researcher and Participant.
This challenge will only focus on the workflow for the Researcher. The Participant role is described to give more context to the problem.

User Role 1: Researcher

• Background: Experimental Psychologist
  • Academic environment (professor or student)
  • Government or Industry (researcher)
• Age: varies
• Programming experience: minimal to extensive
• Requires interfaces for planning Scenarios and implementing experiments.

User Role 2: Participant (in future challenge)

• Background: Undergraduate Psychology Student
• Age: 20 years old average
• Aviation / Drone experience: none
• Video Game Use: avg. 9 hrs/ week
• Computer Use: avg 17-30 hrs/ week
• Requires interfaces to complete assigned experiment tasks.

PERSONA

• Name: Mica Garcia
• Occupation: Professor
• Goals:
  • Compile data based on their students’ (participants) performance with experiment tasks
  • Ability to easily customize the functionality included in the experiment Scenarios
  • Ability to customize the interface for their participants (move and resize windows, style elements, etc.)
• Frustrations:
  • There is not an existing tool which includes all the complex features Mica requires in one application
• Wants:
  • A single, easy to use application available for MacOS to execute research with their students. Have the ability to customize each experiment as needed.

USER WORKFLOW
Mica is using the NASA HATTB application to conduct research with their students. They are able to define an experiment with multiple sessions in specific order.

Each session consists of:

• A Familiarization view - This view gives the Participant information about the goal of the sessions, how their points are calculated and what they need to do.
• A Scenario view - This is where the intense action happens. A scenario consists of several tasks the participant will complete. There are a multitude of tasks and settings to choose from and customize. Tasks may happen one after the other or run in parallel, testing the user’s attention.
• A Questionnaire view - This is a set of questions presented to the participant to collect feedback. It may be presented before, during and/or after a scenario. Note: there will be multiple questionnaires per session (possibly in a combination of before, during, and after).

High-level workflow:

1. Author a new component (Authoring views of Familiarization, Scenario, Questionnaire)
2. Access existing components (Library views of Familiarization, Scenario, Questionnaire)
3. Arrange desired components into Sessions and Sessions into Experiments (Experiment Authoring view)
4. Select Experiment to configure and run with participants (Experiment Library view)

Mica creates a new Familiarization and a new Questionnaire to include in this experiment (6. Familiarization Authoring, 7. Questionnaire Authoring). Assume they have previously designed the detailed Scenario.

Mica is able to define a New Experiment by arranging multiple sessions in the sequence he prefers (5. Experiment Authoring, Session Library) .

Mica includes the new elements and some existing elements into a few sessions. To do this they will need to browse and select from the Library interfaces (1. Familiarization Library, the 2. Scenario Library View, and the 3. Questionnaire Library).

Once Mica sees that the Experiment includes the components desired, they have the ability to save and lock this experiment to prevent changes. There is an obvious link to see the newly created experiment on the landing screen (1. Experiment Library screen), and move forward to configure the experiment and start it for the participant.


GLOSSARY
Experimental psychologist =  a psychologist  who uses scientific methods to collect data and perform research (read more here).

Automation = a device or system that accomplishes (partially or fully) a function that was carried out (partially or fully) by a human operator

Task = a single display window (or element) that has a specific objective(s), which  requires the participant’s attention and interaction.  

Scenario = a predefined series of one or more tasks, which can be performed  simultaneously, consecutively, or as a combination of both.  

Familiarization = a view (or multiple views) shown to a participant immediately  preceding a scenario to provide specific information, examples, or training for the  participant.  

Questionnaire = a set of questions presented to the participant (before, during, or  after a scenario) to collect feedback from the participant.

Session = a predefined series of Scenarios, Familiarizations, and Questionnaires,  which must be completed by the participant sequentially (with a specific order). A  participant will complete a session from start to finish.

Experiment = a set of sessions and associated participant data collected from  completed sessions. Multiple participants may complete the same session within an  experiment.


SCREENS / FEATURES REQUIRED
The screens/features described below are required for the Researcher’s experience. They are based on the workflow described above. This Researcher Part 1 challenge will focus on the primary UI views, as well as some of the basic experiment set-up the Researcher will perform. Challenges to follow will focus on complex Scenario planning and the Participant views of the application.

Scope Note: For this challenge, we are only focusing on a portion of the Researcher workflow and NOT the Participant.

0. Global Elements

• NASA Logo: Use a simple placeholder in the wireframes
• Title: NASA Human-Autonomy Teaming Task Battery (may not need to display on all screens)
• Navigation: As needed. Users should have the ability to navigate through the application screens as needed according to the User Workflow and the screen requirements.

1. Experiment Library View
This view allows the researcher to browse all of the saved Experiments in a list/ grid format, each of them having the following details:

• Experiment name
• Date created
• Date last modified
• Participants numbers
• Status: locked/unlocked; completed/incomplete
• Options to:
  • Edit the experiment (takes user to: 5. Experiment Authoring View)
  • Delete the experiment
  • Duplicate an experiment
  • Share the experiment (see Notes on Sharing in Application Overview)
  • Create a New experiment (takes user to: 5. Experiment Authoring View)
  • Choosing to view the details of an existing experiment will take the user to a view to configure the experiment (Experiment View NOT IN SCOPE).

2. Scenario Library View 
This view allows the researcher to browse all of the saved Scenarios within an experiment. (It might make sense to have a folder structure to group these.)
Each scenario will have the following details:

• Scenario name
• Date created
• Date last modified
• Options to
  • Edit the scenario  (takes user to Scenario Authoring View NOT IN SCOPE)
  • Delete the scenario
  • Share the scenario
  • Duplicate a scenario
  • Create a New scenario (takes user to Scenario Authoring View NOT IN SCOPE)
  • Bulk Edit certain settings for all Scenarios in an experiment
  • Choosing to view the details of an existing Scenario will take the user to a display of the Scenario that is presented to the participant (Scenario View NOT IN SCOPE).

3. Familiarization Library View
This view allows the researcher to browse all of the saved Familiarizations within an experiment (It might make sense to have a folder structure to group these.)

Use case: A researcher may create three familiarizations to be used in an experiment that has nine total sessions. So, each of those familiarizations would be used in three different sessions.  These familiarizations could be named differently for the user to understand the difference between them.

Each Familiarization will have the following details:

• Familiarization name
• Date created
• Date last modified
• Options to
  • Edit the Familiarization (takes user to: 6. Familiarization Authoring View)
  • Delete the Familiarization
  • Share the Familiarization
  • Duplicate a Familiarization
  • Create a new Familiarization (takes user to: 6. Familiarization Authoring View)
  • Choosing to view the details of an existing Familiarization will take the user to a display of the Familiarization that is presented to the participant (Familiarization View NOT IN SCOPE).

4. Questionnaire Library View
This view allows the researcher to browse all of the saved Questionnaires. The questionnaires will not be grouped as the library will have only a relatively small set of questionnaires that get reused across experiments.

The HATTB will come preloaded with several common Questionnaires.

Each scenario will have the following details:

• Questionnaire name
• Date created
• Date last modified
• Options to
  • Edit the questionnaire (takes user to: 7. Questionnaire Authoring View)
  • Delete the questionnaire
  • Duplicate a questionnaire
  • Share the questionnaire
  • Create a New questionnaire (takes user to: 7. Questionnaire Authoring View)
  • Choosing to view the details of an existing questionnaire will take the user to a display of the questionnaire that is presented to the participant (Questionnaire View NOT IN SCOPE).

5. Experiment Authoring View
Experiment example: link.
This view allows researchers to create experiments by arranging sessions.

• Each experiment contains a set of sessions.
• Each session consists of a sequence of Familiarizations, Scenarios, and Questionnaires to understand the flow for each session.
• The  specific order of elements in each session is critical for conducting research experiments and the Researcher is able to change the order as they wish.  
• Include option to Lock an experiment to prevent additional changes.
• Include option to Save an experiment. It is saved locally to the device and surfaced in the 1. Experiment Library view. If the user attempts to leave this view without saving changes, he should be prompted with an alert asking them if they want to save or discard changes.
• Once the user has finished with creating/editing an experiment, they will return to their previous page (Experiment Library)
• Choosing to view the details of an existing experiment will take the user to a display to configure the experiment for a participant (Experiment View NOT IN SCOPE).

Scenario Authoring View 
This screen is NOT IN SCOPE. It will be addressed in an upcoming challenge.
FYI: This view will be a complex interface in the application with many configurable parameters for a scenario. The scenario will be defined on a timeline with events (or tasks) being triggered at specific times. More to come in the next challenge!

6. Familiarization Authoring View 
Example of Familiarization: link.
This view allows researchers to create Familiarizations.

• The Familiarization may contain more than one screen and can incorporate text, images, and videos that will describe the user what the scenario is about. Content may also include instructions for calibrating eye tracking hardware and for connecting to nearby devices for multi-participant experiments.
• This authoring tool will enable flexible layouts for these elements.
• The Familiarizations are saved locally to the device and surfaced in the 2. Familiarization Library view.
• Choosing to view the details of a Familiarization already created will take the user to a view of the Familiarization that is presented to the Participant (Familiarization View NOT IN SCOPE).

7. Questionnaire Authoring View
Example of questionnaire: link 1 and link 2.

This view allows researchers to create Questionnaires.

• The Questionnaires can incorporate various  types of responses, such as multiple choice, slider scale, and open text response.
• The Questionnaires are saved locally to the device.
• Choosing to view the details of a Questionnaire already created will take the user to a view of the Questionnaire that is presented to the Participant (Questionnaire View NOT IN SCOPE).

 
JUDGEMENT CRITERIA

• Presentation: Thorough: provide a thorough wireframe solution. It should simulate the workflow described, including linked screens, variations and behaviors of elements.
• Creativity: Impactful: the solution is different or unique from what is already out there and can be implemented.
• Exploration: Out of the box: consider the screen requirements and guidelines as a draft or start point. Provide alternate experiences or workflows to achieve what we are proposing in the requirements and satisfy the user goals.
• Aesthetics: Low-fidelity design: provide plain simple aesthetics within a detailed wireframe solution.
• Branding: Open: Your solution MUST be pure wireframes without the use of branding or styling of UI elements. Focus is on content and functionality. Design must follow Apple’s Human Interface Guidelines.

Device Specifications

• Desktop: Macintosh OS MacBook
• Size: 1366px x 768px (width x height)

Stock Photos and Icons

• Photos: Use only free photos from the sites allowed by Topcoder
• Icons: Use only icons that are free (based on Topcoder icons policy) without giving attribution, or create the icons yourself. If the icons are not free, we will require them to be replaced in the final fixes.
• Fonts: Use fonts as allowed by Topcoder policy

Marvel Prototype

• Upload your screens to Marvel App.
• Ask in the forums for a Marvel project
• Include your Marvel app URL as a text file in your final submission. Label it “MarvelApp URL”.

Final Deliverables

• An archive called Source.zip file to include:
  • All original source files created with a wireframe tool such as: Axure, Adobe XD, Figma or Sketch.
• An archive called Submission.zip file to include:
  • All your wireframes in html format or PNG / JPG format
• Your declaration files to include any notes about fonts usage, photo and icon declaration and link to your Marvel project
• Create a JPG preview file of 1024 x 1024 px