söndag 17 april 2016

POP Prototype

We started working on our clickable prototype using the application POP as our SDK of choice.

POP Project

Extremely low-fi!

torsdag 14 april 2016

Feedback Reflection

Unfortunately the evaluation we got could not help us that much. They mentioned the difference between the online and offline mode, and also asked questions about our functions. One concrete thing we discussed was some sort of tutorial. They suggested a help icon which would be discrete and optional. There is a similar function in the app iMovie.


Evaluation from group 5 (unedited)

# Grupp 4
[Bloggen](https://www.mdia4.blogspot.com)

Skicka till:
Facebook eller mail: lokemolund@gmail.com
### Slide 1 Alvaro2000

Waxholmsrutten, båt

### Slide 2
Intervjuer:
 - Målgrupp och anv.krav
 - De flesta nöjda
 - Val av målg. __inhemska och utländska turist__
 - Målgrupp baserat på användarkrav


### Slide 3 State of the art
Brainstorm: Image recognition, AR (augmented reality), GPS, turistappar

Idé: Rikta kameran mot sevärdheter och få info om byggnader. GPS hjälper.

### Slide 4 Personas och scenarios
###### Leif GB Glasson:
Inget spec.
Scen: Han tar inte bilder men vill få info om vad han tittar på. Har har sina keds med sig och vill verka smart.
###### Elisabeth Swan:
Offline mode TILLSAMMANS med image recognition? Svar: Känna igen i efterhand.

###### Annat
Photograph mode?: ... ... ... Integrerad kameraapp, kopplad till bildbanken.
Finns SOTA om photographapp?: JA!

Scen: Engelsman som har tagit bilder under rutten. Hon vill kolla upp vad hon fotat.


### Slide 5 Design
 - Fortsatt konceptdesign
 - Parallell design

Blandad språk?: Nej, bild med flagga för olika språk.

### Slide 6 Final Design

Bild med fina små designbilder.
Cool ide!: Historiska bilder på gamla byggnader.

### Diskussion
Livefunktion för folk som inte vill använda mycket data?: Realistiskt så hoppas man på att waxholmsbåten köper appen och bidrar med en server/wifi på båten som tillhandahar infon. Appen ska ha skyssta funktioner utan internet.
Eftersom appen bara är för båtlinjen så kanske all info kan finnas nedladdad. Inte bara kamera i offline.

Hjälpfunktion?: Det får vi se under think aloud. Man vill få det intuitivt för för mycket info blir jobbigt. Vi gillar ikoner.

SOTA för imagerec?: ... ... ... Inte allt i huvudet. Ingen aning.

: Man ska kunna välja att få kort eller lång info. Kanske med en light-app?

Behövs tutorials: Kanske men inte om vi lyckas få funktionerna tillräckligt intuitiva.

Games?: Quiz eller nått. Acheivements som ger poäng till rabatter.
Varför slopade ni games?: Inte slopat än men inte säkra på om det behövs.

## Tankar
 - Vilka funktioner kan man använda offline?
 - Många intessanta funktioner men blir helhetsbilden tillräckligt tydlig?
 - Skall det finnas en tydlig knapp för att förhindra internetuppkoppling.
 - Kan en tutorial behövas?
 - Varför ska folk använda just denna imagerec och inte andras?

onsdag 13 april 2016

måndag 11 april 2016

Seminar 2 Meeting


Can letting users test our product prototype be useful for us?
In our current project we will use a field study as soon as we have made a hi-fidelity prototype and use that data to further improve the usability. Before that however, we first need to develop a functional prototype.

What is the best evaluation method for our product?
Decide-Framework
  1. Determine the goals
    1. We want to know how our first concept design is interpreted by the target group to learn how we should continue with the project.
  2. Explore the questions
    1. How intuitive is the user interface?
    2. Do you find the UI well designed?
      1. How can it be improved?
    3. How easy is it to find a specific element?
      1. Where do you experience the difficulty?
  3. Choose the evaluation paradigm and techniques
    1. We will begin with a heuristic approach, for example Nielsens Heuristics, since we need a functional prototype before we start conducting field studies in a natural setting.
  4. Identify the practical issues
    1. Time constraints
    2. Low budget/no budget
    3. We need to avoid influencing the user while conducting the evaluations. Cognitive walkthroughs is a solution.
  5. Decide how to deal with the ethical issues
    1. We probably won’t have any ethical issues. The GPS capabilities will be informed to the user.
  6. Evaluate, interpret and present the data
    1. We will first make a prototype using some sort of prototype tool. We will then use the heuristic approach to evaluate the prototype UI and gather data ourselves, to save time, and iterate this process until we are satisfied. Afterwards, field studies will be conducted in the natural setting (the boat) using cognitive walkthroughs to clearly see how the users interact with the prototype.

If we had unlimited time and money, we would evaluate the prototype(s) by collecting data automatically from the users while the prototype is running.


Seminar 2

Chapter 13,14 and 15 (4th)

Chapter 13 

This chapter introduces evaluation and why it is integral to design processes. There are different types of evaluation that are classified into three broad categories. The first one is controlled settings involving users. The users’ activities are controlled in order to test hypotheses and measure or observe certain behaviors. The main methods are usability testing and experiments. The second category is natural settings involving users. For products that are used in public places there is little or no control of the users’ activities in order to determine how the product would be used in a real situation. The main method used is field studies. The last and third category is any setting not involving users, for example could experts identify the most obvious usability problems by criticizing, predicting, and modelling aspects of the product. The methods used includes inspections, heuristics, walkthroughs, models, and analytics.

Another issue the chapter discusses is how to inform participants about their rights and getting their consent. It is important when we start doing user evaluations that the participants have to be told what kind of task they are supposed to perform, under which conditions the derived data will be collected, and what we will use the data for when the participants have finished the task.

Chapter 14

The following chapter continues to discuss evaluation by introducing different evaluation studies that take place in various settings, from controlled settings to natural settings. The focus is on usability testing.

One central part of usability testing is collecting data about users' performance on predefined tasks. These tasks could incorporate searching for information or navigating an interface. The quantitative performance measures that are obtained produce the following types of data:

● Time to complete a task. 
● Time to complete a task after a specified time away from the product. 
● Number and type of errors per task.
● Number of errors per unit of time. 
● Number of navigations to online help or manuals. 
● Number of users making a particular error. 
● Number of users completing a task successfully.

To connect this chapter to the previous chapter I want to mention that chapter 14 has an example of usability testing, where two usability specialists conducted a usability test of the websites and apps specific to the iPad. Before the actual tests, the participants were asked to read and sign the terms and conditions of the study, which explained the following:

● what the participant would be asked to do;  
● the length of time needed for the study; 
● the compensation that would be offered for participating; 
● the participants’ right to withdraw from the study at any time;
● a promise that the person's identity would not be disclosed; and 
● an agreement that the data collected would be confidential and would not be made 


Chapter 15

The last of the three chapters introduces heuristic evaluation and walkthroughs, as ways to, in most cases, perform evaluations without an actual user. For our project, Nielsen’s 10 usability heuristics could prove very useful since we at this early stage can not perform field studies in the users' natural setting. Cognitive walkthroughs are also suitable since we rather easily can simulate our target group's problem-solving process to some degree. Pluralistic walkthroughs could also be a possibility as soon as our project has gone from a sketch/paper prototype to a more or less high-fidelity prototype developed using a software development kit (SDK).


Questions for the seminar:

Which of the types of evaluation should we use for our project? Controlled or natural settings involving users, any settings not involving users or maybe several of them?

How are we going to conduct our experiments in a reasonable fashion? Maybe an heuristic approach is suitable since it is rather difficult to try our product in a natural setting?


Would cognitive walkthroughs and predictive models such as Fitt's Law  prove useful?

Reading Seminar 2

I have read the chapters in the 1st edition of the literature corresponding chapter 13 and 15 in the 4th edition (as that is what I have access to), that is the chapters about evaluation.

I thought the example scenarios the text brought up, about the Olympic Message System and HutchWorld, were particularly interesting as you can follow the process of evaluation in real cases. Both these cases bring up the importance of user testing and iterative evaluation. It is important to keep going back to testing; if you notice flaws and redesign, you should test again.

The text continues with going through four core evaluation paradigms: ”quick and dirty” evaluations, usability testing, field studies and predictive evaluation. The ”quick and dirty” approach is used when you want to get feedback fast. Usability tests are carried out in a controlled manner in a laboratory environment (controlled environment), as opposed to field studies which focus on the user's natural environment. Lastly, a predictive evaluation relies on experts rather than users. Of course, the best way to do and evaluation is to combine these paradigms (for example to only do a predictive evaluation would probably be useless), but how much evaluation is necessary and even possible depends on the both the project itself and budget- and time limitations.

Of course, the DECIDE-framework was also brought up. As this framework is made to help beginners in evaluating, I think it could be useful to us.

The most important part though, according to me, was the part about what, why and when to evaluate. If you don’t know what or when to evaluate something, and especially why you evaluate it, the chances are high you won’t get anything useful out of it. For example it seems like many companies think evaluation is for verification rather than the opposite, that is to find flaws that make the product unuseful to the actual users, before you let it out on the market. Because a product that isn’t useful will simply not be used.


Questions and points to discuss:

What type of evaluation paradigm should we use? It it possible for us to use more than one?
At what stage should we start evaluating (lo- or high-fi)?


Seminar 2


The chapters are mainly about Evaluation, and why evaluation is important. 
It is important for it's use in the design process as a way to focus on the goals for the product, and need of the customers. By doing this you can ensure that the resulting product meets the user needs and causes less frictions between the users and the product itself.

There are multiple evaluation paradigms or methods that are to be used depending on what is to be evaluated, for example, Heuristic Evaluation is a evaluation method that uses "Heuristics" to make the User Interface (menus, navigational systems, etc) more user-Friendly. When using Heuristics, you need to keep in mind that different Heuristics focuses on different specific UI (User interface) problems, and it is therefore, very important that the right one is chosen from the start when evaluating.
As noted, different Evaluation methods can be used in different scenarios.
To find the right Method for the current scenario, you can use the Decide-Framework

The Decide-framework is divided into different points:

  1. Determine the goals of the evaluation (E.g. Design or usability evaluation?).
  2. Explore and determine the questions (the questions that the evaluation should answer).
  3. Choose the evaluation methods or paradigms.
  4. Identify practical issues (E.g. are we staying within our target group?).
  5. Decide how to deal with different ethical issues.
  6. Evaluate and present the data (as unbiased as possible).


Questions for the seminar:

  1. Where should we go next in our design process? iterate on Concept design?
  2. Should we create multiple low-fidelity prototypes and gather test data from our target group?

söndag 10 april 2016

Seminar 2

These chapters talked about different kinds of evaluation, how and why evaluation is important and some evaluation paradigms. They brought up things as controlled setting evaluation versus natural setting evaluation. I really like the natural setting evaluation because of the pointers on of the lectures took up. There we heard about a natural setting evaluation where when a error code appears on the screen the fix was to call for another co worker. When viewing users in the natural flow we can really see how our product is used and what changes should be done.
But of course it is always best to use many of these methods in conjunction. And because we don't live in the “waterfall age” and use agile development we can always go back and rethink and redo them.


They also brought up a framework for designers to evaluate the product.
Decide-model
  1. Determine the goals
  2. Explore the questions
  3. Choose the evaluation paradigm and techniques
  4. Identify the practical issues
  5. Decide how to deal with the ethical issues
  6. Evaluate, interpret and present the data


Question: What type of evaluation techniques should we use?
Question: Should we create 2 different low-fidelity designs and see what users like best or use one?

Reading Seminar 2 - Evaluation

I read chapter 10, 11 and some of chapter 12 and 13 in the first edition of the book.

The chapters main focus was on why evaluation is important and when to use the different evaluation paradigms and techniques. So, some of the reasons to evaluate is to fix problems before you ship the product, to concentrate on proved problems that users discover while testing, and when you release the product you can have confidence in that it will work. Understanding which UX-goals and usability the users require is essential to make a product successful. Evaluation makes it possible for developers to discover these goals and needs. As most of the previous design processes, evaluation is also an iterative process and can be done using different paradigms and techniques. The paradigms reminds a lot of the ones used when establishing the user requirements. A question for the group at the seminar: which evaluation paradigm and technique would be best suited for us?

To answer this we can use the DECIDE framwork. The framwork provides a checklist to help the evaluation process:

1. Determine the overall goals that the evaluation addresses.
              What are the users needs?
              What are we evaluating? Design? Concept? Usability?
2. Explore the specific questions to be answered
              Depending on the goals, set relevant questions questions.
3. Choose the Evaluation Paradigm and Techniques to be answered the questions in step 2
               Choose a paradigm and technique. The paradigm determines which techniques are appropriate.
4. Identify the practical issues that must be addressed.
               Identify potential issues BEFORE starting.
               For example, which users should test the prototype? Are they representing the target group?
5. Decide how to deal with ethical issues 
              (I don't think this is critical at our stage)
6. Evaluate and present the data.
              Try to prevent bias.

               Is the data enough to generalize the findings?

Some more practical issues to address: 
How to observe users in their natural environment without disturbing them
Having appropriate equipment available
Dealing with our short schedules (I feel this is something extra important to discuss)
Selecting techniques that are possible for us to do.
I'm guessing we should start evaluating at early stages of our prototype, but should we start at our lo-fi prototype sketch or sould we make a mockup, such as a wizard of oz prototype first?
Should we focus purely on the conceptual design evaluation at first or do it parallel with heuristic evaluations?



Seminar 2


Chapter 13 is about evaluation, why it should be done, what needs to be evaluated, where it should take place, and when. Simply put, evaluation is very important for the development of a product to improve its design and to inform the designer that the product is user-friendly and enjoyable for the user. As the book mentions, well-designed products sell. Depending on the product or prototype, different types of feed back will be of interest by the developer.

There are three categories of evaluation depending on the setting, if users are involved or not and the level of control. Two of these involve users, with one being in a controlled setting, this one is good for when more control is needed and when outside influences and distractions have to be excluded. The other is in a natural setting and is optimal when the evaluator doesn’t want to affect what people do during evaluation. This is also called field studies. The third one is without users and the setting can be anywhere, often imagined or modeld. These methods are often combined to obtain a clearer understanding, but knowing when to use which method is important. 

Chapter 15 talks about this third category where users are not present. These methods were developed to use when real usability testing wasn’t possible because of users not being available or just to save on costs. The inspection methods that were developed are heuristic evaluation and walkthroughs, were there are cognitive walkthroughs, were a users problem-solving process to accomplish tasks with a system is simulated and analyzed, and pluralistic walkthroughs, mostly involving experts discussing usability issues in different given scenarios. These are in turn conducted with so called experts that are, as the name implies, experts in both interaction design and user behavior, that often role-play typical users and evaluate whether user-interfaces follow previous tried and tested principals. The original heuristic evaluation methods for HCI were developed by Jakob Nielsen, the book summarizes the ten usability heuristics that were derived from an analysis of 249 usability problems. Predictive models are also used without the users being present and simliar to analytics data is collected. It provides estimates of efficiency for various task in different systems. 


What is the best evaluation method for our product?

torsdag 7 april 2016

Team meeting 7/4

Today we have had a team meeting. We have discussed and drawn up a new design. And polished on the scenarios.

Design:
We have agreed on a simple and minimal design where we use the left and swipe to move between tiles and functions. As little ui as possible to not obstruct the view of the camera and buttons on the lower half of the screen for easy accessibility.
The Time Machine function is now revamped to show 3d models of how areas and silhouettes change over time instead of seeing how the buildings change over time.



tisdag 5 april 2016

Brainstorming & Lo-Fi-Prototype using Parallel Design


During our last exercise we had a brain-storming session and we did our first lo-fi prototypes.

While brain-storming we turned a lot of small ideas into bigger ones! Everyone yelled out ideas and words that we thought would work with our concept idea. We did this for about ten minutes until the ideas started slowing down. The result: 



We later picked the ones that best fit our product design and placed them into categories:

After brain-storming we started summarizing and discussing and came up with some new features such as letting people review the spots they visited (which they found out about with the app) and that we might charge money for the previously mentioned "time-machine" idea as a "pro-version". Something we talked a bit more about was the idea of gamification. We talked about implementing some kind of game and high-score lists. Ideas for games were quizzes (about the locations informed about in the app), letting people tag themselves at the locations (using gps) and gaining points, battle-ship etc. Another idea was to get the application to point towards a location you're interested about, i.e if you're on the boat in camera-mode and you don't know where Grönalund is, an arrow will appear on the screen to direct where you are looking at.

With some time left we started developing a very lo-fi prototype using pen and paper. We used the parallel design technique, splitting up into two groups. Having the concept, personas, pain-points and categories in mind was a very good help constructing the prototype. 

When comparing the prototypes one group preferred having the camera-guide-mode as start screen, while the other group figured a menu start screen would be better. This brought the discussion to the context of use, will the users only use the application on the boat? If not, a menu start screen would probably be for the best, but if the app is limited to the boat the camera-guide-mode would probably be preferred

Both prototypes had good ideas, which we will implement in the following prototypes. After doing this exercise we realized that the iterative process is truly a necessity.

The prototypes:





One design focusing on the camera function being the main feature, while the other design chose to have a menu of some sort and later choosing the camera function.












fredag 1 april 2016

List of Pain Points


Issues/Opportunities Primary persona
Elisabeth Swan
Secondary persona
Leif GB Glasson
Light information
regarding neighbouring
sites to visit
3 2
In depth information
regarding neighbouring
sites to visit
2 1
Voiceover 4 2
Offline mode 1 4
Transportation tips 2 3
Photograph mode 1 3

Persona 2 - Leif GB Glasson

Leif GB Glasson



Background:

Leif, 40, lives in Kopparberg with his wife Gunilla, 41, and his two children, Vincent, 8, and Hanna, 10, in a house. Leif works as a teacher at the local primary school. Gunilla works as an accountant in an accountant firm. Leif wanted to become a rock star when he was younger. Since then, he has always played the electric guitar in a band. Leif enjoys spending time with his family.

Personality:

Leif is calm, kind and structured. He really enjoys his profession. Leif hasn't really been involved in modern technology, but just recently purchased his first smart phone to improve his technical skills.


Today:

Today Leif and his kids are in Stockholm to go to Gröna Lund on the first two days of summer vacation. Leif wants to teach his children a little about Stockholm and its history since it's their first time in Stockholm. They are staying the weekend at a hotel in Stockholm.

Goals:

Leif wants to give his kids a great day in Stockholm and possibly educate them a bit. Leif would like to relieve himself from the stress caused by his teaching.

Scenario 1:

It's saturday. Leif and the children came to Stockholm earlier this day by train, arriving at Cityterminalen. Leif can find his way in Stockholm's subway since he has visited the capital before in several occasions. He decides to take the trolley to Djurgården because it's the fastest way of transportation to Gröna Lund from where they are. His children are very excited.

After a great day at Gröna Lund, the children are both tired and a bit sad because they don't want to leave. Leif decides to take the boat to cheer his children up, he hopes that the beautiful scenery will make them a little happier. Leif wants to show them the surroundings, but the children don't pay much attention. He would like to find something that would entertain them by showing Stockholm in a fun and educational way.

Scenario 2:


Leif and his children has spent a long weekend in Stockholm, in the time that they spent there they took a lot of pictures on different historical buildings and monuments.
It's Monday, Leif and his children board a train at Centralstationen to go home, and three hours later they arrive in Kopparberg.

They really want to show Gunilla their pictures. While doing so, Gunilla asks a lot of questions about the buildings in the pictures. Unfortunately, Leif isn't very educated on the topic. Leif would also like to show the pictures to his pupils after their summer vacation.

Persona 1 - Elisabeth Swan

Elisabeth Swan



Background:

Elisabeth Swan is a 22 year old strong independent woman from London. Elisabeth studies Psychology at the University of Oxford in England. Elisabeth's other interests are history and architecture. She also loves travelling the world, both alone and with friends. She's visited countries in both Asia and Africa. She wouldn't mind pursuing her PhD abroad. On the side of her studies Elisabeth is a micro blogger, she posts a lot on Twitter and Instagram.

Personality:

Elisabeth is a social and adventurous person. She's open minded, spontaneous and energetic. Elisabeth wants to travel and see the world a lot before graduating and later being stuck at her job. She's also a vegan and engaged in environmental issues.

Today:

Elisabeth is currently taking a year off to travel Europe to mostly visit capitals and their famous sites. She's staying in Stockholm for two nights and she wants to experience as much as possible during her brief visit.

Goals:

Elisabeth is looking to visit Stockholm's most famous sites and generally have a pleasant experience. As most tourists, Elisabeth is looking forward to taking a lot of pictures on historical buildings and learn about Stockholm during her visit.  She will later post the pictures on Instagram.


Scenario 1

Elisabeth is browsing the internet checking out Stockholm from cyberspace in preparation for her trip coming up in a few days. Rather quickly she finds out about the Nordic museum which catches her interest -  it would certainly be a great place to learn about nordic history!

Arriving at the Arlanda airport a couple of days later, Elisabeth grabs a taxi after reclaiming her baggage. Eventually when reaching the hotel she checks in at the reception and proceeds to her room to quickly unpack her things, eager to get out in Stockholm. Elisabeth then leaves the room down to the hotel's entrance asking the hotel's receptionist about the nicest way to the Nordic museum as a tourist. The receptionist tells her that there is a boat trip to Djurgården where the Nordic museum is situated. Elisabeth remembers reading about it, and asks for the direction.

Well at the boat, Elisabeth really enjoys the view of Stockholm, especially since it's such a lovely day with the sun shining and almost a complete absence of clouds. She spots a lot of buildings and interesting architecture from the boat, and grabs her cellphone to take pictures. Elisabeth imagines how the harbour and its surroundings might have looked like in the past, and wishes she knew more about their names and history.


Scenario 2:

When Elisabeth arrived at the Arlanda airport, her good friend Markus was waiting there for here at the exit. They took Markus car to his home in Hammarby sjöstad.
When she arrived she immediately wanted to go out and discover the Stockholm city. Markus recommended the boat to Djurgårded from Slussen. He tells her that there are a lot of interesting sites for them to visit there.
Later at the boat, Elisabeth Takes a lot of pictures that she wants to upload to her Instagram account.
Elisabeth has been out all day discovering different places at Djurgården, visiting museums and other stuff. Now back at Markus place, Elisabeth checks through all of her pictures taken during the boat trip earlier. She wants to post them on her Instagram and asks Markus about the names of the buildings and landmarks in the pictures, but he isn't sure.
Elisabeth decides to upload the pictures anyway, but without any hashtags or information.