0LAUK0 2018Q1 Group 2 - Prototype User Testing

From Control Systems Technology Group

(Difference between revisions)
Jump to: navigation, search
(Proof of Assumptions: added disclaimer - section is not finished)
Line 51: Line 51:
=Proof of Assumptions=
=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
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
actually succeed in preventing RSI. If our device would not take the known actions for preventing RSI

Revision as of 19:52, 7 October 2018

This page is part of the research done by 0LAUK0 2018 Q1 Group 2, our main page can be found at PRE2018 1 Group2.


Contents

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.

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.

Personal tools