0LAUK0 2018Q1 Group 2 - Prototype User Testing

From Control Systems Technology Group
Revision as of 16:57, 14 October 2018 by S141153 (talk | contribs) (updated using contents from google drive project folder)
Jump to navigation Jump to search

This page is part of the research done by 0LAUK0 2018 Q1 Group 2, our main page can be found at PRE2018 1 Group2. During week 6 of the project, the tests were revised. The previous iteration of the tests can be found in the section "old tests".


Introduction

Once the design is ready, it needs to be tested by independent users. The monitor needs to be user- friendly, so a test plan should be made to check whether it is. The requirements are mainly about ethical and physical issues. The monitor should not cause ethical problems and it should be physically pleasant for the user to use the monitor. An idea for testing our monitor could be to place it in MetaForum, and let students and teachers use it. Again, here one can distinguish critical issues from high, medium and low issues. Any critical issues shall be dealt with first, then the high issues, etc. The goal is again to get zero critical and high issues and as less medium and low issues as possible. In the end, a justification of our device will follow.


Requirements

  • Screen not moving too slow, but not too fast neither. Optimal would be that once the screen starts moving, it will reach the correct position within ‘x’ seconds. It will move with a constant velocity (or as constant as possible). Screen will move in three parts; first sideways, then vertically and then horizontally.
  • Screen not too sensitive (an optimal responding time would be ‘x’ seconds).
  • As less noise as possible.
  • Cameras delete all frames made.
  • From a certain angle, it should be impossible to see what is on the screen (privacy).
  • It must be possible to operate the screen manually.
  • If the user has a wrong posture, the screen will give a warning. When the warning is not answered, the screen will turn off. (Good or wrong posture is determined by input parameters.
  • Screen moves by itself to adjust the posture of the user.
  • One needs a security code to be able to install and/or adjust the input parameters.


Revised tests

Responding to a Wrong Posture

The goal of doing these tests, is finding out what the preference of the user is, regarding how the monitor should respond when the user is having a wrong posture. The response that turns out to be most convenient will then be set as the standard response of the device. The other responses will still be available as custom settings.

Scenario:

The user is sitting behind the monitor, having a wrong posture.

Expected outcomes:

  • The screen will be lightened or dimmed, depending on whether the user is too close or too far away. If the user is too close, the screen will brighten up, if the user is too far away, the screen will dim.
  • The monitor will come up with a visual reminder (like a pop-up, a notification, etc.).
  • The device will play an audio reminder, a sample that starts to play when the user is in an incorrect posture.
  • The rumble motors in the chair will be activated and the chair starts to rumble (akin to rumble features in present modern video games).
  • The screen will move towards or away from the user, depending on whether the user is too close or too far away. If the user is too close, the screen will move towards the user, if the user is too far away, the screen will move away from the user.

First it should be tested whether these scenarios work at all (these tests could be performed by us), and then the users could be used to determine a favourite way of responding.

Monitor Moves Along

The goal of doing these tests, is finding out what moving speed of the monitor is the most convenient for the user. This speed will then be set as the default speed. The other speeds could still be available as custom speeds.

Scenario:

The user moves away an enough distance to not maintain an optimal position for the monitor.

Expected outcomes: The monitor will follow along with 1 cm/s, 2 cm/s, 3 cm/s, etc. First it should be tested (by us) whether these scenarios work in the first place. Then the users could be used to determine an optimal moving speed. An additional test could be made concerning the vibration of the monitor when moving (these tests could be performed both by us and the users).

Scenario:

The same as just before.

Expected outcome:

The monitor doesn’t vibrate when moving, the view of the monitor is not disturbed.


Old Tests

Physical tests

Some of the tests that could be done regarding the requirements above will be omitted since that these already have been described in the first test plan (tests like making the actuator less noisy, installing custom made thresholds and thus operating the screen manually, etc.). Of course, everything described in the first test plan should still be valid when testing the device on the real users.

1. The user moves within response time and exceeding the maximum deviation.

Expected outcome: The screen will follow along after ‘a’ seconds (response time) and reach the correct position within ‘x’ seconds, moving with a (as far as possible) constant velocity.
Obtained outcome: …

2. The user is sitting behind the screen, having a wrong altitude.

Expected outcome: The screen will give a warning about the wrong posture of the user. If the user corrects his/her posture correctly, the warning disappears. If the user doesn’t correct his/her posture, the screen will turn off.
Obtained outcome: …

3. The user is sitting in a correct position for a ‘x’ amount of time.

Expected outcome: After a ‘x’ amount of time, the screen will adjust itself to a new optimal position.
Obtained outcome: …

Ethical Tests

1. The user uses the monitor for a ‘x’ amount of time, with the camera running.

Expected outcome: All frames the camera has made are deleted (instantaneously).
Obtained outcome: …

2. Someone stands behind the user and walks to the right/left, looking at the screen.

Expected outcome: From a certain angle, the screen will not be visible anymore.
Obtained outcome: …

3. The user wants to install/change his/her input parameters.

Expected outcome: The device asks for a personal security code in order to be able to get access to the input parameters.
Obtained outcome: …


Proof of Assumptions

Disclaimer - this section is work-in-progress

One of the most important things in this project of course is to get proof of that our device will actually succeed in preventing RSI. If our device would not take the known actions for preventing RSI into account, it could become a failure. Therefore, it is important to have a justification of what our device does and why.

In order to maintain and promote ones health, a good balance between activity and rest is necessary. Rest pauses are helpful for recovery of load-induced strain and prevention of fatigue. By giving the monitor a function to give a warning after the user has worked for a ‘x’ period of time, or when desired even shut down, this can be achieved.