Medien Wiki - User contributions [en]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-19T22:16:22Z

AnjaR: /* The interviews */

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a convenient handling in the message window?
* How can we improve the interface for the functions of secure, insecure and verified messaging?

Phrasing your goals as questions is a good way to guide the process. These are both quite valuable and relevant questions. I'm unclear who '''I''' is in the first question, the designer or the user.
'''EDIT''': Thank you. I and We are the designer.

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The different colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

I like that you started with very quick and raw sketches! I think its important to generate lots of ideas in the beginning, so doing rough sketches is important. I would like to see more sketches with all sorts of ideas from small makeovers to radical new ideas. Its also possible to do quick user tests with very rough sketches.
'''EDIT''': Sorry, but we didn't make more sketches that time.

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

A good set of questions. They should be tighter, more targetted. Like instead of "would you want to improve something?" say it very directly: "what would you improve?" or "What do you like about the app's interface?"

We interviewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

Ideally, a user study would be made up of people who use the software in ways that are directly relevant to what you are trying to achieve. Of course, its not always possible to spend the time to find the perfect users, so finding willing candidates is still valuable as long as you take into account the experience and possible bias of the people who actually participate in your user study.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arranged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

Taking notes during the process is a good way to remember key details. Having a video of the process is very useful for going back and getting a feeling for what the user was doing. By focusing on the video on the device and not the user, it can make the user less self-conscious.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her address, e.g. in Facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more important.

She does care some about security because she adds "as long as". A good follow up question would be about how much usability she would give up to guarantee that the "as long as" never happens. Or perhaps, if there were two apps that were both easy to use, would she prefer the more secure one?

* Test subject 3: She is a quite cautious person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

It would also be useful to find out how much she extra is willing to work to understand an app if it provides security.

'''EDIT''': I even asked both, 1 and 3, that question! Both didn't have any ideas, so I asked them if it would be okay to be asked a question in the app that she and her partner have set up before. It was an effort, both agreed it wouldn't bother them and they would use such a chat.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he has thought about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

Did he have specific concerns about the third party, or was he saying that that part of the app's interface was confusing?

'''EDIT''': It's just circuitous to register on a third party. It had nothing to do with the interface.

* Test subject 2: Person two wasn't really interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

Yes, the "network effect" is a big hurdle in getting people to use a new app. Having a sense of where the tipping point is where this user would switch to a more secure app would be quite useful when thinking about which part is most important to focus on first.

'''Student 3:'''

* Test subject 1: He is a person who uses instant-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the person's thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By directly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technology. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite sure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagram.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

Overall a good set of results from the interviews. These could be improved by getting more information on what the specific barriers to using different software are. All of the users seemed to care about security to some degree, but it sounds like some were willing to work more in order to be secure. Knowing what these users' key issues were would be very useful when figuring out what improvements are the highest priority in order to get more people to start using ChatSecure.

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a [http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisSecurity heuristic analysis] to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they don't look above by each sending of a message.

[[File:pro.jpg | 900px]]

Providing feedback where the user actually looks when working is key. Its not always easy to tell that in advance, that's where user testing comes in. So you got come valuable information in your test here. One idea related to the coloring to consider: the app is called ChatSecure, so people expect secure messaging. That expectation can be represented in the app, so when the messages are secure, the app looks like a "normal" Android messaging app. Then use the color to represent when things are not secure. That could make the non-secure states stand out more.

===Protoype 2b)===
A next question was how we could show that the message is not encrypted. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

This would be a very valuable thing to have for people using ChatSecure in high risk situations, where it is important that they don't mistakenly send messages insecurely. An example is a journalist under surveillance from the state. But for many people, it would just annoy them. I wouldn't discard this idea so quickly, I think it could be made workable. And it would work a lot better than a popup once the user learns it.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an insecure chat or to remind the user to verify himself and/or his contact person.

'''EDIT:''' The user have to choose, whether he will send the message unsafe or try a safe sending on another time. He also has the opportunity to save his response for all time. This can be changed in the settings.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

This is a good balance of familiar interface experience and quick to use regularly. Its not as flashy as the swipe, but seems like it would not get too annoying if you saw it regularly.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

You are right, starting the secure session is too complicated. The on/off switch would be a nice representation, but because of technical constraints, I don't think it would be workable. We tried it and it was confusing people. The problem is the on/off widget cannot represent anything but on or off, and it takes a while for the OTR session to start. So that leaves the on/off switch in a confusing state while OTR is starting. OTR is neither on nor off. We still don't have a great answer for this problem, but it seems that a button with an icon that changes is the best bet. Then we can represent multiple states.

Starting OTR automatically all the time would also make things easier, but that also has technical limitations. OTR works by sending text messages, and if someone is using a program that does not include OTR, they'll see those odd OTR messages. Its not a huge problem, but it does freak some people out.

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!

'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

Its always surprising, but still, "social engineering" is still the main way people break into computer systems. Edward Snowden used a lot of social engineering techniques to get access to many of the documents that he leaked.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

I find that rapid prototyping is essential to the process of making good user experiences. For most people, the design process works best when there are many iterations on the idea, so making more iterations as fast as possible means more ideas get explored.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Representing technical limitations to the user in a simple way will always be challenging. User testing has demonstrated itself to be a great method for finding out how well ideas and designs map to real experience.

==What we learned / conclusions:==

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

I also want to see more. I think you had a lot of good design ideas, but there was not a lot of information outside that to back up the designs.

From our research, we got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.
For our prototypes, we concentrated to improve the interface. Here is a graphical summary of our proposals.

[[File:Zusammenfassung prototyp.jpg | 900px]]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-19T22:04:14Z

AnjaR: /* What we learned / conclusions: */

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a convenient handling in the message window?
* How can we improve the interface for the functions of secure, insecure and verified messaging?

Phrasing your goals as questions is a good way to guide the process. These are both quite valuable and relevant questions. I'm unclear who '''I''' is in the first question, the designer or the user.
'''EDIT''': Thank you. I and We are the designer.

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The different colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

I like that you started with very quick and raw sketches! I think its important to generate lots of ideas in the beginning, so doing rough sketches is important. I would like to see more sketches with all sorts of ideas from small makeovers to radical new ideas. Its also possible to do quick user tests with very rough sketches.
'''EDIT''': Sorry, but we didn't make more sketches that time.

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

A good set of questions. They should be tighter, more targetted. Like instead of "would you want to improve something?" say it very directly: "what would you improve?" or "What do you like about the app's interface?"

We interviewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

Ideally, a user study would be made up of people who use the software in ways that are directly relevant to what you are trying to achieve. Of course, its not always possible to spend the time to find the perfect users, so finding willing candidates is still valuable as long as you take into account the experience and possible bias of the people who actually participate in your user study.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arranged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

Taking notes during the process is a good way to remember key details. Having a video of the process is very useful for going back and getting a feeling for what the user was doing. By focusing on the video on the device and not the user, it can make the user less self-conscious.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her address, e.g. in Facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more important.

She does care some about security because she adds "as long as". A good follow up question would be about how much usability she would give up to guarantee that the "as long as" never happens. Or perhaps, if there were two apps that were both easy to use, would she prefer the more secure one?

* Test subject 3: She is a quite cautious person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

It would also be useful to find out how much she extra is willing to work to understand an app if it provides security.

'''EDIT''': I even asked both, 1 and 3, that question! Both didn't have any ideas, so I asked them if it would be okay to be asked a question in the app that she and her partner have set up before. It was an effort, both agreed it wouldn't bother them and they would use such a chat.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he has thought about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

Did he have specific concerns about the third party, or was he saying that that part of the app's interface was confusing?

* Test subject 2: Person two wasn't really interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

Yes, the "network effect" is a big hurdle in getting people to use a new app. Having a sense of where the tipping point is where this user would switch to a more secure app would be quite useful when thinking about which part is most important to focus on first.

'''Student 3:'''

* Test subject 1: He is a person who uses instant-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the person's thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By directly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technology. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite sure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagram.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

Overall a good set of results from the interviews. These could be improved by getting more information on what the specific barriers to using different software are. All of the users seemed to care about security to some degree, but it sounds like some were willing to work more in order to be secure. Knowing what these users' key issues were would be very useful when figuring out what improvements are the highest priority in order to get more people to start using ChatSecure.

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a heuristic analysis to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they don't look above by each sending of a message.

[[File:pro.jpg | 900px]]

Providing feedback where the user actually looks when working is key. Its not always easy to tell that in advance, that's where user testing comes in. So you got come valuable information in your test here. One idea related to the coloring to consider: the app is called ChatSecure, so people expect secure messaging. That expectation can be represented in the app, so when the messages are secure, the app looks like a "normal" Android messaging app. Then use the color to represent when things are not secure. That could make the non-secure states stand out more.

===Protoype 2b)===
A next question was how we could show that the message is not encrypted. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

This would be a very valuable thing to have for people using ChatSecure in high risk situations, where it is important that they don't mistakenly send messages insecurely. An example is a journalist under surveillance from the state. But for many people, it would just annoy them. I wouldn't discard this idea so quickly, I think it could be made workable. And it would work a lot better than a popup once the user learns it.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an insecure chat or to remind the user to verify himself and/or his contact person.

'''EDIT:''' The user have to choose, whether he will send the message unsafe or try a safe sending on another time. He also has the opportunity to save his response for all time. This can be changed in the settings.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

This is a good balance of familiar interface experience and quick to use regularly. Its not as flashy as the swipe, but seems like it would not get too annoying if you saw it regularly.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

You are right, starting the secure session is too complicated. The on/off switch would be a nice representation, but because of technical constraints, I don't think it would be workable. We tried it and it was confusing people. The problem is the on/off widget cannot represent anything but on or off, and it takes a while for the OTR session to start. So that leaves the on/off switch in a confusing state while OTR is starting. OTR is neither on nor off. We still don't have a great answer for this problem, but it seems that a button with an icon that changes is the best bet. Then we can represent multiple states.

Starting OTR automatically all the time would also make things easier, but that also has technical limitations. OTR works by sending text messages, and if someone is using a program that does not include OTR, they'll see those odd OTR messages. Its not a huge problem, but it does freak some people out.

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!

'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

Its always surprising, but still, "social engineering" is still the main way people break into computer systems. Edward Snowden used a lot of social engineering techniques to get access to many of the documents that he leaked.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

I find that rapid prototyping is essential to the process of making good user experiences. For most people, the design process works best when there are many iterations on the idea, so making more iterations as fast as possible means more ideas get explored.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Representing technical limitations to the user in a simple way will always be challenging. User testing has demonstrated itself to be a great method for finding out how well ideas and designs map to real experience.

==What we learned / conclusions:==

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

I also want to see more. I think you had a lot of good design ideas, but there was not a lot of information outside that to back up the designs.

From our research, we got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.
For our prototypes, we concentrated to improve the interface. Here is a graphical summary of our proposals.

[[File:Zusammenfassung prototyp.jpg | 900px]]

File:Zusammenfassung prototyp.jpg

2014-03-19T22:01:43Z

AnjaR:

== Summary ==

== Copyright status: ==

== Licensing ==
{{self|c}}
== Source: ==

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:59:47Z

AnjaR: /* Presentation */

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a conveniant handling in the message window?
* How can we improve the interface for the functions of secure, unsecure and verified messaging?

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The diffrent colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arraged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her adress, e.g. in facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more impotant.

* Test subject 3: She is a quite cautios person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he have thinked about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

* Test subject 2: Person two wasn't realy interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

'''Student 3:'''

* Test subject 1: He is a person who uses instand-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the persons thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By direcly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technics. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite shure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a heuristic analysis to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they dont look above by each sending of a message.

[[File:pro.jpg | 900px]]

===Protoype 2b)===
A next question was how we could show that the message is not encryped. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an unsecure chat or to remind the user to verify himself and/or his contact person.

'''EDIT:''' The user have to choose, whether he will send the message unsafe or try a safe sending on another time. He also has the opportunity to save his response for all time. This can be changed in the settings.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!

'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

==What we learned / conclusions:==

'''from our research:'''

We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.


[[Category:Automation]]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:59:25Z

AnjaR:

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a conveniant handling in the message window?
* How can we improve the interface for the functions of secure, unsecure and verified messaging?

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The diffrent colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arraged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her adress, e.g. in facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more impotant.

* Test subject 3: She is a quite cautios person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he have thinked about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

* Test subject 2: Person two wasn't realy interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

'''Student 3:'''

* Test subject 1: He is a person who uses instand-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the persons thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By direcly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technics. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite shure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a heuristic analysis to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they dont look above by each sending of a message.

[[File:pro.jpg | 900px]]

===Protoype 2b)===
A next question was how we could show that the message is not encryped. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an unsecure chat or to remind the user to verify himself and/or his contact person.

'''EDIT:''' The user have to choose, whether he will send the message unsafe or try a safe sending on another time. He also has the opportunity to save his response for all time. This can be changed in the settings.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!
'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

==What we learned / conclusions:==

'''from our research:'''

We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.


[[Category:Automation]]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:55:44Z

AnjaR: /* Protoype 2c) */

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a conveniant handling in the message window?
* How can we improve the interface for the functions of secure, unsecure and verified messaging?

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The diffrent colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arraged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her adress, e.g. in facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more impotant.

* Test subject 3: She is a quite cautios person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he have thinked about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

* Test subject 2: Person two wasn't realy interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

'''Student 3:'''

* Test subject 1: He is a person who uses instand-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the persons thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By direcly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technics. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite shure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a heuristic analysis to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they dont look above by each sending of a message.

[[File:pro.jpg | 900px]]

===Protoype 2b)===
A next question was how we could show that the message is not encryped. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an unsecure chat or to remind the user to verify himself and/or his contact person.

'''EDIT:''' The user have to choose, whether he will send the message unsafe or try a safe sending on another time. He also has the opportunity to save his response for all time. This can be changed in the settings.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!
'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

===What we learned / conclusions:===

'''from our research:'''

We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.


[[Category:Automation]]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:50:14Z

AnjaR: /* Protoype 2b) */

==Aims of design==
We concentrated on the interface of the message window. First, it should be easy to handle, of course. It should provide an uncomplicated and plain interface, where you can figure out the functions fast and remember them for the next time. It’s essential to spare symbols that confuses the user or that are barely necessary by themselves. So we searched for some design ideas to answer the questions:
* What can I do to guarantee a conveniant handling in the message window?
* How can we improve the interface for the functions of secure, unsecure and verified messaging?

==Ideas==
Könntet ihr die Ideenfindung in den Prozess einordnen? Wann und warum habt ihr das gemacht? Es sieht wie Lösungsideen für Probleme aus, die nach der Nutzerfoschung festgestellt wurden. Sollte der Abschnitt hier drinnen sein, weil im Arbeitsbuch ein solcher Abschnitt ist: In dem Arbeitsbuch ging es um erste Ideen, zu denen man forschen könnte (tut mir leid, wenn das nicht klar war, schreibt mir gerne dazu, dann kann ich es verbessern)
 '''EDIT''': We came up with this ideas after using ChatSecure for the first time. We wanted to improve the interface before our user interviews according to the question: How do we communicate security?

We searched for possible symbols that provide security and tried out some designs to improve the current look of the chat. Examples had been locks and shields in many variations. We also tried out various colors to make clear the differences between functions.

We discussed our ideas and criticized them. The diffrent colors are feedback from the group.
 ''Green'': the group liked the idea
 ''Blue'': neutral / comments
 ''Red'': problems of the idea

[[File:NuStu_prototyping.jpg | 300px]] [[File:ideas.jpg | 300px]]

==How we prepared for interviews / our questions==
For our interviews, we tried to choose open questions that don’t require a yes or no, but longer answers. So we would find out more about what our test subjects like or not.

'''Main questions have been:'''
* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs? Why?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them.
Warum habt ihr Studierende ausgewählt? (es ist auch o.k. Personen auszuwählen, weil man einfachen Zugang hat – solange ihr schreibt, warum, z.B, weil auch diese einen Chat-Client benutzen und ihr so mehr Erfahrung im Interviewen sammeln könnt…) 
 '''EDIT''': For no particular reason. Our friends are mostly students from our courses, that's why.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

==Preparation for the interviews / Observation==

'''Student 1:'''

The preparatioin was quite easy for me, because I’ve already known the test subjects. It was fast done to find a fixed date. During the interviews II realized that I sometimes had to look between the lines to filter what my interview partner really thinks. So I got the most usable answers by questioning their answers (“Why do you think so?”) or ask a question like “So, do you think it’s like…?” I used pen and paper, I haven’t had audio equipment, but the written answers had been useful.

'''Student 2:'''

Before the interviews I prepared a list of questions. This was helpful, to keep the focus in the talks and don't ask yes or no questions.
I also used pen and paper or the computer to make notes while the interview. I made short notes, because they are written down quickly. After the interview I've formulate this notes and add more informations.

'''Student 3:'''

Before doing the interview I looked up our last topic and / or problems of the course. Based on these information I made some notes and put them into possible questions. Afterwards I arraged them to fit a better order for the talk.
Because writing, asking and thinking is to much at the same time, i decided to use a audio recorder with the permission of the test subjects. This made it possible to keep the talk running. In my opinion it's more polite to concentrate on the interview partner instead writing everything down. This way of interviewing enables you rewind the whole interview and maybe check for a certain aspect as often as you wish. After all things were done I wrote down the findings for documentation and share purpose.

==The interviews==

'''Student 1:'''
* Test subject 1: She is not quite satisfied with her current chat programs. Sometimes she holds back her opinion about political references and don’t give an access to her adress, e.g. in facebook. She’d like to have a chat that’s secure, but she only uses it, if all of her friends would use it, too.

* Test subject 2: She knows about the dangers of someone that could spy out her messages, but it doesn’t bother her at all. As long as it isn’t someone that she knows and it could have consequences for her, she not interested in a secure chat. For her functions and look is more impotant.

* Test subject 3: She is a quite cautios person that feels insecure all the time when being in the internet. She don’t hold back with her opinion, but writes messages with the perpetual feeling of “I can be watched now.” She would appreciate a chat that is secure, but one that is instinctively and simple to handle, because she gives up pretty fast and changes the app when she needs a longer time to figure out the single functions.

'''Student 2:'''
* Test subject 1: Person one preferred messages to plan things, if they aren't complicated. Because he is working in the IT business, he have thinked about the security of his messages, how the data is encoded and how the password is saved. The scope of functions in ChatSecure is okay, but the registration through a third party isn't comfortable. The person doesn't liked the design of ChatSecure at this time, because the contact view is very confused.

* Test subject 2: Person two wasn't realy interested in the security of his messages. He had heard about some vulnerabilities in Facebook but he think he can't do something against. The scope of functions in ChatSecure is okay, but it could be more color in the design.

* Test subject 3: The third person have also think about the security of his messages because of the news in the media. But he would not change his chat program, because of the amount of people in programs like WhatsApp.

'''Student 3:'''

* Test subject 1: He is a person who uses instand-chat only for some basic talks about dispensable topics with friends. In the first part of the interview he answered the questions not containing security issues. This gave a good impression of the persons thoughts about this kind of software and security in general. In the second part he answered questions directly linked to the security topic. By direcly asking him about security problems and concerns, he gave some interesting answers. The main statement of this talk was: Don't think about it, or you will panic.

* Test subject 2: He is a person with high skills in electronic and computer technics. His attitude towards security and secure chat software were very negative. One big problem of secure systems is that they are not quite secure or that they are to complex to use, he said. In his opinion it would be good if programs inform the user about security issues and everything else should be done automatically.

* Test subject 3: She is a person with also good knowledge on computers and software. Chat-software is for her a good medium for fast message transport. She says unfortunately oneself has no chance to check if the security promises of the companies are right. In her opinion the best way to secure own data is to publish only the data you are quite shure to publish.

==Data Analysis==
We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

[[File:affinity.jpg | 900px]]

===Results:===
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important. They know about the danger in these chats, but it doesn’t bother them enough to change to another one. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a program or message is secure or not
* Open Source programs provide trust
* The design should be functional AND appealing

It was also interesting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug

==Choosing Ideas and creating prototype==

Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik?
 '''EDIT''': To improve our prototype, we did a heuristic analysis to search for specific problems in the chat. This analysis is divided in ten subitems. We had been going through them all and found some problems which we wanted to take care of. For time reasons though, we couldn’t involve them all.

===Prototype 1===

This prototype is for informing the user what is going on, if the message can't be encrypted.

[[File:pro1.jpg | 300px]]

===Testing it / Results===

When testing it, we found out that the colors had been irritating for our testperson.

==Improvement of the first prototype==

Schöne Bebilderung!

"Testet" diesen Abschnitt nochmal mit folgender "Heuristik": 1) Gibt es einen Bezug von Text und Bild, der die Änderungen/Vorschläge im Design einfach verständlich und deutlich macht, wenn man noch nicht mit euren Ideen und eurer Forschung vertraut ist? 2) ist es klar auf welches Bild-Element sich der Text bezieht, wenn man kein Deutsch spricht?

===Protoype 2a)===
To make the user keep an eye on the current security level, we added colour to the send button. This means the button has the same colour as the bar with the names of the contacts.

'''EDIT''': So you know by clicking on the send button, whether the state is unsafe(red), safe(yellow) or safe and verified(green). You can also see the current status in the little lock above. But some test person told us, they dont look above by each sending of a message.

[[File:pro.jpg | 900px]]

===Protoype 2b)===
A next question was how we could show that the message is not encryped. This also included the problem how one could start encryption.
Warum habt ihr dieses Thema ("informing the user what is going on, if…") gewählt? Nutzerforschung? Vortest? Heuristik? Logische begründung, denn… (eure Erklärung)

'''EDIT:''' As described above, some test persons told us, they want to be informed by sending if their message isn't save. This is another possibility to inform the user.

[[File:nust_security_prototype.png | 600px ]]

The idea was to show a litte exclamation mark sign beside the message on which one could touch. Then some actions should be possible. For example swipe left to send even if it is unsecure.

We discussed this idea in the group and decided that this would not be easy to understand. So we gave up this idea.

===Protoype 2c)===
We added a pop up, which appears when the user tries to start an unsecure chat or to remind the user to verify himself and/or his contact person.

[[File:impro2.jpg | 300px]] [[File:pro2a.jpg | 300px]]

===Prototype 2d)===

If the message is secure (In the speechbubble in the middle picture is written: “start secure messaging”, because one problem was that user don’t know what OTR means.)

[[File:pro2b1.jpg | 900px]]

If the message is not secure, a pop-up comes out to tell the user what is going on and if he wants to continue or to cancel the message-sending:

[[File:pro2b2.jpg | 900px]]

We tested it and our testperson went through it without problems.

===Prototype 2e)===
Because some of our test persons expressed concerns about the many buttons needed to start a secure chat and especially about their labels, we decided to bring everything to one switch.

[[File:prototyp_schalter.png | 300px]]

We gave up this idea, because a switch is not much more easy as we thought. Since ChatSecure is a chat where people want to chat secure obviously, we thought it would be a better idea to start the security function automatically.

[[File:nust_security_prototype_automatic.png | 400px]]

==Presentation==
Schön, dass ihr eure Vortragsthemenund Erkenntnisse dazu nochmal zusammenfasst!
'''Student 1:'''

My topic had been ''security and usability of passwords''. It was really interesting to inform myself about that. The gap between easy understanding (usability) and security of password-protected websites was one theme. In my presentantion I explained that system builder to think out of the perspective of the user. 
However, what I liked the most in my research had been the studies about what passwords other people choose and how they choose them. I was quite surprised about how easy people's passwords can be encrypted and that hacker go social ways more than mathematical ones to crack them.

'''Student 2:'''

My presentation was about prototyping. It was interesting, how many types of prototypes are existing. There are many ways to test new ideas. You have to choose, which type of prototyp is the best for your product.

'''Student 3:'''

My talk was about designing interfaces for secure or security based systems. The main statement of these paper was, that the most of the classical rules of design does not meet the requirements of such an interface. The authors based their thesis upon user tests with the e-mail encryption tool pgp. It was also interesting to read how a test should be organised and which aspects of the test subjects should be kept in mind. All in all it was a very interesting topic for me and i could recommend this paper to everyone.

Ich habe mich sehr gefreut, eure Dokumentation zu lesen. Leider endet sie etwas abrupt. Es würde bei mir als Leser und vermutlich auch unseren Mentoren einen sehr guten letzten Eindruck hinterlassen, wenn hier noch eine Zusammenfassung der wichtigsten Erkenntnisse und Vorschläge zu lesen wäre; Sinnigerweise mit einer Übersicht in Bild- oder Grafikform (siehe Mail) 

===What we learned / conclusions:===

'''from our research:'''

We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan parties in a chat, so the group function could be necessary and image transfer is also an important factor of communication for our interviewed students.


[[Category:Automation]]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:45:40Z

AnjaR: /* Protoype 2a) */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:41:29Z

AnjaR: /* Protoype 2a) */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:40:27Z

AnjaR: /* Protoype 2a) */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-11T10:39:50Z

AnjaR: /* Protoype 2a) */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T22:09:30Z

AnjaR: /* Prototype 3 */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T22:04:44Z

AnjaR: /* Presentation */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T21:49:09Z

AnjaR: /* Ideas */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T21:48:46Z

AnjaR: /* Ideas */

File:NuStu prototyping.jpg

2014-03-03T21:47:54Z

AnjaR:

== Summary ==

== Copyright status: ==

== Licensing ==
{{self|c}}
== Source: ==

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T21:38:40Z

AnjaR: /* The interviews */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T21:19:50Z

AnjaR: /* The interviews */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T21:00:13Z

AnjaR: /* Preparation for the interviews / Observation */

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-03T20:59:59Z

AnjaR: /* Preparation for the interviews / Observation */

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-23T13:28:03Z

AnjaR:

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

Version 13.0.6

== Visibility of system status ==
* When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

* If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

* After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

* Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

* Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

* When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

* A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

* After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

* If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

* If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

* If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

* Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

* Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

* Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

[[File:Screenshot_2014-01-15-11-35-15.png]]

== Aesthetic and minimalist design ==

* The menu is a mix of German and English words. It would be better if it would be limited to one language.

[[File:Screenshot_2014-01-15-11-09-33.png]]

* After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

* In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

* I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

* A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung Person2

2014-01-23T13:08:32Z

AnjaR: /* Help users recognize, diagnose, an recover from errors */

Aufgaben:
* Anmelden
* Account erstellen
* Einstellungen ("Settings")
{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==

* Your own status is shown in the space above your contacts. So it seems to be the status of all your contact. This is slightly confusing. But with a klick on the green circle you can change your status and realize that this is your own status.

[[File:nutzerstudien_start_status.png | 200 px]]

* During the chat, all your messages are marked with a color and show you the security of your message. The colors distinguish between red (unsafe), yellow (only safe from one contact) and green (safe). In addition to the colors, there ist also a lock, which shows you the status of security. If the ciphering break down, there is a warning for the user.

[[File:nutzerstudien_verschluesselung_beendet.png | 200 px]]

* Feedback of a lot of functions do not exist, so the user don‘t know what happend, for example when you try to start OTR and the contact isn't online, then there appears a permanent rotary circle but nothing happens.

[[File:nutzerstudien_rotierender_kreis.png | 200 px]]

== Match between system an the real world ==

* Creating an new account is clear structured and requires only a few data (new user name, provider and a password) from the user. The list of the provider sounds not very confidential to someone who is not familiar with "jabber". So it would useful to give the user some help.
The same would be necessary down to the option "Verbinden über Tor (Benötigt Orbotapp)" - I think some of the user don't know what this item means.
One solution could be an infomationbutton next to the pointed problems.

[[File:nutzerstudien_anmeldung_create.png | 200 px]]
[[File:nutzerstudien_anmedlung_create_jabberanbieter.png | 200 px]]

* For the existing account I think there are no problems. The person, which already own a jabber account has engaged with "jabber" an know the basic things.

== User control an freedom ==

== Consistency and standards ==

* You can swap right an left to change from your contactlist to all open chats. Pull from the left side wil open the menu. All these are typical moves to use an smartphone.

* The Language is easy to unterstand and they use known terms. But there is no continuous language - somtimes its in englisch and sometimes in german, so you have to switch between these two languages.
It would be better if there is used one language. There are two possibilities to solve the problem. The first would be only present the app in englisch (language of the developer) and the second would be to present two different versions - one in englisch and one in german.

* the menu is partially clear. But there is one items, which is confusing.
The "panic - button" enables the user to cancel the app but there is an extra security query, if he really want to cancel.

[[File:nutzerstudien_menu1.png | 200 px]]
[[File:nutzerstudien_panic_abfrage.png | 200 px]]

== Error prevention ==

* There ist no error prevention, within the app there are too many error messages and there is no helping function.

== Recognition rather than recall ==

== Flexibility and efficiency of use ==

* Can't found any difference between novice and expert users.

== Aesthetic and minimalist design ==

* It is an clear an simple design

== Help users recognize, diagnose, an recover from errors ==

* There are a lot off bugs within the app and most of the time ChatSecure close the app an asks the user if he would send a report to the developer. In some case there are warnings or error messages

[[File:nutzerstudien_crash.png | 200 px]]
[[File:nutzerstudien_crash_data.png | 200 px]]

== help an documentation ==

A lot of things are intuitiv, if you are familiar in handling a smartphone.
But there are also a lot of bugs and mistakes within the app and there are also some „wrong“ or some unexpected reaction.
A few functions do not accord with the norm or there is a other reaction as you would expect in reality.
So an documentation would be very helpful.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung Person2

2014-01-23T13:07:48Z

AnjaR: /* Aesthetic and minimalist design */

Aufgaben:
* Anmelden
* Account erstellen
* Einstellungen ("Settings")
{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==

* Your own status is shown in the space above your contacts. So it seems to be the status of all your contact. This is slightly confusing. But with a klick on the green circle you can change your status and realize that this is your own status.

[[File:nutzerstudien_start_status.png | 200 px]]

* During the chat, all your messages are marked with a color and show you the security of your message. The colors distinguish between red (unsafe), yellow (only safe from one contact) and green (safe). In addition to the colors, there ist also a lock, which shows you the status of security. If the ciphering break down, there is a warning for the user.

[[File:nutzerstudien_verschluesselung_beendet.png | 200 px]]

* Feedback of a lot of functions do not exist, so the user don‘t know what happend, for example when you try to start OTR and the contact isn't online, then there appears a permanent rotary circle but nothing happens.

[[File:nutzerstudien_rotierender_kreis.png | 200 px]]

== Match between system an the real world ==

* Creating an new account is clear structured and requires only a few data (new user name, provider and a password) from the user. The list of the provider sounds not very confidential to someone who is not familiar with "jabber". So it would useful to give the user some help.
The same would be necessary down to the option "Verbinden über Tor (Benötigt Orbotapp)" - I think some of the user don't know what this item means.
One solution could be an infomationbutton next to the pointed problems.

[[File:nutzerstudien_anmeldung_create.png | 200 px]]
[[File:nutzerstudien_anmedlung_create_jabberanbieter.png | 200 px]]

* For the existing account I think there are no problems. The person, which already own a jabber account has engaged with "jabber" an know the basic things.

== User control an freedom ==

== Consistency and standards ==

* You can swap right an left to change from your contactlist to all open chats. Pull from the left side wil open the menu. All these are typical moves to use an smartphone.

* The Language is easy to unterstand and they use known terms. But there is no continuous language - somtimes its in englisch and sometimes in german, so you have to switch between these two languages.
It would be better if there is used one language. There are two possibilities to solve the problem. The first would be only present the app in englisch (language of the developer) and the second would be to present two different versions - one in englisch and one in german.

* the menu is partially clear. But there is one items, which is confusing.
The "panic - button" enables the user to cancel the app but there is an extra security query, if he really want to cancel.

[[File:nutzerstudien_menu1.png | 200 px]]
[[File:nutzerstudien_panic_abfrage.png | 200 px]]

== Error prevention ==

* There ist no error prevention, within the app there are too many error messages and there is no helping function.

== Recognition rather than recall ==

== Flexibility and efficiency of use ==

* Can't found any difference between novice and expert users.

== Aesthetic and minimalist design ==

* It is an clear an simple design

== Help users recognize, diagnose, an recover from errors ==

* There are a lot off bugs within the app and most of the time ChatSecure close the app an asks the user if he would send a report to the developer. In some case there are warnungs or error messages

[[File:nutzerstudien_crash.png | 200 px]]
[[File:nutzerstudien_crash_data.png | 200 px]]

== help an documentation ==

A lot of things are intuitiv, if you are familiar in handling a smartphone.
But there are also a lot of bugs and mistakes within the app and there are also some „wrong“ or some unexpected reaction.
A few functions do not accord with the norm or there is a other reaction as you would expect in reality.
So an documentation would be very helpful.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung Person2

2014-01-23T13:05:44Z

AnjaR: /* Consistency and standards */

Aufgaben:
* Anmelden
* Account erstellen
* Einstellungen ("Settings")
{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==

* Your own status is shown in the space above your contacts. So it seems to be the status of all your contact. This is slightly confusing. But with a klick on the green circle you can change your status and realize that this is your own status.

[[File:nutzerstudien_start_status.png | 200 px]]

* During the chat, all your messages are marked with a color and show you the security of your message. The colors distinguish between red (unsafe), yellow (only safe from one contact) and green (safe). In addition to the colors, there ist also a lock, which shows you the status of security. If the ciphering break down, there is a warning for the user.

[[File:nutzerstudien_verschluesselung_beendet.png | 200 px]]

* Feedback of a lot of functions do not exist, so the user don‘t know what happend, for example when you try to start OTR and the contact isn't online, then there appears a permanent rotary circle but nothing happens.

[[File:nutzerstudien_rotierender_kreis.png | 200 px]]

== Match between system an the real world ==

* Creating an new account is clear structured and requires only a few data (new user name, provider and a password) from the user. The list of the provider sounds not very confidential to someone who is not familiar with "jabber". So it would useful to give the user some help.
The same would be necessary down to the option "Verbinden über Tor (Benötigt Orbotapp)" - I think some of the user don't know what this item means.
One solution could be an infomationbutton next to the pointed problems.

[[File:nutzerstudien_anmeldung_create.png | 200 px]]
[[File:nutzerstudien_anmedlung_create_jabberanbieter.png | 200 px]]

* For the existing account I think there are no problems. The person, which already own a jabber account has engaged with "jabber" an know the basic things.

== User control an freedom ==

== Consistency and standards ==

* You can swap right an left to change from your contactlist to all open chats. Pull from the left side wil open the menu. All these are typical moves to use an smartphone.

* The Language is easy to unterstand and they use known terms. But there is no continuous language - somtimes its in englisch and sometimes in german, so you have to switch between these two languages.
It would be better if there is used one language. There are two possibilities to solve the problem. The first would be only present the app in englisch (language of the developer) and the second would be to present two different versions - one in englisch and one in german.

* the menu is partially clear. But there is one items, which is confusing.
The "panic - button" enables the user to cancel the app but there is an extra security query, if he really want to cancel.

[[File:nutzerstudien_menu1.png | 200 px]]
[[File:nutzerstudien_panic_abfrage.png | 200 px]]

== Error prevention ==

* There ist no error prevention, within the app there are too many error messages and there is no helping function.

== Recognition rather than recall ==

== Flexibility and efficiency of use ==

* Can't found any difference between novice and expert users.

== Aesthetic and minimalist design ==

* It ist an clear an simple design

== Help users recognize, diagnose, an recover from errors ==

* There are a lot off bugs within the app and most of the time ChatSecure close the app an asks the user if he would send a report to the developer. In some case there are warnungs or error messages

[[File:nutzerstudien_crash.png | 200 px]]
[[File:nutzerstudien_crash_data.png | 200 px]]

== help an documentation ==

A lot of things are intuitiv, if you are familiar in handling a smartphone.
But there are also a lot of bugs and mistakes within the app and there are also some „wrong“ or some unexpected reaction.
A few functions do not accord with the norm or there is a other reaction as you would expect in reality.
So an documentation would be very helpful.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung Person2

2014-01-23T13:02:10Z

AnjaR: /* Consistency and standards */

Aufgaben:
* Anmelden
* Account erstellen
* Einstellungen ("Settings")
{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==

* Your own status is shown in the space above your contacts. So it seems to be the status of all your contact. This is slightly confusing. But with a klick on the green circle you can change your status and realize that this is your own status.

[[File:nutzerstudien_start_status.png | 200 px]]

* During the chat, all your messages are marked with a color and show you the security of your message. The colors distinguish between red (unsafe), yellow (only safe from one contact) and green (safe). In addition to the colors, there ist also a lock, which shows you the status of security. If the ciphering break down, there is a warning for the user.

[[File:nutzerstudien_verschluesselung_beendet.png | 200 px]]

* Feedback of a lot of functions do not exist, so the user don‘t know what happend, for example when you try to start OTR and the contact isn't online, then there appears a permanent rotary circle but nothing happens.

[[File:nutzerstudien_rotierender_kreis.png | 200 px]]

== Match between system an the real world ==

* Creating an new account is clear structured and requires only a few data (new user name, provider and a password) from the user. The list of the provider sounds not very confidential to someone who is not familiar with "jabber". So it would useful to give the user some help.
The same would be necessary down to the option "Verbinden über Tor (Benötigt Orbotapp)" - I think some of the user don't know what this item means.
One solution could be an infomationbutton next to the pointed problems.

[[File:nutzerstudien_anmeldung_create.png | 200 px]]
[[File:nutzerstudien_anmedlung_create_jabberanbieter.png | 200 px]]

* For the existing account I think there are no problems. The person, which already own a jabber account has engaged with "jabber" an know the basic things.

== User control an freedom ==

== Consistency and standards ==

* You can swap right an left to change from your contactlist to all open chats. Pull from the left side wil open the menu. All these are typical moves to use an smartphone.

* The Language is easy to unterstand and they use known terms. But there is no continuous language - somtimes its in englisch and sometimes in german, so you have to switch between these two languages.
It would be better if there is und one language. There are two possibilities to solve the problem. The first would be only present one app in englisch (language of the developer) and the secend would be to present two different version - one in englisch and one in german.

* the menu is partially clear. There is one items, which is confusing.
The "panic - button" enables the user to cancel the app but there is an extra security query, if he really want to cancel.

[[File:nutzerstudien_menu1.png | 200 px]]
[[File:nutzerstudien_panic_abfrage.png | 200 px]]

== Error prevention ==

* There ist no error prevention, within the app there are too many error messages and there is no helping function.

== Recognition rather than recall ==

== Flexibility and efficiency of use ==

* Can't found any difference between novice and expert users.

== Aesthetic and minimalist design ==

* It ist an clear an simple design

== Help users recognize, diagnose, an recover from errors ==

* There are a lot off bugs within the app and most of the time ChatSecure close the app an asks the user if he would send a report to the developer. In some case there are warnungs or error messages

[[File:nutzerstudien_crash.png | 200 px]]
[[File:nutzerstudien_crash_data.png | 200 px]]

== help an documentation ==

A lot of things are intuitiv, if you are familiar in handling a smartphone.
But there are also a lot of bugs and mistakes within the app and there are also some „wrong“ or some unexpected reaction.
A few functions do not accord with the norm or there is a other reaction as you would expect in reality.
So an documentation would be very helpful.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung Person2

2014-01-23T12:54:55Z

AnjaR: /* Match between system an the real world */

Aufgaben:
* Anmelden
* Account erstellen
* Einstellungen ("Settings")
{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==

* Your own status is shown in the space above your contacts. So it seems to be the status of all your contact. This is slightly confusing. But with a klick on the green circle you can change your status and realize that this is your own status.

[[File:nutzerstudien_start_status.png | 200 px]]

* During the chat, all your messages are marked with a color and show you the security of your message. The colors distinguish between red (unsafe), yellow (only safe from one contact) and green (safe). In addition to the colors, there ist also a lock, which shows you the status of security. If the ciphering break down, there is a warning for the user.

[[File:nutzerstudien_verschluesselung_beendet.png | 200 px]]

* Feedback of a lot of functions do not exist, so the user don‘t know what happend, for example when you try to start OTR and the contact isn't online, then there appears a permanent rotary circle but nothing happens.

[[File:nutzerstudien_rotierender_kreis.png | 200 px]]

== Match between system an the real world ==

* Creating an new account is clear structured and requires only a few data (new user name, provider and a password) from the user. The list of the provider sounds not very confidential to someone who is not familiar with "jabber". So it would useful to give the user some help.
The same would be necessary down to the option "Verbinden über Tor (Benötigt Orbotapp)" - I think some of the user don't know what this item means.
One solution could be an infomationbutton next to the pointed problems.

[[File:nutzerstudien_anmeldung_create.png | 200 px]]
[[File:nutzerstudien_anmedlung_create_jabberanbieter.png | 200 px]]

* For the existing account I think there are no problems. The person, which already own a jabber account has engaged with "jabber" an know the basic things.

== User control an freedom ==

== Consistency and standards ==

* You can swap right an left to change from your contactlist to all open chats. Pull from the left side wil open the menu. All these are typical moves to use an smartphone.

* The Language is easy to unterstand and they use known terms. But there is no continuous language - somtimes its in englisch and somatimes in german, so you have to switch between these two languages.
It would be better if there is und one language. There are two possibilities to solve the problem. The first would be only present one app in englisch (language of the developer) and the secend would be to present two different version - one in englisch and one in german.

* the menu is partially clear. There is one items, which is confusing.
The "panic - button" enables the user to cancel the app but there is an extra security query, if he really want to cancel.

[[File:nutzerstudien_menu1.png | 200 px]]
[[File:nutzerstudien_panic_abfrage.png | 200 px]]

== Error prevention ==

* There ist no error prevention, within the app there are too many error messages and there is no helping function.

== Recognition rather than recall ==

== Flexibility and efficiency of use ==

* Can't found any difference between novice and expert users.

== Aesthetic and minimalist design ==

* It ist an clear an simple design

== Help users recognize, diagnose, an recover from errors ==

* There are a lot off bugs within the app and most of the time ChatSecure close the app an asks the user if he would send a report to the developer. In some case there are warnungs or error messages

[[File:nutzerstudien_crash.png | 200 px]]
[[File:nutzerstudien_crash_data.png | 200 px]]

== help an documentation ==

A lot of things are intuitiv, if you are familiar in handling a smartphone.
But there are also a lot of bugs and mistakes within the app and there are also some „wrong“ or some unexpected reaction.
A few functions do not accord with the norm or there is a other reaction as you would expect in reality.
So an documentation would be very helpful.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity

2014-01-17T14:14:38Z

AnjaR:

== Visibility of system status ==
* When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

* If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

* After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

* Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

* Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

* When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

* A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

* After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

* If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

* If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

* If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

* Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

* Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

* Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

[[File:Screenshot_2014-01-15-11-35-15.png]]

== Aesthetic and minimalist design ==

* The menu is a mix of German and English words. It would be better if it would be limited to one language.

[[File:Screenshot_2014-01-15-11-09-33.png]]

* After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

* In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

* I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

* A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-17T14:13:30Z

AnjaR:

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
* When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

* If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

* After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

* Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

* Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

* When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

* A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

* After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

* If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

* If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

* If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

* Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

* Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

* Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

[[File:Screenshot_2014-01-15-11-35-15.png]]

== Aesthetic and minimalist design ==

* The menu is a mix of German and English words. It would be better if it would be limited to one language.

[[File:Screenshot_2014-01-15-11-09-33.png]]

* After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

* In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

* I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

* A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:28:45Z

AnjaR: /* Flexibility and efficiency of use */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

[[File:Screenshot_2014-01-15-11-35-15.png]]

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

[[File:Screenshot_2014-01-15-11-09-33.png]]

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:28:03Z

AnjaR: /* Aesthetic and minimalist design */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

[[File:Screenshot_2014-01-15-11-09-33.png]]

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:27:00Z

AnjaR: /* Error prevention */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

[[File:Screenshot_2014-01-09-11-16-06.png]]

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:26:14Z

AnjaR: /* Error prevention */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

[[File:Screenshot_2014-01-09-11-05-47.png]] [[File:Screenshot_2014-01-09-11-06-17.png]]

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:24:50Z

AnjaR: /* Match between system and the real world */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:24:21Z

AnjaR: /* Match between system and the real world */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

[[File:Screenshot_2014-01-09-11-35-19.png]]

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

[[File:Screenshot_2014-01-09-11-35-19.png]]

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

File:Screenshot 2014-01-15-11-35-15.png

2014-01-16T10:23:07Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screenshot 2014-01-15-11-09-33.png

2014-01-16T10:22:55Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screenshot 2014-01-09-11-16-06.png

2014-01-16T10:22:40Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screenshot 2014-01-09-11-06-17.png

2014-01-16T10:22:25Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screenshot 2014-01-09-11-05-47.png

2014-01-16T10:22:10Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screenshot 2014-01-09-11-35-19.png

2014-01-16T10:21:52Z

AnjaR: uploaded a new version of "File:Screenshot 2014-01-09-11-35-19.png"

== Summary ==

== Copyright status: ==

== Source: ==

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:19:07Z

AnjaR: /* Match between system and the real world */

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.
[[File:Screenshot_2014-01-09-11-35-19.png]]

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

File:Screenshot 2014-01-09-11-35-19.png

2014-01-16T10:18:17Z

AnjaR:

== Summary ==

== Copyright status: ==

== Source: ==

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisSecurity Person5

2014-01-16T10:09:46Z

AnjaR:

Aufgaben:
* Neuen Kontakt hinzufügen
* Nachricht verschicken auf den Wegen:
** Unsicher
** Verschlüsselt
** Authentifiziert

{{IFD_Nutzerstudien_HeuristischeEvaluationAnweisungen}}

== Visibility of system status ==
When you click on the lock and afterwards on "Start OTR”, a charging circle appears on the left side of the lock. This is helpful to show the user that something happens and the app is working. If the contact is offline the loading circle "boosts" permanent and it happens nothing. Thus the user gets no information what’s happens now.

If you click on "verify fingerprint" and afterwards on "OK", the window just closes without a message to the user. So he doesn’t know the current status.

After "verify Key" appears at once a green marker at the message, but the lock is still showing up with a yellow question mark. The contact bar at the top is also shown in yellow. Thus the user does not know the actually state.

== Match between system and the real world ==

Clicking the lock with red cross shows "Start OTR". Maybe some unskilled users will not know that “OTR” means Off-the-Record Messaging. So they don’t know, if OTR is about the encryption or not.

Use of traffic light colors (red, yellow, green) is known to the user from the real world. However, for first time users may not be immediately clear what color means what.

When sending an image it has a yellow label, but the message before and after are marked green. The user don’t know why.

A message is marked in green but under the message comes a cross. The message is encrypted but was not sent? Maybe the user will be confused.

== User control and freedom ==

After select a function (encryption, add file, menu) in an open chat you just click in the chat box which is still visible. This is intuitive as undo and sufficient.

If you are in the chat and would like to go back to the list of contacts, this is possible by swiping to the left or clicking back button (Samsung phone). The swiping isn’t very intuitive.

== Consistency and standards ==

If you click on a message the window to "Verify" open. This isn’t expected by the users because this action should come only by clicking the lock. Moreover, it leads to confusion when the message is already marked as green but still opens a window for verification.

== Error prevention ==

If you have already opened the keyboard to write a message and then goes back to the contact view, the keyboard is still open. Typing some characters and they are displayed in an over layer. (Screenshot) If you now close the keyboard this text is still be shown, even if you move to another contact. The keyboard should therefore be closed automatically when you go back to the contact list in order to avoid such errors.

Contact appears offline even though it is online. The chat with the contact, however, is still possible.

== Recognizing rather than recall ==

Open the contact view from a chat window (swipe to the left) is not intuitive. Instead of the way to swipe to the previous and next contact, you could always put a link to the contact list.

== Flexibility and efficiency of use ==

Change the status is hidden behind a small green dot. This function is therefore only for experienced users or people who click anywhere discoverable. That’s okay, because in my opinion this feature is not absolutely necessary. A personally design is not possible with the App.

== Aesthetic and minimalist design ==

The menu is a mix of German and English words. It would be better if it would be limited to one language.

After starting OTR a lock with a yellow question mark appears above. Now the messages have a yellow mark. When you click on the question mark, the possibility of verifying and ending the OTR appears (Verify Key / Beende OTR). Here the German / English mix is also unfavorable for the user.

In the top status bar of the phone, a corresponding icon is displayed in case of a new message. This icon is useful if the app is not open yet. However, the Chat Secure icon is also shown in the status bar permanently if the app is running. That means if you get a message you have 2 icons of Chat Secure in the status bar. Will there be more icons of WhatsApp etc. the bar will be full very quickly. Therefore the always visible Chat Secure icon should be removed.

== Help users recognize, diagnose, and recover from errors ==

I have not received any error message from the app. Therefore, no statement about the intelligibility of the message and the quality of the solution paths are taken.

== Help and dokumentation ==

A help is not available in the menu. This would be very helpful for "beginners". E.g. the traffic light system for the security of the message isn’t immediately clear.

IFD:Nutzerstudien WiSe1314/Sicherheit (security)

2013-12-13T16:33:50Z

AnjaR: /* Data Gathering: Interviews/Observation */

==Aims of data gathering==

We wanted to know how to improve the design and/or functions in Chat-Secure, regarding the security-problem. People should immediatly see that it's a secure chat through its interface. So we searched for possible symbols that provide security and tried out some designs to improve the current look of the chat.



== Data Gathering: Interviews/Observation ==

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them. We asked them about their chat behavior in general and especially how they think about security.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 20-25
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

Main questions: 

* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

== Data Analysis ==
How we analysed the data: We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

==Main Results Data Analysis==

'''Results:'''
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a programm or message is secure or not
* OpenSource programms provide trust
* The design should be functional AND appealing

What we learned from our user research: We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan partys in a chat, so the group function could be necessary and image transfer is also an important factor of communication for most people.

It was also interessting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug
However, they did not try to find an alternative. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.

==What specifc problem we want to solve==

The interface should communicate security to the user. Therefor we want to improve the interface of ChatSecure in a way, that everyone is possible to understand what is meant with the symbols.
To create such a design, we drew some of our own design-ideas on a paper. It showed the message window and some applications and icons we added to it, e.g. the lock symbol next to the Accountname and in the speech bubbles itself. These things intensify the security-feeling. Then we discussed those ideas, made a prototype and tested it on a comrade who wasn`t in our working group.

<div style="color:darkgreen">Please include a sketch or photo; otherwise it is hard to understand that you refer to. --[[User:JanD|JanD]] 10:19, 13 December 2013 (CET)</div>

==Plans – how we want to solve the problem(s)==
The ideas of last week worked quite well, but not properly understandable. The problem of the red color we`d chosen for the Send-Button for an insecure message didn't work out. Our test subject thought the button couldn't be clicked at all.
So, in the next week, we would look for similiar applications and how they deal with authentification and security methaphors. After that, we would improve our prototype with the results of the last weeks and try out different approaches to solve our problems, regarding the prototype itself, the layout and the colours. Then we would test it again.



==Images==

IFD:Nutzerstudien WiSe1314/Sicherheit (security)

2013-12-13T16:32:30Z

AnjaR: /* Data Gathering: Interviews/Observation */

==Aims of data gathering==

We wanted to know how to improve the design and/or functions in Chat-Secure, regarding the security-problem. People should immediatly see that it's a secure chat through its interface. So we searched for possible symbols that provide security and tried out some designs to improve the current look of the chat.



== Data Gathering: Interviews/Observation ==

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them. We asked them about their chat behavior in general and especially how they think about security.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 25-30
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

Main questions: 

* What chats do you use?
* Are you happy with them or would you want to improve something?
* Which functions are important for you?
* Have you ever think about the security in the chat programs?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

== Data Analysis ==
How we analysed the data: We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

==Main Results Data Analysis==

'''Results:'''
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a programm or message is secure or not
* OpenSource programms provide trust
* The design should be functional AND appealing

What we learned from our user research: We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan partys in a chat, so the group function could be necessary and image transfer is also an important factor of communication for most people.

It was also interessting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug
However, they did not try to find an alternative. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.

==What specifc problem we want to solve==

The interface should communicate security to the user. Therefor we want to improve the interface of ChatSecure in a way, that everyone is possible to understand what is meant with the symbols.
To create such a design, we drew some of our own design-ideas on a paper. It showed the message window and some applications and icons we added to it, e.g. the lock symbol next to the Accountname and in the speech bubbles itself. These things intensify the security-feeling. Then we discussed those ideas, made a prototype and tested it on a comrade who wasn`t in our working group.

<div style="color:darkgreen">Please include a sketch or photo; otherwise it is hard to understand that you refer to. --[[User:JanD|JanD]] 10:19, 13 December 2013 (CET)</div>

==Plans – how we want to solve the problem(s)==
The ideas of last week worked quite well, but not properly understandable. The problem of the red color we`d chosen for the Send-Button for an insecure message didn't work out. Our test subject thought the button couldn't be clicked at all.
So, in the next week, we would look for similiar applications and how they deal with authentification and security methaphors. After that, we would improve our prototype with the results of the last weeks and try out different approaches to solve our problems, regarding the prototype itself, the layout and the colours. Then we would test it again.



==Images==

IFD:Nutzerstudien WiSe1314/Sicherheit (security)

2013-12-13T16:26:55Z

AnjaR: /* Data Gathering: Interviews/Observation */

==Aims of data gathering==

We wanted to know how to improve the design and/or functions in Chat-Secure, regarding the security-problem. People should immediatly see that it's a secure chat through its interface. So we searched for possible symbols that provide security and tried out some designs to improve the current look of the chat.



== Data Gathering: Interviews/Observation ==

We interwiewed ten people of these courses of studies below. Since we all studies something similar we had an easy access to them. We asked them about their chat behavior in general and especially how they think about security.

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Media Science
|-
| 2
| 20-25
| Computer Science
|-
| 3
| 20-25
| Business Economics
|-
| 4
| 25-30
| Computer Science
|-
| 5
| 20-25
| Computer Science
|-
| 6
| 20-25
| Computer Science
|-
| 7
| 20-25
| Computer Science and Media
|-
| 8
| 20-25
| Computer Science and Media
|-
| 9
| 20-25
| Media Arts/Media Design
|-
| 10
| 25-30
| Game Design
|}

Main questions: 

* What chats do you use?
* Are you happy with them or would you want to improve something?
* Are you feeling secure in your currently used chats? If no, did you restrict yourself in some way and how far?
* What are the limits of effort you would accept to feel safer in a chat?
* Have you ever been attacked before?

== Data Analysis ==
How we analysed the data: We searched for specific answers in the interviews and looked how it could help to spot a problem. Then we put all our results together and created an affinity diagramm.

==Main Results Data Analysis==

'''Results:'''
* Most people use chat programs that are unsafe. The amount of friends that use a specific chat is more important
* Standard functions like Smileys and data/picture transfer should be offered
* There should be a function to create a group discussion
* Chats are used for job messages as for private ones
* User want to see (e.g. by a lock-symbol), if a programm or message is secure or not
* OpenSource programms provide trust
* The design should be functional AND appealing

What we learned from our user research: We got a lot of information about the requirements and the possible use of a chat application. The most important features people wanted to be part of such an application where group chat functionality, image transfer, smileys and an easy to use but appealing interface. People often want to plan partys in a chat, so the group function could be necessary and image transfer is also an important factor of communication for most people.

It was also interessting for us to find out that the main percentage of the users know about possible security issues:
* fear of being in a computer surveillance/being watched in general
* fear of theft of an account/a mobile device
* e.g. personal messages were posted on the pinboard because of a Facebook bug
However, they did not try to find an alternative. Related to this we also found out that people using chat software for business had much more concerns about their personal information and especially the topic and content of the talk then the private users.

==What specifc problem we want to solve==

The interface should communicate security to the user. Therefor we want to improve the interface of ChatSecure in a way, that everyone is possible to understand what is meant with the symbols.
To create such a design, we drew some of our own design-ideas on a paper. It showed the message window and some applications and icons we added to it, e.g. the lock symbol next to the Accountname and in the speech bubbles itself. These things intensify the security-feeling. Then we discussed those ideas, made a prototype and tested it on a comrade who wasn`t in our working group.

<div style="color:darkgreen">Please include a sketch or photo; otherwise it is hard to understand that you refer to. --[[User:JanD|JanD]] 10:19, 13 December 2013 (CET)</div>

==Plans – how we want to solve the problem(s)==
The ideas of last week worked quite well, but not properly understandable. The problem of the red color we`d chosen for the Send-Button for an insecure message didn't work out. Our test subject thought the button couldn't be clicked at all.
So, in the next week, we would look for similiar applications and how they deal with authentification and security methaphors. After that, we would improve our prototype with the results of the last weeks and try out different approaches to solve our problems, regarding the prototype itself, the layout and the colours. Then we would test it again.



==Images==

IFD:Nutzerstudien WiSe1314/firstUseChatSecure

2013-11-20T10:37:13Z

AnjaR:

Bitte hier Probleme und (Usability)-Bugs Eintragen

'''Please report problems like this:'''

* What happened: [I did… and… etc.]
* What should have happened: [After… the … should have… so that…]

''Be clear on what you refer to''. Be specific and make it easy to understand. Refer to elements by their "official terms" (like "link") or by describing them, if you dont know exactly how they are called ("the underlined text you can click on"). Rather use a term twice than saying "it" or "that thing", because "it" can be basicly anything.

Remember: if the problem would be easy to see for the developer, that person would have fixed it.

The more specific you are and the clearer you can descibe when and when not the problem occurrs that faster the problem can be fixed

==can't avoid icon in statusbar==
''What happened:'' As long as chat secure is not manually closed, the chat secure icon appears in the top bar. The "Chat secure online" message/icon can not be dismissed by swiping the system-message.

''What should happen:'' The icon should only be present if there are messages or problems that need my attention, at least it should be possible to dimiss the indicator by swiping on the system message.
Look at the behaviour of whatsapp as an example.

==log in-trouble==
What exactly caused the trouble?

Ich kann mich anmelden (Schalter on-off), dann will ich meinen Status auf Online stellen und es kommt die Meldung "Du bist nicht angemeldet"
Keine Lösung für das Problem, daher auch kein Chat möglich.

''War das Passwort etc. 'richtig'? Wenn nicht, gab es außer "du bist nicht angemeldet" andere Hinweise darauf?''--[[User:JanD|JanD]] 12:18, 19 November 2013 (CET)

==creating account difficulties==
What did you try to create an account? What were the applications reactions? Did you manage to solve the problem, and if yes, how?

==Logout not immediantly obvious; I didn`t know it was the checkmark==

Ich wusste nicht, dass der Haken abmelden bedeutet. Erwartungen, was es überhaupt sein könnte, habe ich mir vorher gar keine gemacht. Eine einfache Zusatzleiste bei Konten, Kontakte hinzufügen usw. wo dann "Abmelden" draufstünde, würde es meiner Meinung nach auch tun und ersichtlicher sein.

Describe where the checkmark was. What did you expect the checkmark to be?

==Durch diesen Schiebemechanismus passiert es leicht, aus Versehen einer falschen Person zu schreiben. (Der Name, der beim Chat oben steht, ist recht unscheinbar.)==

Was passiert ist: Ich habe mich verscrollt und so einer falschen Person geschreiben.

Was sollte passieren: Ich hatte einer anderen Person schreiben wollen. Evtl. wäre ein einfacher Klick auf entsprechende Person besser gewesen als ein Schiebemechanismus.

---------
''Kannst du das aufteilen in "was passiert" (Beschreibung, das du einer falschen Person geschrieben hast und warum)
und "was sollte passieren" (e.g. einen anderen Mechanismus um die Person auszuwählen)''

''PS.: Eine gute Beobachtung, hat mich auch schon öfter gestört. Später im Werkmodul zeige ich noch, was die Gründe für diese Problem sind. (mit den [http://www.nngroup.com/articles/ten-usability-heuristics/ Regeln für Interfaces] kannst du es aber auch selber schnell herrausfinden)''

==Jede Person taucht zwei Mal in der Kontaktliste auf. Man kann aber nur mit einer davon kommunizieren, kann also die unnötige löschen. Dennoch umständlich.==

==functions==
Try to add a picture to the chat - gallery opened - i choosed one image and the gallery closed - nothing happens, there is no image in my chat

try to send a file - dropbox app opened -> only the use of dropbox possible to send an other file?

push the trash icon - the complete chat protocol deleted without some control question

==switch between profile view and chat view==
the Switch isnt intuitive (you have to click on the profile)

IFD:Nutzerstudien WiSe1314

2013-10-28T12:15:06Z

AnjaR: /* Vortragsthemen| student presentations */

=Werkmodul Nutzerstudien/Sicherheit und Benutzbarkeit=


===Aktuelles===
* Ein Teil der Aufgaben werden im Medienwiki (auf dieser Website also) bearbeitet werden. Bitte informiert euch wie ihr euch [https://www.youtube.com/watch?v=3oJF0G25q9Q Anmelden], [https://www.youtube.com/watch?v=PVBOAyd_1Zw Editieren], [https://www.youtube.com/watch?v=hLoOpqCyos0 Formatieren] und [https://www.youtube.com/watch?v=P42Une7fC_g Unterseiten anlegen] könnt (Videos dazu in den Links).

==Beschreibung==
[[File:Messaging_CC2BY_FlickrUser-Håkan_Dahlström.jpg|thumb|right|300px|wer liest mit? ([http://flickr.com/photos/dahlstroms/8041061787/sizes/k/in/photostream/ Bild: Dahlström, CC-BY])]]
[[File:6930835797 2db7044d34 b.jpg|thumb||right|200px|Interviewen]]
[[File:ExploreChallenge CC-BY-2 FlickrUserServicedesignberlin.jpg|thumb|right|200px|Analysieren]]
''Warum ist eine App nützlich und nutzbar, eine andere nicht?''
''Wie kann ich herrausfinden was meine Nutzer brauchen?''

Im Werkmodul Nutzerstudien werden wir Design und die Funktionen von Apps zur sicheren Kommunikation entwickeln und verbessern.

Wir werden:
* Durch unsere Gespräche und Beobachtungen mehr über Nutzer lernen
* Lernen, welche psychologischen Prinzipien bestimmen, ob etwas leicht oder schwierig zu benutzen ist und damit Designen.
* Wir werden unsere Designs ausprobieren lassen und so Verbesserungsmöglichkeiten erkennen und neue Ideen bekommen.



Um zu lernen, wie wir diese Methoden in der Praxis anwenden, haben wir eine Praxiskooperation mit dem [https://guardianproject.info/ Guardian Project]. Wir haben die Aufgabe, sichere Kommunikation über mobile Apps zu verbessern. Mitarbeiter des Projektes werden uns beraten und Feedback für eure Ideen geben.

Kommunikation, die nicht einfach abgehört oder Personen zugeordnet werden kann, ist für Bürgerrechtler und Journalisten essentiell, wird aber auch von Personen verwendet, die ihre Rechte im Netz nicht geschützt sehen.

Leider ist die Nutzung solcher Methoden nicht einfach. Sicherheitsexperte Bruce Schneier z.B. [http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance gibt Tips], sieht diese Tips aber kritisch, denn: ''»My five tips [for more security] suck. They are not things the average person can use. […] Basically, the average user is screwed.«'' (aus einem [http://www.technologyreview.com/news/519336/bruce-schneier-nsa-spying-is-making-us-less-safe/ Interview mit dem MIT Technology Review]) Zwar wird oft auf [https://en.wikipedia.org/wiki/Rtfm »Nutzererziehung«] verwiesen. Das Argument entschuldigt auch die unbenutzbarsten Lösungen – und selbst erfahrene [http://www.gaudior.net/alma/johnny.pdf Nutzer scheitern] z.B. an Verschlüsselungsprogrammen. Besser wären Lösungen, die praktisch, gut benutzbar und sicher sind. Wir wollen zu solchen Lösungen beitragen.

==Häufige Fragen==

'''Muss ich Programmieren können?''' Nein.

'''Ist das hier alles theoretisch?''' Nein, der Kurs ist nicht theoretisch, im Gegenteil, wir werden die gelehrten Methoden anwenden und sie nutzen, um eine anwendbare, praktische Lösung für Probleme zu schaffen.

'''Ist das wissenschaftlich?''' Jein. Es ist [http://de.wikipedia.org/wiki/Naturwissenschaft wissenschaftlich] in dem Sinne, das die Gestaltung auf (eigenen) Erkenntnissen beruht, die wir auch [http://de.wikipedia.org/wiki/Kritischer_Rationalismus kritisch hinterfragen]. Nicht wissenschaftlich ist, das wir konkrete Probleme lösen, anstatt ein allgemeines Modell zu erstellen. (Vergleiche "Wie verhindere ich, das es umfällt?" mit "warum fallen Dinge nach unten?")

==Voraussetzungen==
* Bereitschaft zu eigener Forschung und Weiterentwicklung von Ideen. Mit einem Konzept, dessen Umsetzung für euch schon absolut feststeht, wird der Kurs freud- wie erkenntnislos.

* Texte auf Englisch lesen, denn es gibt wenig Literatur zu dem Gebiet auf deutsch. Wir lesen nicht viel, und ich wähle keine Texte aus, die den Leser mit [http://dev.null.org/postmodern/ nebulös-abstrakten] Begriffen beeindrucken. Aber es ist hilfreich, sich damit zu beschäftigen was andere bisher herausgefunden haben.

==Bewertung==
* Dokumentation (im Wiki, dabei an die Struktur des Arbeitsbuches halten)
* Vortrag
* Anwesenheit (regelm., max 3x fehlen)

==Anmelden==
Mail an ''jan.dittrich ÄT uni-weimar.de'' mit
* Name, Vorname
* Matrikelnummer
* Studiengang
* Kurzer Text der erklärt, warum ihr Teilnehmen möchtet.

==Vortragsthemen| ''student presentations''==
''Mögliche Vortragsthemen. Bitte nutzt die bereitgestellten Quellen, und macht dann eine eigene Recherche. Bereitet das Thema auf, macht es [http://dilbert.com/strips/comic/2010-01-18/ anschaulich] und nicht einfach nur eine Nacherzählung der Quellen (oder der Stichpunkte auf den Slides).''

'''Vortragsdauer: 15-20min'''
* 7.11 Attacks based on Psychology, [http://www.cl.cam.ac.uk/~rja14/book.html Security Engineering, Chapter 2.2] (Lisa Guth)
* 14.11 Personas: About Face 3, ISBN 0470084111, (page 75-81, 97-106)
* 21.11 'Service Blueprinting, [http://knowledge.wpcarey.asu.edu/article.cfm?articleid=1546 intro], [[wikipedia:Service blueprint|Wikipedia]], [http://www.flickr.com/photos/brandonschauer/3363169836/ template]
* 28.11 Security and Usability: The Case of passwords: [http://www.nngroup.com/articles/security-and-human-factors/ Norman/Nielsen on Sign-On-Usability], [http://www.cl.cam.ac.uk/~rja14/book.html Security Engineering, Chapter 2.4], [https://xkcd.com/936/ xkcd on password strength] (Anna Krieger)
* 05.12 "Intuitivität" [http://www.asktog.com/papers/raskinintuit.html Intuitive = Familiar], [http://www.uie.com/articles/design_intuitive/ The Intuition Gap]
*12.12. Kein Vortrag
*19.12. Prototyping-Tools: [http://pencil.evolus.vn/ Pencil], [http://jquery.com/ jQuery] (Anja Rathgeber)
* 19.12. Parallel Prototyping: [http://www.sigchi.org/chi95/proceedings/shortppr/so_bdy.htm 1995], [http://aaalab.stanford.edu/papers/Parallel_Prototyping_2010.pdf 2010]
* 9.1 Knowledge in the Head, Knowledge in the World. In "The Design of Everyday Things" ("Alltägliche Dinge"), Donald Norman, ISBN 0465067107 (Psychologischer Fokus) (Susanne Pötzsch)
* 16.1. [http://www.gaudior.net/alma/johnny.pdf Why Johnny can't encrypt] a classic Security/HCI paper.
* 23.1. Paper: [http://technology.open.ac.uk/design/cross/documents/DesignerlyWaysofKnowing.pdf Designerly Ways of knowing]





==Zeitplan==
* '''24.10''': Einführung | ''Introduction''
* '''31.10''' : ''Feiertag''
* '''7.11''': Security
* '''14.11''' : Nutzerforschung: Beobachten und Fragen stellen | ''User Research: Observing and Asking Questions''
* '''21.11''': Datenanalyse, Szenarioerstellung | ''Analyse Data, Create Scenarios''
* '''28.11''': Idenentwicklung | ''Idea Development''
* '''5.12.: Prototyping
[…]
* '''12.12''': 1st Feedback round
[…]

