-
Notifications
You must be signed in to change notification settings - Fork 0
/
results.html
116 lines (101 loc) · 9.48 KB
/
results.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
<!DOCTYPE HTML>
<!--
Hyperspace by HTML5 UP
html5up.net | @ajlkn
Free for personal and commercial use under the CCA 3.0 license (html5up.net/license)
-->
<html>
<head>
<title>Results and Discussion</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />
<link rel="stylesheet" href="assets/css/main.css" />
<noscript><link rel="stylesheet" href="assets/css/noscript.css" /></noscript>
</head>
<body class="is-preload">
<!-- Header -->
<header id="header">
<a href="index.html" class="title">PassBeat</a>
<nav>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="method.html" title="method">previous</a></li>
<li><a href="future-work.html" title="future work">next</a></li>
</ul>
</nav>
</header>
<!-- Wrapper -->
<div id="wrapper">
<!-- Main -->
<section id="main" class="wrapper">
<div class="inner">
<h1 class="major">Results and Discussion</h1>
<p></p>
<h3>Strengths</h3>
<ul>
<li>The level of feedback given will be familiar to the user and will neither confuse nor overwhelm the user.</li>
<li>A simple design and a limited, but well thought out, choice of colours helps emphasize the important elements in the app.</li>
</ul>
<h3>Weaknesses</h3>
<ul>
<li>Unless the user is careful they can still be subject to things that lower their integrity, such as shoulder-surfing.</li>
<li>Limited visual and auditory feedback might worsen a user's ability to remember their secret rhythm.</li>
</ul>
<h3>Heuristic evaluation</h3>
<p>We analysed the app based on Nielsen's 10 Usability Heuristics, due to the scope of the project some heuristics are more relevant than others.</p>
<ul>
<li><strong>Visibility of system status: </strong>The large text at the top of each page serves as a way to show the status of the system.</li>
<li><strong>Match between system and the real world: </strong>We tried to use short texts or phrases instead of icons in order to increase the understanding, unless the meaning of an icon is obvious.</li>
<li><strong>User control and freedom: </strong>Since the project is about authentication, the freedom has to be limited. But within this limitation the user is free to enter any view possible at that time.</li>
<li><strong>Consistency and standards: </strong>The app uses icons that are commonly used and whose meaning is unambiguous. The yellow input-button looks the same and has the same behaviour on all pages where it is present.</li>
<li><strong>Error prevention: </strong>Due to the app-environment there is relatively little room for user-caused errors, unlike on websites. Error prevention has, however, been checked often throughout the development. </li>
<li><strong>Recognition rather than recall: </strong>Plenty of instructions are given to the user in each view and all options are always present on the screen.</li>
<li><strong>Flexibility and efficiency of use: </strong>Not really relevant to the project or its scope.</li>
<li><strong>Aesthetic and minimalist design: </strong>We have tried to keep the app's design as minimalistic as possible using as few elements as possible, and only three colours: black, white and yellow. The design is supposed to emphasize the yellow input-button in order to increase understanding.</li>
<li><strong>Helps users recognise, diagnose and recover from errors: </strong>The app shows Toast messages indicating whether the password was correct. This helps users to identify input mistakes without revealing the password.</li>
<li><strong>Help and documentation: </strong>The user is given the option to read a short "About"-section in the app and is also invited to this website for more information.</li>
</ul>
<h3>Empirical Evaluation</h3>
<p>To evaluate the retentiveness of rhythm-based passwords, a small-scale field-study was conducted. Seven Participants aged between 20 and 60 where asked to set a rhythm-password. Then they had five minutes time to practice entering the password. After two and four hours respectively, they were asked to enter the password again. Furthermore, the participants were asked to compare the retentiveness and difficulty of inputting rhythm-based passwords to conventional passwords.</p>
<p>The study showed that the majority of participants though the rhythm-based password was easier to remember than conventional passwords. 85.7% of participants could successfully enter their rhythm-based passwords two and four hours after setup. Only one participant remembered it partially after two hours and could not login after four hours. So, the retentiveness seems to be quite good, even though, two participants though the rhythm-based password was significantly more difficult to remember. In particular, remembering the speed of the rhythm seemed to cause the difficulties.</p>
<span class="inner fit"><img src="images/result_difficulty.png" alt="diagram showing the results on the difficulty of remembering rhythm-based passwords" width="100%"/></span>
<p>When it comes to the difficulty of entering rhythm-based passwords the participants are split in two groups. About one half considered rhythm-bases passwords to be (significantly) easier to use while the other thought them to be more difficult.</p>
<span class="inner fit"><img src="images/result_input.png" alt="diagram showing the results on the difficulty of entering rhythm-based passwords" width="100%"/></span>
<p>Thus, rhythm-based passwords seem to be good to remember and one participant also commented that the ability to enter the rhythm without looking the screen was a great asset. Nonetheless, the perceived difficulty regarding usability strongly depends on the users’ personal preferences and remembering the speed of the rhythm can be a challenge.</p>
<p>Due to the very small number of participants, outliers can have a larger effect on the results. So, the results only give an insight into a small group of potential users and might not be representative for the general public.</p>
<h3>Limitations</h3>
<p>One thing we have heard multiple times in feedback is that this kind of authentication would not suit people who are tone-deaf or has little sense of music. This is highly relevant feedback and also allowing normal text-based passwords would be a way to solve this problem. However, this solution raises problems in the potential usage of rhythm-based passwords as people, when given the option, might opt for text-based passwords due to their familiarity with it. Why learn a whole new type of password when you can stick with what you are used to?</p>
<p>The app has also been critiqued in that shoulder-surfing still is possible despite the fact that this, in the beginning, was one of the issues that the app was going to solve. The reason why this hasn't been addressed to a significant extent is mainly due to the fact that the more secure version of the early prototypes was dropped. However, in our opinion the app is still at least equally secure as normal passwords would be, if not more so. It is still possible for the user to cover the screen with one hand while entering their rhythm with the other, or even hold the smartphone behind their back.</p>
<span class="inner fit"><img src="images/security.JPG" alt="hand covering phone during password input" width="100%"/></span>
<h3>Conclusion</h3>
<p>This project has given us a great opportunity to research interaction design, accessibility and mobile development and in regard to the scope we think the results have been satisfactory. However as this is the first prototype there are, as suspected, several limitations and problems with the design that should be addressed before moving on to further development. Further user testing using a large number of people would also be required to make any statistically significant conclusions. From a technical point of view these first results seem promising, but many improvements could be made to decrease the number of false positives and false negatives. </p>
</div>
</section>
</div>
<!-- Footer -->
<footer id="footer" class="wrapper alt">
<div id="footer-nav">
<nav>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="method.html" title="method">previous</a></li>
<li><a href="future-work.html" title="future work">next</a></li>
</ul>
</nav>
</div>
<div class="inner">
<ul class="menu">
<li>© PassBeat. All rights reserved.</li><li>Design: <a href="http://html5up.net">HTML5 UP</a></li>
</ul>
</div>
</footer>
<!-- Scripts -->
<script src="assets/js/jquery.min.js"></script>
<script src="assets/js/jquery.scrollex.min.js"></script>
<script src="assets/js/jquery.scrolly.min.js"></script>
<script src="assets/js/browser.min.js"></script>
<script src="assets/js/breakpoints.min.js"></script>
<script src="assets/js/util.js"></script>
<script src="assets/js/main.js"></script>
</body>
</html>