Medien Wiki - User contributions [en]

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-14T20:15:01Z

Hans:

==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.

==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.

==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.

'''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. As shown in the prototypes before, we:
*in prototype a) added colors to button and bar
*in b) inform the user, if the message is insecure, through an exclamation mark and a slide-system
*in c) inform the user, if the message is insecure, through a pop-up
*in d) changed the words "OTR" to "secure messaging", because users don't know what OTR meant and added a pop-up to inform the user what to do after sending a message fails three times in a row
*in e) added the functions that secure messaging starts automatically.

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-14T19:56:16Z

Hans:

==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.

==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.

==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.

'''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.

===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.

==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) 

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. As shown in the prototypes before, we:
*in prototype a) added colors to button and bar
*in b) inform the user, if the message is unsecure, through an exclamation mark and a slide-system
*in c) inform the user, if the message is unsecure, through a pop-up
*in d) changed the words "OTR" to "secure messaging", because users don't know what OTR meant and added a pop-up to inform the user what to do after sending a message fails three times in a row
*in e) added the functions that secure messaging starts automatically.

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-14T19:09:47Z

Hans:

==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.

==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.

==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.

'''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 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.

==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) 

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. As shown in the prototypes before, we:
*in prototype a) added colors to button and bar
*in b) inform the user, if the message is unsecure, through an exclamation mark and a slide-system
*in c) inform the user, if the message is unsecure, through a pop-up
*in d) changed the words "OTR" to "secure messaging", because users don't know what OTR meant and added a pop-up to inform the user what to do after sending a message fails three times in a row
*in e) added the functions that secure messaging starts automatically.

IFD:Nutzerstudien WiSe1314/Sicherheit endpresentation (security)

2014-03-14T18:51:36Z

Hans:

==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.

==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]]

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.

==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.

==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) 

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. As shown in the prototypes before, we:
*in prototype a) added colors to button and bar
*in b) inform the user, if the message is unsecure, through an exclamation mark and a slide-system
*in c) inform the user, if the message is unsecure, through a pop-up
*in d) changed the words "OTR" to "secure messaging", because users don't know what OTR meant and added a pop-up to inform the user what to do after sending a message fails three times in a row
*in e) added the functions that secure messaging starts automatically.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T18:37:44Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

It is interesting to hear that people want to see the online status. We mostly hear feedback saying that online status is irrelevant in modern messaging apps (i.e. more like SMS). So perhaps we need to be thinking about how to provide SMS-like "send anytime" messaging while still including the idea of online status, rather than eliminating the idea of online/offline/etc entirely.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options.

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the interviews, the observations while usability tests and the comparison with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as intuitive as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

One thing to consider with the password is whether it is a good idea for the app to not remember the password. Certain high-risk users might want to avoid saving their password on the phone in case the phone is lost. But if the password is stored in a way that it cannot be recovered, and access to the app requires a password on a lock screen, then there is no longer a good reason to avoid saving the password. ChatSecure can now do both: it stores everything encrypted, and it has a lock screen for the whole app. In this case, I think it makes sense to remove the option for saving the account password, and just make it always save it. Then perhaps ChatSecure can forget the password if the user forces a logout. I believe this is how the Facebook app handles the password: it automatically remembers it until the user manually requests to logout.

==Prototypes==

I would like to see more quick and dirty sketches of ideas. Like quick doodles on paper of all sorts of radical ideas. What you have here is a good optimization of the existing processes. But a radical reshaping of the process could have a much much bigger payoff in terms of improving usability.

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

This definitely makes a lot of sense, it should be easy to enter the password if it is not saved. And ChatSecure should prompt the user when it wants the password, rather than making the user go find where to enter the password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
Our next steps for our prototypes were to thought about a clear arrangement of the contact online/contact offline menu.
In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion.
Now it's clear what your own status is and what's the status of your contacts.
 We also added a yellow star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we considered that it is very important that the user could follow all of his actions and understands the results.
We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge. (images 5,6,7)

The idea of allowing people to find out more info on the account setup screen is quite valuable. One thing to also consider is how to use information that the program can automatically detect. For example, Tor/Orbot is a separate app, and ChatSecure can detect if it is installed or not. So ChatSecure could change the account setup screen based on that.

[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]

 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs". (images 11, 13,14)
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)

It is interesting to see that you adding online presense to the interface. It used to be part of ChatSecure, back when it was called Gibberbot, but we actually removed the representation of online status to simplify things. It seems to be very much an open question of whether having online/offline presence info in messaging apps is a useful thing. Some people very much demand it, while for many it is just confusing. From what I've seen of new messaging apps, the trend in mobile apps is to remove it, but that could just be a trend that changes in a year. So perhaps there is a middle ground somewhere, a way to include the information without having be dominant or confusing.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account. (image 5)
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react. (images 6,7 and 10)
 
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our results==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

FINAL DESIGN RESULTS/UPDATES FOR CHATSECURE:

This is a much clearer representation of the password prompt than what currently exists.

1. additional password entering button

[[File:nutzerstudien_version4_1.JPG|200px]]

2. advice if password is wrong - error message

[[File:nutzerstudien_version4_2.JPG|200px]]

3. generally error messages in case of no connection/wrong enters

Android is pushing away from Ok message boxes, and instead putting as much of the info inline into the interface as possible. The on/off switch is one example of that. I think these errors could also be represented inline too.

[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]

4. new contact order with several colours - two different design ideas

I think image numbers 13 (middle) and 14 (right) represent the online info the best. In 11 (left), it is too dominant and could be potentially confusing because people might think a contact went missing since its not on the Online list, and the offline list is far off the bottom of the screen.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

5. yellow stars for most important contacts

I like this idea.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]

6. info buttons to improve the user understanding

Definitely needed. I would like to see a sketch of what happens when the user clicks on an info button. Do you know of any existing Android metaphors you can build on?

[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

Thanks for testing with the app despite the problems! We have recently had a big push to implement new features in ChatSecure, so there are still bugs to work out. Our next big work focus will be improving the UI and the stability. There is also a iOS version, but without quite as many as the security features: https://chatsecure.org

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufficient background knowledge for our process of work during the course. So we obtained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T18:36:13Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

It is interesting to hear that people want to see the online status. We mostly hear feedback saying that online status is irrelevant in modern messaging apps (i.e. more like SMS). So perhaps we need to be thinking about how to provide SMS-like "send anytime" messaging while still including the idea of online status, rather than eliminating the idea of online/offline/etc entirely.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options.

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the interviews, the observations while usability tests and the comparison with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as intuitive as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

One thing to consider with the password is whether it is a good idea for the app to not remember the password. Certain high-risk users might want to avoid saving their password on the phone in case the phone is lost. But if the password is stored in a way that it cannot be recovered, and access to the app requires a password on a lock screen, then there is no longer a good reason to avoid saving the password. ChatSecure can now do both: it stores everything encrypted, and it has a lock screen for the whole app. In this case, I think it makes sense to remove the option for saving the account password, and just make it always save it. Then perhaps ChatSecure can forget the password if the user forces a logout. I believe this is how the Facebook app handles the password: it automatically remembers it until the user manually requests to logout.

==Prototypes==

I would like to see more quick and dirty sketches of ideas. Like quick doodles on paper of all sorts of radical ideas. What you have here is a good optimization of the existing processes. But a radical reshaping of the process could have a much much bigger payoff in terms of improving usability.

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

This definitely makes a lot of sense, it should be easy to enter the password if it is not saved. And ChatSecure should prompt the user when it wants the password, rather than making the user go find where to enter the password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
Our next steps for our prototypes were to thought about a clear arrangement of the contact online/contact offline menu.
In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion.
Now it's clear what your own status is and what's the status of your contacts.
 We also added a yellow star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we considered that it is very important that the user could follow all of his actions and understands the results.
We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge. (images 5,6,7)

The idea of allowing people to find out more info on the account setup screen is quite valuable. One thing to also consider is how to use information that the program can automatically detect. For example, Tor/Orbot is a separate app, and ChatSecure can detect if it is installed or not. So ChatSecure could change the account setup screen based on that.

[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]

 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs". (images 11, 13,14)
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)

It is interesting to see that you adding online presense to the interface. It used to be part of ChatSecure, back when it was called Gibberbot, but we actually removed the representation of online status to simplify things. It seems to be very much an open question of whether having online/offline presence info in messaging apps is a useful thing. Some people very much demand it, while for many it is just confusing. From what I've seen of new messaging apps, the trend in mobile apps is to remove it, but that could just be a trend that changes in a year. So perhaps there is a middle ground somewhere, a way to include the information without having be dominant or confusing.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account. (image 5)
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react. (images 6,7 and 10)
 
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our results==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

FINAL DESIGN RESULTS/UPDATES FOR CHATSECURE:
This is a much clearer representation of the password prompt than what currently exists.

1. additional password entering button

[[File:nutzerstudien_version4_1.JPG|200px]]

2. advice if password is wrong - error message

[[File:nutzerstudien_version4_2.JPG|200px]]

3. generally error messages in case of no connection/wrong enters

Android is pushing away from Ok message boxes, and instead putting as much of the info inline into the interface as possible. The on/off switch is one example of that. I think these errors could also be represented inline too.

[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]

4. new contact order with several colours - two different design ideas

I think image numbers 13 (middle) and 14 (right) represent the online info the best. In 11 (left), it is too dominant and could be potentially confusing because people might think a contact went missing since its not on the Online list, and the offline list is far off the bottom of the screen.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

5. yellow stars for most important contacts

I like this idea.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]

6. info buttons to improve the user understanding

Definitely needed. I would like to see a sketch of what happens when the user clicks on an info button. Do you know of any existing Android metaphors you can build on?

[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

Thanks for testing with the app despite the problems! We have recently had a big push to implement new features in ChatSecure, so there are still bugs to work out. Our next big work focus will be improving the UI and the stability. There is also a iOS version, but without quite as many as the security features: https://chatsecure.org

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufficient background knowledge for our process of work during the course. So we obtained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T18:26:22Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

It is interesting to hear that people want to see the online status. We mostly hear feedback saying that online status is irrelevant in modern messaging apps (i.e. more like SMS). So perhaps we need to be thinking about how to provide SMS-like "send anytime" messaging while still including the idea of online status, rather than eliminating the idea of online/offline/etc entirely.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options.

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the interviews, the observations while usability tests and the comparison with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as intuitive as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

One thing to consider with the password is whether it is a good idea for the app to not remember the password. Certain high-risk users might want to avoid saving their password on the phone in case the phone is lost. But if the password is stored in a way that it cannot be recovered, and access to the app requires a password on a lock screen, then there is no longer a good reason to avoid saving the password. ChatSecure can now do both: it stores everything encrypted, and it has a lock screen for the whole app. In this case, I think it makes sense to remove the option for saving the account password, and just make it always save it. Then perhaps ChatSecure can forget the password if the user forces a logout. I believe this is how the Facebook app handles the password: it automatically remembers it until the user manually requests to logout.

==Prototypes==

I would like to see more quick and dirty sketches of ideas. Like quick doodles on paper of all sorts of radical ideas. What you have here is a good optimization of the existing processes. But a radical reshaping of the process could have a much much bigger payoff in terms of improving usability.

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

This definitely makes a lot of sense, it should be easy to enter the password if it is not saved. And ChatSecure should prompt the user when it wants the password, rather than making the user go find where to enter the password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
Our next steps for our prototypes were to thought about a clear arrangement of the contact online/contact offline menu.
In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion.
Now it's clear what your own status is and what's the status of your contacts.
 We also added a yellow star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we considered that it is very important that the user could follow all of his actions and understands the results.
We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge. (images 5,6,7)

The idea of allowing people to find out more info on the account setup screen is quite valuable. One thing to also consider is how to use information that the program can automatically detect. For example, Tor/Orbot is a separate app, and ChatSecure can detect if it is installed or not. So ChatSecure could change the account setup screen based on that.

[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]

 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs". (images 11, 13,14)
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)

It is interesting to see that you adding online presense to the interface. It used to be part of ChatSecure, back when it was called Gibberbot, but we actually removed the representation of online status to simplify things. It seems to be very much an open question of whether having online/offline presence info in messaging apps is a useful thing. Some people very much demand it, while for many it is just confusing. From what I've seen of new messaging apps, the trend in mobile apps is to remove it, but that could just be a trend that changes in a year. So perhaps there is a middle ground somewhere, a way to include the information without having be dominant or confusing.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account. (image 5)
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react. (images 6,7 and 10)
 
This is a much clearer representation of the password prompt than what currently exists.
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our results==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

FINAL DESIGN RESULTS/UPDATES FOR CHATSECURE:

1. additional password entering button

[[File:nutzerstudien_version4_1.JPG|200px]]

2. advice if password is wrong - error message

[[File:nutzerstudien_version4_2.JPG|200px]]

3. generally error messages in case of no connection/wrong enters

Android is pushing away from Ok message boxes, and instead putting as much of the info inline into the interface as possible. The on/off switch is one example of that. I think these errors could also be represented inline too.

[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]

4. new contact order with several colours - two different design ideas

I think image numbers 13 (middle) and 14 (right) represent the online info the best. In 11 (left), it is too dominant and could be potentially confusing because people might think a contact went missing since its not on the Online list, and the offline list is far off the bottom of the screen.

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

5. yellow stars for most important contacts

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]

6. info buttons to improve the user understanding

[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufficient background knowledge for our process of work during the course. So we optained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T15:43:46Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

It is interesting to hear that people want to see the online status. We mostly hear feedback saying that online status is irrelevant in modern messaging apps (i.e. more like SMS). So perhaps we need to be thinking about how to provide SMS-like "send anytime" messaging while still including the idea of online status, rather than eliminating the idea of online/offline/etc entirely.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options.

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the interviews, the observations while usability tests and the comparison with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as intuitive as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

One thing to consider with the password is whether it is a good idea for the app to not remember the password. Certain high-risk users might want to avoid saving their password on the phone in case the phone is lost. But if the password is stored in a way that it cannot be recovered, and access to the app requires a password on a lock screen, then there is no longer a good reason to avoid saving the password. ChatSecure can now do both: it stores everything encrypted, and it has a lock screen for the whole app. In this case, I think it makes sense to remove the option for saving the account password, and just make it always save it. Then perhaps ChatSecure can forget the password if the user forces a logout. I believe this is how the Facebook app handles the password: it automatically remembers it until the user manually requests to logout.

==Prototypes==

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

This definitely makes a lot of sense, it should be easy to enter the password if it is not saved. And ChatSecure should prompt the user when it wants the password, rather than making the user go find where to enter the password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
Our next steps for our prototypes were to thought about a clear arrangement of the contact online/contact offline menu.
In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion.
Now it's clear what your own status is and what's the status of your contacts.
 We also added a yellow star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we considered that it is very important that the user could follow all of his actions and understands the results.
We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge. (images 5,6,7)

[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]

 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs". (images 11, 13,14)
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account. (image 5)
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react. (images 6,7 and 10)
 
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our results==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

FINAL DESIGN RESULTS/UPDATES FOR CHATSECURE:

1. additional password entering button

[[File:nutzerstudien_version4_1.JPG|200px]]

2. advice if password is wrong - error message

[[File:nutzerstudien_version4_2.JPG|200px]]

3. generelly error messages in case of no connection/wrong enters

[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]

4. new contact order with several colours - two different design ideas

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

5. yellow stars for most important contacts

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]

6. info buttons to improve the user understanding

[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufficient background knowledge for our process of work during the course. So we optained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T15:40:34Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options.

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the interviews, the observations while usability tests and the comparison with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as intuitive as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

One thing to consider with the password is whether it is a good idea for the app to not remember the password. Certain high-risk users might want to avoid saving their password on the phone in case the phone is lost. But if the password is stored in a way that it cannot be recovered, and access to the app requires a password on a lock screen, then there is no longer a good reason to avoid saving the password. ChatSecure can now do both: it stores everything encrypted, and it has a lock screen for the whole app. In this case, I think it makes sense to remove the option for saving the account password, and just make it always save it. Then perhaps ChatSecure can forget the password if the user forces a logout. I believe this is how the Facebook app handles the password: it automatically remembers it until the user manually requests to logout.

==Prototypes==

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

This definitely makes a lot of sense, it should be easy to enter the password if it is not saved. And ChatSecure should prompt the user when it wants the password, rather than making the user go find where to enter the password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
Our next steps for our prototypes were to thought about a clear arrangement of the contact online/contact offline menu.
In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion.
Now it's clear what your own status is and what's the status of your contacts.
 We also added a yellow star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we considered that it is very important that the user could follow all of his actions and understands the results.
We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge. (images 5,6,7)

[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]

 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs". (images 11, 13,14)
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account. (image 5)
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react. (images 6,7 and 10)
 
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our results==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

FINAL DESIGN RESULTS/UPDATES FOR CHATSECURE:

1. additional password entering button

[[File:nutzerstudien_version4_1.JPG|200px]]

2. advice if password is wrong - error message

[[File:nutzerstudien_version4_2.JPG|200px]]

3. generelly error messages in case of no connection/wrong enters

[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]

4. new contact order with several colours - two different design ideas

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

5. yellow stars for most important contacts

[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]

6. info buttons to improve the user understanding

[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufficient background knowledge for our process of work during the course. So we optained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T15:32:11Z

Hans:

==Course Aims==

During the course "Nutzerstudien" we focused on the smartphone app "ChatSecure" by interrelating the security of chat apps.
We wanted to find out about the importance of security in chat apps for students at our age. Further we were interested in general expectations they have from chat apps and what their problems/wishes are.
For that purpose we tested the app "ChatSecure" with our target group, accomplished usability tests and so developed a varied design to improve the process of creating an account and of signing in.

==Progress of work==

'''1. Interviews and target group'''
For that reason we started to interview a few people from our social environment as our target group. So we focused on students at the age of 20 - 30. We reached this test persons personally so we met them to conduct the interviews directly.

'''2. Analyse and Assessment'''
After that we analysed the results by summing up, comparing and strucuring them.

'''3. Prototypes and scenarios'''
Then we began to create prototypes. These prototypes also passed through usability tests to further improve the design.
For that prototypes we constructed scenarios which had to be accomplished by the test users.

'''4. Improving Design by Iteration'''
We further improved our design by iteration (five steps) to get our final design.

Ich denke, dass ''Progress of work'' und ''Course aims'' eine gute und einfache Einleitung sind. 

Sounds like a straightforward, useful, and doable plan.

=='''Data gathering: Interviews'''==

table of interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing those people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students.

Form of accessibility:

From the start we were agreed that we want to reach our target group personally by meeting them at the university (fellow students/friends) or at home (homemates). We wanted to talk to them privately to get detailed information and to observe their chat behaviour.

In person interviews can give you a lot of focused time and information, and can be quite valuable. Did you consider any other less focused methods of gathering information? Like a survey via facebook, etc. Having a more neutral method of getting information from people might give you things that would not be mentioned in an interview.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?
''Kleine Anmerkung für zukünftige Projekte: Fragen "what are the requirements…" und "how often…" sind schwierig gut zu beantworten und ihr erfahrt dadurch vermutlich wenig über die Gründe für das Nutzerverhalten. "Advantages… Disadvantages" und "which measures" sind gut. Fragt nicht nach generellem, sondern nach "wie machst du…" "was machst du…", "warum hilft… wenn du…" – Dinge, die mit Aktionen zu tun haben, und, noch besser, beobachtet werden können.

This is a good range of questions that sounds likely to bring out some of the harder issues of the interface, like finding the threshold where people will give up some security because the interface is too difficult to use. Like the comment above, some of the questions might be too vague without follow-up information. Perhaps there needs to be a couple more targeted questions about examples of when the user gave up on security because of usability issues.

==Observation==

After that we did a usability test with ChatSecure to find out how other users deal with the app.

We wanted to find out if the register and login process is intuitive for the user or not. So we got to know about user's handling with apps and their expectations. We hoped to get suggestions and ideas for a better log in process based on the user's behavior.)

* What observations during the interviews did we make?

The tester was asked to say what she/he was thinking and doing while testing the prototype, which problems she/he had and how they could be solved.
With that method and the video it was possible to find and analyse the issues the tester had.

[https://www.youtube.com/watch?v=zdeTEaDdvy4&feature=youtu.be Usability test]
 

Nice video! Good format. Its definitely very useful for watching how a user navigates the app. The user seemed to feel comfortable enough to react naturally during the process, which is quite important. It would be useful to have a higher resolution video to see the details of what is on the screen. It would be nice to see more of these from other users.

* What is noticeable during that usability test?

During the test we found out...
* ...how the proband approached to the test,
* ...how long it took her/him to understand the system and structure of the app,
* ...which problems appeared
* ...and where the problems appeared.

Results:
We evaluated the usability tests and made a heuristic analysis for creating a new account and the login-progress.
Der Abschnitt zu Observation zeigt eine gute Strukturierung, da bin ich sehr gespannt auf die Ergebnisse dieser Tests. leider steht unter "What is noticeable during that usability test?" nur welcher Art die Ergebnisse sind ("which problems appeared") und nicht was die Ergebnisse selber sind ("Problems: The ''foo'' irritates users, because it looks like the ''bar'' they already know from ''qux'') Auch die Heuristische Analyse, die ihr gemacht habt, hat eine kurze Hinleitung und deutliche Erwähnung verdient!

[http://www.uni-weimar.de/medien/wiki/IFD:Nutzerstudien_WiSe1314/HeuristicAnalysisAnmeldung heuristic analysis]

The heuristic analysis provides a thorough overview of the issues discovered in the user testing. It would be interesting to see links to specific quotes and actions of users in the testing in relation to the points in the analysis. Then if I want to understand a specific problem better, I find the quotes, or reference in the video (you can link to specific times in a youtube video, for example).

=='''Data Analysis & Main Results'''==

To analyze the data we got, we wrote down the interviews and focused on concisely statements that were important for our task. So we picked out some theses independent from each other and created a kind of digital pin board. There we collected the most important information and tried to arrange the notes into groups. So we got a good summary of our interview results and a much better basis for the designs and improvements.

[[File:Nutzerstudien-Authentifizierung.jpg| 600 px]]

* App Requirements
** It is of prime importance that the app has to be easily accessible. So it has to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necessary.

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses. That means that the app should be save. Our probands talked about some safety gaps they experienced on social platforms and other chat providers they used (e.g. private messages that were published on the public profile, spam mails, ...).
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

Some sections here are a good collection of overarching ideas for making good software. Other sections here are a couple of specific points, like wanting to see when a user is online. Each section should have a couple overarching ideas, with some important, specific points. For example, what specific things are required to provide an "up-to-date and flexible" messaging experience. What general rules did you learn about security?

==Research and problem solutions==

'''What specific problem we want to solve'''

We want to solve some problems with the login-process we had as we first used the app and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

'''Plans – how we want to solve the problem(s)'''

--> Using the method: other application's test:
Ich freue mich, das ihr hier zusätzliche Methoden (Konkurrenzanalyse) angewandt habt. Das zeigt, dass ihr euch eigene Gedanken macht und eigene Lösungen sucht!

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

WhatsApp is a good example of sacrificing security and privacy to make it easy to use. WhatsApp definitely provides a simple login, but no app has been able to simplify the login that much without creating serious security and privacy concerns. For example, the WhatsApp login and password are generated based on data from the phone which can leak out. The user cannot even change the password once its leaked. Anyone with that username/password can then read and write messages using that account from anywhere on the internet: http://blog.philippheckel.com/2013/07/05/how-to-sniff-the-whatsapp-password-from-your-android-phone-or-iphone/ 

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Facebook is a much better example to work with since it does require a password, and it is a password that the user sets and can change.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone).

One thing that both WhatsApp and Facebook have in common is that they both make the app and they also run the service that the app uses. This is the difficult part of ChatSecure: it is just the app, someone else is providing the service. The advantage is that anyone can provide the service (companies, student groups, universities, individuals, etc.) This means the user can choose a service provider that they trust the most, but that makes the login procedure a lot more complicated. One idea that works well in this kind of situation is having "sensible defaults". That means that the app will choose a specific service by default, and the user can just choose a username and password. Then if the user wants more choice, then can expand a hidden section that contains all of the options. 

Another approach is to ask the user a question before setting up the account. Something like "how concerned are you about the security and privacy of this account?" Then based on the answer to that question, ChatSecure would choose the defaults for the user (things like which service, whether to use Tor or not, etc. Then the user could optionally change those defaults.

==First design considerations and ideas==

After the intervies, the observations while usability tests and the comparision with other apps, we could draw the first design conclusion and ideas:

1. We want the process of creating an account and signing in as inutitve as possible (comparable with WhatsApp and Facebook Messenger)
2. We want the app as safe as possible (safer than WhatsApp and Facebook Messenger)

first changings/development ideas:
* additional button for entering a password (if it isn't saved)
* reduce redundant buttons
* clarify inconclusive and obscure functions/buttons

==Prototypes==

'''Version 1'''
 
Our first prototype for the login process contains the additional password entering button if it isn't saved. (at the beginning you can choose if you want to save the password for further use or not)
It occurs when you want to switch from offline to online as an extra field.

[[File:Prototyp Anmeldeprozess.jpg|600px]]
 
[[File:nutzerstudien_version1_1.JPG|200px]]
[[File:nutzerstudien_version1_2.JPG|200px]]
 
 
'''Version 2'''

 
In the next step for our prototype we thought about a clear arrangement of the contact online/contact offline menu. In our usability tests we found out, that the design is very confusing and the tester couldn't really find out wich contact was online and who not.
 Moreover we separated the symbol of the own status and the symbol of the contact's status, so there's no more confusion. Now it's clear what your own status is and what's the status of your contacts.
 We also added a star on the right side next to the contact's name. That's optional for every contact and a way to fix your favourite contacts on top of the list.

 
[[File:nutzerstudien_version2_1.JPG|200px]]
[[File:nutzerstudien_version2_2.JPG|200px]]
[[File:nutzerstudien_version2_3.JPG|200px]]
[[File:nutzerstudien_version2_4.JPG|200px]]
[[File:nutzerstudien_version2_5.JPG|200px]]
 
 
'''Version 3'''
 
For the next iteration we focused on improving the progress of creating an account.
At this juncture we found it very importent that the user could follow all of his actions and understands the results. We also wanted a clear and visible design to show the system status.
 We added info buttons near interface-Elements that were misunderstood in our tests. So the user can get fast help without serching for it very long. We think this is a solution helping new users and not annoying user with a bigger knowledge.
 Furthermore we improved the design for the list of contacts once more and clearly seperated "online" and "offline" from each other in order to prevent mistakes and confusion. This two lists are know reachable with a kind of "tabs".
 
Bezug zu Bildern herstellen (wie in der Mail angemerkt)
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version3_5.JPG|200px]]
[[File:nutzerstudien_version3_6.JPG|200px]]
[[File:nutzerstudien_version3_7.JPG|200px]]
[[File:nutzerstudien_version3_8.JPG|200px]]
[[File:nutzerstudien_version3_9.JPG|200px]]
[[File:nutzerstudien_version3_10.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]
 
 
'''Version 4 - final version'''
 
In the last and final version we used an old idea from the first prototype and grided the password-request in the progess of creating an account.
 Moreover we added all error messages, that appeared in the tests to give feedback to the user in every of this situations and to let her/him decide by her-/himself how to react.
 
 
[[File:nutzerstudien_version3_1.JPG|200px]]
[[File:nutzerstudien_version3_2.JPG|200px]]
[[File:nutzerstudien_version3_3.JPG|200px]]
[[File:nutzerstudien_version3_4.JPG|200px]]
[[File:nutzerstudien_version4_1.JPG|200px]]
[[File:nutzerstudien_version4_2.JPG|200px]]
[[File:nutzerstudien_version4_3.JPG|200px]]
[[File:nutzerstudien_version3_11.JPG|200px]]
[[File:nutzerstudien_version3_12.JPG|200px]]
[[File:nutzerstudien_version4_4.JPG|200px]]
[[File:nutzerstudien_version3_13.JPG|200px]]
[[File:nutzerstudien_version3_14.JPG|200px]]

==Our conclusions==
Überblick am Schluss: Sehr gut. Wie in der Mail angemerkt, wäre hier ein guter Platz für eine Zusammenfassung der Änderungen, sozusagen ein Design-Fazit.

Problems we had:

The first user experiences by ourselves with the app "ChatSecure" passed dragging because of difficulties with the process of creating an account. We lost too much time by trying to test the app. It was a huge problem that the app didn't worked with IOS.

What did work well:

Our teamwork worked all time. On the one hand inside the course but especially inside our working group because we regulary organised meetings and were always in contact via messaging about the actual state of affairs.

Furthermore we were well prepared before interviewing so that we could implement that while talking to our target group.

Generally we got sufhficient background knowledge for our process of work during the course. So we optained step by step our final design.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T15:12:02Z

Hans:

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T04:19:22Z

Hans:

IFD:Nutzerstudien WiSe1314/HeuristicAnalysisAnmeldung

2014-03-14T04:03:22Z

Hans:

== Visibility of system status ==
* New Account

** While creating an account the app keeps the user informed about what is to do. There are several input fields which have to be filled. If all fields are filled up, the user gets into the main page of ChatSecure where he/she sees a box with the account.
** Unfortunately there is no special information that the creation was successful.

** 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. (picture 2)

[[File:new_account.jpg | 200px]]
[[File:Nutzerstudien_anmedlung_create_jabberanbieter.png | 200px]]

* Log In
** On the start page the user finds his created account and the information if it is on or off. So the app always shows if the user is signed in or not.

** Usually the user pushes the button of the account to start to chat. Then you get in your inside page with your friendlist. But you can’t go online without entering your password (if you didn’t save the password) Than you get this information:
[[File:problem_passwordentering.jpg | 200px]]
** What misses at the beginning is the request to enter the password if it isn’t saved.
** There is no visible button to enter the password on the main page. When the user found out that it is the tool button where he/she can enter the password, then the app shows “application accomplished” and then the status “online” at the main page.
** When the user is finally online, he/she gets into the chat page and there is a button with “online” so that the user knows his/her status.

[[File:login_visability.jpg | 800px]]

* Settings

** There are visible boxes to fill with ticks so that the user always knows which option he/she uses or not.
[[File:settings.jpg | 200px]]

*Create new account:
**The created account is visible and thus it's sure that the account was successfully created.
**But after I created a new account and agreed to the certificate the system crashed.

[[File:report_chat_secure.JPG | 200px]]

[[File:syytem_crash_chat_secure.jpeg | 200px]]

*Login:
**When the system is about to login a little loading bar could be usefull to show the status of the login-progress. But thus the login-progress is quite fast, the missing loading bar is no problem.

== Match between system and the real world==

* New Account

** The process of creating an account only consists of simple words that the user has to fill in (user name, password). But there are two fields/ buttons where I personally didn’t hear yet. Firstly I didn’t know what to choose as a domain and secondly I don’t know what “Verbinden über Tor (Benötigt Orbot app) means. Maybe that should be explained more to the user.

[[File:new_account_complication.jpg | 200px]]

* Log In

** The words “on” and “off” are clear to the user, it is also simple to find out that the user have to shove the button to change the status.
As already shown it isn’t intuitive for the user to enter the password with the help of the tool button at the right side.

* Settings

** All options are clear or they are explained but it would be better to keep one language and not to have an English heading and a German explanation.

[[File:settings_language.jpg | 200px]]

Some terms where difficult for me to understand.
*Create new account:
**I don't know what "Tor" is. Maybe there could be some help and more information in the app.

[[File:tor_chat_secure.JPG | 200px]]

== User control and freedom==

* There are two possibilities to close the app but if you use the first, the program is closed and you get the information “ChatSecure stopped”. That is an error because it shows that the app didn’t react correctly. (no screenshot possible)

*I need the app-extern "back" button to get out of the settings. Everywhere else in the app there are functions that allow me to switch back or find an exit. But in my opinion it's not a big problem. Just a litte flaw of the app.

== Consistency and standards ==

* New Account

** The app uses standard words that other apps uses too, like user name, password etc.

* Log In

** Maybe first the user doesn’t notice the difference between “on”/”off” and “online”/”offline”.

** Unlike others, who have a slide bar to log in, I have to click on a checkmark. Since I have never logged in that way I needed some time to figure out that this is the log-in-button.

* Settings

** The settings largely follow platform conventions, like e.g. vibrate, audio.

** 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]]

All in all the app is easy to understand. The "moves" you have to make to use the app are quite familiar and like on every other smartphone.
There are just two things, that seemed to be a problem for me.
*Settings:
**I don't understand what the "Fingerpringt"-button is supposed to be used to.
**Also the "Panic"-button could confuse the user.

[[File:settings_chat_secure.JPG | 200px]]

It also would be more helpful to use one language (German or English) consequent in the whole app, than to mix up both languages. It also would help the app to appear more serious.

[[File:language_chat_secure.JPG | 200px]]

The last thing I recognized, is that I have to encrypt my chat to send a file. But if I'm allowed to chat without encryption, why can't I send a picture without encrypt my chat?

[[File:bilder_senden_chat_secure.JPG | 200px]]

== Error prevention ==

* I didn’t notice any error prevention while creating an account, signing in or at the settings.

There were no errors in the app. Just the system crash when I created my account (see "visibly of system status").
But in the whole app I can't find any help- or support-page. Maybe it would be usefull to create such a page to give quick help to the user.

== Recognition rather than recall==

* New Account

** At the main page there is a plus button to create a new account or to use an existing one. The user has to remember that but it is quite intuitive. For other actions the user doesn’t have to remember something from another part.

* Log In

** The user has to remember that he/she has to enter the password at the tool button at the right side. There is no instruction for it.

[[File:login_complication.jpg | 200px]]

* Settings

** There are two possible options to find the settings. Either the user pushes the left button at the smartphone (e.g. Samsung Galaxy S2) or he/she goes throw the lock and chooses “settings”. The second one is more intuitive for the user.
For the first possibility there is no advice that the settings are at that place but it isn’t necessary because there is the second one.

== Flexibility and efficiency of use==

* couldn’t find out differences for novice users and experts.

I think that the offered providers don't sound very confidental to uninformed users because of the unfamiliar names. There should be some more information about the providers (e.g. "xmmp.jp" or "neko.im").

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

For the "first use"-user the account settings are a little bit hard to understand. But I think this results out of missing knowledge in the domains internet and programming. For the user, who is a little more comfortable with this topics it should be no problem.

In all other aspects I don't see any differences for beginners and advanced users.
== Aesthetic and minimalist design==

* New Account

** There are no irrelevant buttons and a clear, simple design.

* Log In

** The design is simple but there are redundant steps to log in (first shove at “on”, than enter the password, than push on the account etc.) It would be enough to have one action to sign in so that it is more comfortable.

* Settings

** The design of the settings are well listed and clear. There is only one button for each option.

The design is quite modern and organized.

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

* There was one error message that occurs after closing the program normally. It asked if you want to send the problem to the developers.

* 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]]

The only bug/error that happend to me was the system crash, when I created my account.

== Help and documentation ==

It would be very useful to have an short help- or support-page to give quick help to the user.

* couldn’t find a option for help or documentation so it would be necessary to add it.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T03:26:28Z

Hans:

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung endpresentation

2014-03-14T03:11:44Z

Hans:

IFD:Nutzerstudien WiSe1314/Sicherheit (security)

2013-12-18T20:56:58Z

Hans:

==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.


<div style="color:brown">Developing a clear, concise scheme for representing the states of messages in ChatSecure is a very valuable problem to solve. If the user does not understand when things are private or not, they could easily leak private information. Keep in mind all manner of design treatments: font, color, iconography, etc. I think that finding well known metaphors could likely produce good results here, but a very simple abstract scheme could also work. One of my favorite ideas here is relying on the default look. ChatSecure should provide private/secure messaging by default. If the messages are not private/secure, then that is a warning/error condition and should be represented as such.</div>--[[User:Hans|Hans]] 21:40, 18 December 2013 (CET)

== 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.

<div style="color:brown">I'd like to see more discussion of your approach here. How did you choose your people? What criteria did you use to develop your questions?</div>--[[User:Hans|Hans]] 21:43, 18 December 2013 (CET)

==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 <div style="color:brown">did the users know that the apps they use were unsafe?</div>--[[User:Hans|Hans]] 21:44, 18 December 2013 (CET)
* 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

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 parties 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 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
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.

<div style="color:brown">You bring up a lot of valuable points here, and the bullet points provide a quick summary, but I'd love to hear more about all of the topics. In particular, I think the core issue is why people don't find more secure/private alternatives to the apps that they use. Is it social (everyone I know uses Xapp)? Is it usability (private apps are hard to use)? Or something else entirely?</div>--[[User:Hans|Hans]] 21:50, 18 December 2013 (CET)

==What specific problem we want to solve==

The interface should communicate security to the user. Therefore we want to improve the interface of ChatSecure in a way, that everyone is able 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.

[[image:IFD-NuSt security-mockup.jpg|1000px]]

<div style="color:brown">Its good to see the mockups, this gets the process rolling. About the prompt for sending messages insecurely, this would work well for people in very sensitive situations, but I think most users would get annoyed once they've seen a pop-up like this more than 5 or 10 times. I think that it is possible to achieve the same results security-wise with less annoyance on the user by integrating this warning more. For example, the Send button should change color like you have already but maybe instead of the yes/no/later prompt, the user would have to press the send button twice, and it would change color on each press. For more security, there could be an enforced delay on the second press, so they would have to wait a second or two before clicking it the second time. Or mybe it would be enough if the whole interface was shouting out that the message would be sent insecurely, something like every aspect of the UI turning red, and getting a different font.</div>--[[User:Hans|Hans]] 21:56, 18 December 2013 (CET)



==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-18T20:50:11Z

Hans:

==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.


<div style="color:brown">Developing a clear, concise scheme for representing the states of messages in ChatSecure is a very valuable problem to solve. If the user does not understand when things are private or not, they could easily leak private information. Keep in mind all manner of design treatments: font, color, iconography, etc. I think that finding well known metaphors could likely produce good results here, but a very simple abstract scheme could also work. One of my favorite ideas here is relying on the default look. ChatSecure should provide private/secure messaging by default. If the messages are not private/secure, then that is a warning/error condition and should be represented as such.</div>--[[User:Hans|Hans]] 21:40, 18 December 2013 (CET)

== 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.

<div style="color:brown">I'd like to see more discussion of your approach here. How did you choose your people? What criteria did you use to develop your questions?</div>--[[User:Hans|Hans]] 21:43, 18 December 2013 (CET)

==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 <div style="color:brown">did the users know that the apps they use were unsafe?</div>--[[User:Hans|Hans]] 21:44, 18 December 2013 (CET)
* 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

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 parties 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 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
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.

<div style="color:brown">You bring up a lot of valuable points here, and the bullet points provide a quick summary, but I'd love to hear more about all of the topics. In particular, I think the core issue is why people don't find more secure/private alternatives to the apps that they use. Is it social (everyone I know uses Xapp)? Is it usability (private apps are hard to use)?</div>--[[User:Hans|Hans]] 21:50, 18 December 2013 (CET)

==What specific 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.

[[image:IFD-NuSt security-mockup.jpg|1000px]]



==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-18T20:44:24Z

Hans:

==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.


<div style="color:brown">Developing a clear, concise scheme for representing the states of messages in ChatSecure is a very valuable problem to solve. If the user does not understand when things are private or not, they could easily leak private information. Keep in mind all manner of design treatments: font, color, iconography, etc. I think that finding well known metaphors could likely produce good results here, but a very simple abstract scheme could also work. One of my favorite ideas here is relying on the default look. ChatSecure should provide private/secure messaging by default. If the messages are not private/secure, then that is a warning/error condition and should be represented as such.</div>--[[User:Hans|Hans]] 21:40, 18 December 2013 (CET)

== 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.

<div style="color:brown">I'd like to see more discussion of your approach here. How did you choose your people? What criteria did you use to develop your questions?</div>--[[User:Hans|Hans]] 21:43, 18 December 2013 (CET)

==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 <div style="color:brown">did the users know that the apps were unsafe?</div>--[[User:Hans|Hans]] 21:44, 18 December 2013 (CET)
* 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.

[[image:IFD-NuSt security-mockup.jpg|1000px]]



==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-18T20:43:39Z

Hans: another comment

==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.


<div style="color:brown">Developing a clear, concise scheme for representing the states of messages in ChatSecure is a very valuable problem to solve. If the user does not understand when things are private or not, they could easily leak private information. Keep in mind all manner of design treatments: font, color, iconography, etc. I think that finding well known metaphors could likely produce good results here, but a very simple abstract scheme could also work. One of my favorite ideas here is relying on the default look. ChatSecure should provide private/secure messaging by default. If the messages are not private/secure, then that is a warning/error condition and should be represented as such.</div>--[[User:Hans|Hans]] 21:40, 18 December 2013 (CET)

== 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.

<div style="color:brown">I'd like to see more discussion of your approach here. How did you choose your people? What criteria did you use to develop your questions?</div>--[[User:Hans|Hans]] 21:43, 18 December 2013 (CET)

==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.

[[image:IFD-NuSt security-mockup.jpg|1000px]]



==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==

User:Hans

2013-12-18T20:41:17Z

Hans:

Hi! This is me:

* http://at.or.at/hans
* https://guardianproject.info

User:Hans

2013-12-18T20:41:06Z

Hans: Created page with "Hi! This is me: http://at.or.at/hans https://guardianproject.info"

Hi! This is me:

http://at.or.at/hans
https://guardianproject.info

IFD:Nutzerstudien WiSe1314/Sicherheit (security)

2013-12-18T20:40:37Z

Hans: first comment

==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.


<div style="color:brown">Developing a clear, concise scheme for representing the states of messages in ChatSecure is a very valuable problem to solve. If the user does not understand when things are private or not, they could easily leak private information. Keep in mind all manner of design treatments: font, color, iconography, etc. I think that finding well known metaphors could likely produce good results here, but a very simple abstract scheme could also work. One of my favorite ideas here is relying on the default look. ChatSecure should provide private/secure messaging by default. If the messages are not private/secure, then that is a warning/error condition and should be represented as such.</div>--[[User:Hans|Hans]] 21:40, 18 December 2013 (CET)

== 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.

[[image:IFD-NuSt security-mockup.jpg|1000px]]



==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/Gruppe Anmeldung

2013-12-18T20:35:16Z

Hans: added my comments

'''Aims of data gathering'''

During the course "Nutzerstudien" we wanted to know how important security is for students at our age, what they expect from chat apps and what their problems/whishes are. Main focus was also the question of authenticity.
For that reason we started to interview a few people from our social environment.

'''Data gathering: Interviews/Observation'''

1. Interviews:

Interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing these people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students. Thereby we had a huge spectrum of users.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?

2. Observation:

Next week we want to make some usability tests of the app (ChatSecure) to find out how others deal with the login process. We want to find out if the log in process is intuitive for the user or not. So we get to know about user's handling with apps and their expectations. We hope to get suggestions and ideas for a better log in process based on the user's behavior.
<div style="color:darkgreen">Great idea. It is not easy though to see why for an outsider. You could fix it by explaining first, why and how you canged to the topic "login" and because of this it could not be part of the interview process one or two weeks ago.</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)
<div style="color:blue">I tried to explain what we want to achieve with the usability tests. Ok? [M.E.]</div>
<div style="color:brown">I think this is an area that definitely needs analysis from a usability perspective, and having feedback from people who have limited experience with ChatSecure will be quite helpful. Having a few different setup scenarios to test with would be very useful since the login is quite different depending on what kind of account, etc. For example, using the same Google account as the phone should be quite simple. Using a Facebook acocunt should be a little more work, but straightforward. Using any account with Tor/Orbot would be trickier. And perhaps the hardest will be setting up an account on a server like jabber.ccc.de</div>--[[User:Hans|Hans]] 21:17, 18 December 2013 (CET)

'''Data Analysis & Main Results'''

* App Requirements
** accessibility is of prime importance, so the app have to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necassary. <div style="color:brown">not quite sure what this is, could you elaborate on it?</div>--[[User:Hans|Hans]] 21:35, 18 December 2013 (CET)

* Security
** It would be useful to have a password for the app.
** To feel safe, the user desires to have a security warranty.
** It is important that apps are immune from viruses.
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

<div style="color:darkgreen">There are lots of "the user wants". It would be easier for outsiders to understand, if you could explain ''why'' the user wants this ('''if''' you know that. Naturally, my request is not asking for inventing explanations! If you only know that users ''want'' but not ''why'' you could make it subject of further research)</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">I tried to phrase and explain some points in another way. Is it ok? [M.E.]</div>
<div style="color:brown">Definitely some interesting results here, it sounds like people are interested in security and are trying to figure out ways to increase their own security. It would be quite valuable to explore ideas of how people represent their concerns, and how they aim to increase their own security. About Authenticity, its a hard concept in computers. I think most computer users don't understand that its easy to fake messages. My guess is that people are concerned about it, but don't really understand the technical issues so they assume things they receive are what they seem to be. A parallel test on this topic could be very illuminating, like showing users how to generate fake emails, messages, etc. to make them appear they are coming from someone they trust. Also, I'm not quite sure what the point of view of all of these bullet points are. Are they from the person running the tests, or are the things that the users in the tests communicated? My guess is that they are all summaries of things communicated from the users.</div>--[[User:Hans|Hans]] 21:35, 18 December 2013 (CET)

'''What specific problem we want to solve'''

We want to solve some problems with the login-process and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

<div style="color:darkgreen">Nice proposal. Are you really talking about the log-in or about setting up a new (Jabber) account? Because in my experience it is not easy to set it up, but once you have your account working and data saved, it behaves very well. But please prove me wrong if that is a singular experience</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">We really focus on the sign up process. There is the problem that you don't get an advice to enter the password but it is nessacary. The process is very inconvenient, it needs to many steps till you can start to chat so that we want to create an easier way. [M.E.]</div>

<div style="color:brown">I think this is important work since the process is currently confusing, but also complicated so its not easy to fix the usability issues. But its also not such a huge task, so you should be able to get solid results in the time you have in this class.</div>--[[User:Hans|Hans]] 21:35, 18 December 2013 (CET)

'''Plans – how we want to solve the problem(s)'''

Method 1: Other application's test

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone)

Solution:

We want it as intuitive as WhatsApp and Facebook Messenger but we also want it to be save. So there have to be an additional button for entering a password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]

Our first prototype for the login process.

<div style="color:brown">The difficult part here is that there is no known way of making a secure, private connection without some kind of login process. WhatsApp's uses an automatically generated password that it is not hard for a malicious user to generate, getting full access to the whole account. So its security is very poor, but its usability is great. As far as I know, Facebook does require a login, but it just handles it well and it only happens once really. Facebook is probably a better example here. It probably makes the most sense to compare the Facebook mobile app's first time setup/login procedure with ChatSecure's Facebook login procedure. Then additionally, it would be great to see a comparison of other apps like ChatSecure that allow users to use a wide variety of accounts (Xabber, Beem, etc.) </div>--[[User:Hans|Hans]] 21:35, 18 December 2013 (CET)

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung

2013-12-18T20:18:31Z

Hans:

'''Aims of data gathering'''

During the course "Nutzerstudien" we wanted to know how important security is for students at our age, what they expect from chat apps and what their problems/whishes are. Main focus was also the question of authenticity.
For that reason we started to interview a few people from our social environment.

'''Data gathering: Interviews/Observation'''

1. Interviews:

Interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing these people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students. Thereby we had a huge spectrum of users.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?

2. Observation:

Next week we want to make some usability tests of the app (ChatSecure) to find out how others deal with the login process. We want to find out if the log in process is intuitive for the user or not. So we get to know about user's handling with apps and their expectations. We hope to get suggestions and ideas for a better log in process based on the user's behavior.
<div style="color:darkgreen">Great idea. It is not easy though to see why for an outsider. You could fix it by explaining first, why and how you canged to the topic "login" and because of this it could not be part of the interview process one or two weeks ago.</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)
<div style="color:blue">I tried to explain what we want to achieve with the usability tests. Ok? [M.E.]</div>
<div style="color:brown">I think this is an area that definitely needs analysis from a usability perspective, and having feedback from people who have limited experience with ChatSecure will be quite helpful. Having a few different setup scenarios to test with would be very useful since the login is quite different depending on what kind of account, etc. For example, using the same Google account as the phone should be quite simple. Using a Facebook acocunt should be a little more work, but straightforward. Using any account with Tor/Orbot would be trickier. And perhaps the hardest will be setting up an account on a server like jabber.ccc.de</div>--[[User:Hans|Hans]] 21:17, 18 December 2013 (CET)

'''Data Analysis & Main Results'''

* App Requirements
** accessibility is of prime importance, so the app have to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necassary.

* Security
** It would be useful to have a password for the app.
** To feel save, the user desires to have a security warranty.
** It is important that apps are immune from viruses.
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

<div style="color:darkgreen">There are lots of "the user wants". It would be easier for outsiders to understand, if you could explain ''why'' the user wants this ('''if''' you know that. Naturally, my request is not asking for inventing explanations! If you only know that users ''want'' but not ''why'' you could make it subject of further research)</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">I tried to phrase and explain some points in another way. Is it ok? [M.E.]</div>

'''What specifc problem we want to solve'''

We want to solve some problems with the login-process and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

<div style="color:darkgreen">Nice proposal. Are you really talking about the log-in or about setting up a new (Jabber) account? Because in my experience it is not easy to set it up, but once you have your account working and data saved, it behaves very well. But please prove me wrong if that is a singular experience</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">We really focus on the sign up process. There is the problem that you don't get an advice to enter the password but it is nessacary. The process is very inconvenient, it needs to many steps till you can start to chat so that we want to create an easier way. [M.E.]</div>

'''Plans – how we want to solve the problem(s)'''

Method 1: Other application's test

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone)

Solution:

We want it as intuitive as WhatsApp and Facebook Messenger but we also want it to be save. So there have to be an additional button for entering a password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]

Our first prototype for the login process.

IFD:Nutzerstudien WiSe1314/Gruppe Anmeldung

2013-12-18T20:17:49Z

Hans: comment on question

'''Aims of data gathering'''

During the course "Nutzerstudien" we wanted to know how important security is for students at our age, what they expect from chat apps and what their problems/whishes are. Main focus was also the question of authenticity.
For that reason we started to interview a few people from our social environment.

'''Data gathering: Interviews/Observation'''

1. Interviews:

Interview partner:

{| class="wikitable"
|-
! Number
! Age class
! Course of studies
|-
| 1
| <20
| Arts
|-
| 2
| <20
| Arts
|-
| 3
| 20-25
| Science/Engineering
|-
| 4
| 25-30
| Science/Engineering
|-
| 5
| <20
| Fine Arts/Design
|-
| 6
| <20
| Fine Arts/Design
|-
| 7
| <20
| Fine Arts/Design
|}

Reasons for choosing these people:

We wanted to figure out the differences between the students of Arts, Fine Arts/Design and Science/Engineering. So we chose people from our social environment. Because we are students from different courses of studies (Arts, Fine Arts/Design and Science/Engineering) we had the chance to interview these types of students. Thereby we had a huge spectrum of users.

Central questions:
* What chat apps/programs do you use and for what purposes (one-on-one interviews or group discussions, image, video and link transfer)?
* Where do you see advantages and disadvantages of your favorite chat program?
* How important authentication is for you?
* How should a trustable profile be? What information are important?
* In what situations you prefer the phone or an E-Mail before chatting?
* What are requirements for you to use a new app with guaranteed security?
* How often do you use them and how important they are for you?
* How important is security for you while chatting with people?
* What measures do you probably adopt to be safe?
* What functions and design features do you find most important for a chat app?

2. Observation:

Next week we want to make some usability tests of the app (ChatSecure) to find out how others deal with the login process. We want to find out if the log in process is intuitive for the user or not. So we get to know about user's handling with apps and their expectations. We hope to get suggestions and ideas for a better log in process based on the user's behavior.
<div style="color:darkgreen">Great idea. It is not easy though to see why for an outsider. You could fix it by explaining first, why and how you canged to the topic "login" and because of this it could not be part of the interview process one or two weeks ago.</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)
<div style="color:blue">I tried to explain what we want to achieve with the usability tests. Ok? [M.E.]</div>
<div style="color:lightgreen">I think this is an area that definitely needs analysis from a usability perspective, and having feedback from people who have limited experience with ChatSecure will be quite helpful. Having a few different setup scenarios to test with would be very useful since the login is quite different depending on what kind of account, etc. For example, using the same Google account as the phone should be quite simple. Using a Facebook acocunt should be a little more work, but straightforward. Using any account with Tor/Orbot would be trickier. And perhaps the hardest will be setting up an account on a server like jabber.ccc.de</div>--[[User:Hans|Hans]] 21:17, 18 December 2013 (CET)

'''Data Analysis & Main Results'''

* App Requirements
** accessibility is of prime importance, so the app have to be widespread to make the user downloading it.
** The app should be for free.
** For the user it’s important to be up-to-date and flexible with messages. So he/she prefers an app for chatting.

* Visual Design
** Complexity takes a lot of time, so you need a simple, intuitive, neatly arranged design, which looks uniform on all gadgets.

* Interface & Functions
**It is handy for the user to have an interface, where you can see who is online at the moment and when a contact was online the last time.
** The app should contain a function to let the user know if the chat partner read the messages because it faciliate the communication.
** The user wants to send out photos/videos.
** The user likes to express its emotion with a lot of smileys.
** The function "writes..." is not necassary.

* Security
** It would be useful to have a password for the app.
** To feel save, the user desires to have a security warranty.
** It is important that apps are immune from viruses.
** Important information, link, photos, videos, … are often sent by E-Mail.
** Distrust towards apps results e.g. from missing knowledge about safety and smart phone-apps.
** People use safety-options of social networks (e.g. Facebook) but don’t know, if they really work.

* Authenticity
** If you want a trustworthy profile you have to find a good balance between too much and too little information.
** (To much) Personalized advertising makes the user feel insecure.
** A “real” profile picture is soothing for the user.
** Authenticity doesn't loom large for students personally.

<div style="color:darkgreen">There are lots of "the user wants". It would be easier for outsiders to understand, if you could explain ''why'' the user wants this ('''if''' you know that. Naturally, my request is not asking for inventing explanations! If you only know that users ''want'' but not ''why'' you could make it subject of further research)</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">I tried to phrase and explain some points in another way. Is it ok? [M.E.]</div>

'''What specifc problem we want to solve'''

We want to solve some problems with the login-process and make it easier to use.
It's hard and circular to login with one of your accounts, because there are too many steps until you are finally logged in. Moreover the buttons are difficult to find on the interface.
Therefore we want to create a new login-process.

<div style="color:darkgreen">Nice proposal. Are you really talking about the log-in or about setting up a new (Jabber) account? Because in my experience it is not easy to set it up, but once you have your account working and data saved, it behaves very well. But please prove me wrong if that is a singular experience</div>--[[User:JanD|JanD]] 19:58, 13 December 2013 (CET)

<div style="color:blue">We really focus on the sign up process. There is the problem that you don't get an advice to enter the password but it is nessacary. The process is very inconvenient, it needs to many steps till you can start to chat so that we want to create an easier way. [M.E.]</div>

'''Plans – how we want to solve the problem(s)'''

Method 1: Other application's test

First we start to analyse the login process at other applications.
We found out that WhatsApp is the most widespread app to chat for our target group, second one is the Facebook messanger.

1. WhatsApp

This application doesn't contain a login process. You only have to choose the app to be online and you directly see all of your conversations. It is quite easy and intuitive.

2. Facebook Messenger

This application functions nearly the same way as WhatsApp, so you don't need a password to sign in.

Our conclusion:

Both applications manage without a password. That's quite intuitive but it isn't quite save. While doing our interviews we experienced that it would be convenient to have a password to have a safety warranty (e.g. in case of losing the smartphone)

Solution:

We want it as intuitive as WhatsApp and Facebook Messenger but we also want it to be save. So there have to be an additional button for entering a password.

[[File:Prototyp Anmeldeprozess.jpg|600px]]

Our first prototype for the login process.