==Gruppen==
[[/SicherheitKommunizieren]]

[[/Authentifikation]]

== Presentation and Documentation of Works==
General Presentation and Progress.

==Arbeits & Übungshilfen==
[[File:GuillocheGeldBitcoin.png|thumb|right|100px|"Geldscheinmuster" (zu Interviewbeispiel)]]
* [[IFD:Human-Centered-Design-Research_-_Workbook|"Workbook"]] in Begleitung zur Praktischen Arbeit als Dokumentation, Gedankenstütze und Reflektionsmöglichkeit
* [[Media:Interview IllustratorUse.mp3|Interview/Beobachtung]]: Thema: "Grafiken erstellen"; zum Ausprobieren von Auswertungsmethoden.
''Begriffe'':
Die erwähnten [https://de.wikipedia.org/wiki/Bitcoin "Bitcoins"] sind eine virtuelle Währung; "Offset" bedeutet soviel wie "Abstand".

Die Ergebnisse von Beobachtung und Fragen werden aufbereitet; [[Zusammenhänge Beispielinterview|Hier einige Zusammenhänge]], die sich aus der Audioaufnahme herrausarbeiten lasse.

===Folien===
* [http://webuser.uni-weimar.de/~fudo5114/talks/defineAndFindAudience.html define and find your audience]
* [http://webuser.uni-weimar.de/~fudo5114/talks/BeobachtenFragen.html Beobachten und Fragen]
* [http://webuser.uni-weimar.de/~fudo5114/talks/Datenanalyse.html Datenanalyse]

==Links und Materialien==
===Security/Usability===
* [http://www.cl.cam.ac.uk/~rja14/book.html Security Engineering, Kapitel 2: Usability and Psychology]
* Security and Usability: Designing Secure Systems That People Can Use, Lorrie Faith Cranor, Simson Garfinkel et.al., O'Reilly Media, ISBN 0596008279
* [https://csclub.uwaterloo.ca/media/Off-the-Record%20Messaging:%20Useful%20Security%20and%20Privacy%20for%20IM.html Wie Off-The-Record funktioniert und warum]: Usability, Verbreitbarkeit, Effektivität, "Resilienz"/Fehlerresistenz (von [https://en.wikipedia.org/wiki/Ian_Goldberg Ian Goldberg])
* Usability: [http://jnd.org/dn.mss/when_security_gets_in_the_way.html »When Security gets in the Way«] (D. Norman)

===Kyptografie===
* [https://en.khanacademy.org/math/applied-math/cryptography/modern-crypt/v/the-fundamental-theorem-of-arithmetic-1 The intro to cryptography on Khan Academy] several 3-5min Videos. Easy.
* [http://www.mat-d.com/site/rsa-diffie-hellman-explained-in-3-minutes/ Diffie-Hellman-Key-Exchange] – ca. 2 DINA4 pages Text. How can you get a secret key without ever seeing each other or sending it?
* Zur Belohnung nach der Mathematik: [http://www.schneierfacts.com/ Bruce Schneier Facts]. Es hat keinen Bildungswert, ist aber lustig (wenn man ''sehr'' nerdigen Humor mag)

===Ausprobieren…===
* Mobile Applikationen testen, aber kein Telefon zur Hand? (Aber einen PC?): den [https://developer.android.com/sdk/index.html Android-Simulator] nutzen, der ein Android-System auf eurem Computer simuliert. ("SDK-Tools only" reicht aus). Schaut das [https://www.youtube.com/watch?v=4r3o2eBzyrs erklärende Video] an.
* [https://guardianproject.info/apps/gibber/ Gibberbot]. ist die App, mit der wir u.A. arbeiten werden. Installieren über [https://play.google.com/store/apps/details?id=info.guardianproject.otr.app.im Android Store] oder direkt aus dem [https://guardianproject.info/releases/ChatSecure-v12.6.4-RC3.apk Repository]
* [http://www.pidgin.im/ Pidgin] kann mittels [https://otr.cypherpunks.ca/ OTR-Plugin] sicher mit Gibberbot (und vielen anderen Instant-Messangern) Nachrichten senden.
* man braucht natürlich mindestens einen XMPP-Account. Den kann man z.B. bei [http://einfachjabber.de/reg einfachjabber] oder [https://dukgo.com/blog/using-pidgin-with-xmpp-jabber dukgo] anlegen.

===Bücher Design===
* Interaction Design: Beyond Human-Computer Interaction – Preece, Rogers and Sharp, ISBN 978-0470665763 ''Interaktionsdesign-Bezug, darin aber sehr umfassender Überblick''

* Observing the User Experience: A Practitioner's Guide to User Research, Kuneavski, ISBN 978-1558609235

===Human Centered Design===

* [[Media:Ideo hcd toolkit final CC-BY-SA-NC.pdf|HCD Toolkit]] der Designagentur IDEO (steht unter [http://creativecommons.org CC])
* [[IFD:Course_Interaction_Design|Interaktionsdesign-Kurs]] Ein Script zu einem vorhergehenden, ähnlichen Werkmodul.
* [http://www.uxmatters.com/mt/archives/2011/10/research-guidelines-you-wont-find-in-a-textbook.php 3 Regeln für Nutzerforschung: Sich Anfreunden, nicht zum Fragen beantworten da sein, nichts "verkaufen"]
* [http://www.experientia.com/blog/ Putting People First-Blog] (u.A. Forschung, Gender, Bildung etc. im HCD. Keine hurra-wir-sind-toll-Artikel, sondern interessante Inhalte.)

===Mobile Apps===
[[Mobile_Interaction_Design]] in unserem Wiki. Ich würde vorschlagen einfach [http://www.cs.uml.edu/~fredm/courses/91.308-fall05/palm/zenofpalm.pdf The Zen of Palm] zu lesen. Gute Zusammenfassung.

===Nützliches===
* Ein [http://en.wikipedia.org/wiki/Service_blueprint Service Blueprint] zum [http://www.flickr.com/photos/brandonschauer/3363169836/ Download]

* [http://m18.uni-weimar.de/mailman/listinfo/interaction Sign up] for our (inofficial) BU Interaction Design Mailinglist

===Meta===
...das Designen von Designlehre
* [http://www.newyorker.com/reporting/2012/01/30/120130fa_fact_lehrer?currentPage=all Brainstorming: Eine Kritik] (vgl. mit der pro-Brainstorm-Kultur von e.g. Design Thinking)
* Parallel Prototyping:Eine empirische Studie von [http://aaalab.stanford.edu/papers/Parallel_Prototyping_2010.pdf 2010] und einer von [http://www.sigchi.org/chi95/proceedings/shortppr/so_bdy.htm 1995], deren Ergebnisse sehr für paralelles Prototyping sprechen.
* Das Iteration sinnvoll ist, ist auch nix neues, aber auch hier eine [http://www.itu.dk/people/jeppeh/specialeartikler/The%20Efficacy%20of%20Prototyping%20Under%20Time%20Constraints.pdf Studie] dazu
* Gruppen, die sich nach bestehenden Freundschaften zusammenfinden, sind für designerische Gruppenarbeiten [http://www.stanford.edu/~roypea/RoyPDF%20folder/A154_CSCL09_Maldonado_Klemmer_Pea.pdf nicht gut geeignet]
* The Reflective Practitioner (D. Schön), ISBN 0465068782