HCI

Question 1

What do we have to take into account in HCI?

Answer 1

every element of the human, from the way they perceive and interact with the world, to their long history of using computers and technology

Question 2

What application has turned the entire world into basically an instance of HCI?

Answer 2

augmented reality

Question 3

How should we think about HCI?

Answer 3

the human interacting with the task, through the computer. The interaction is really between the human and the task and the computer in the middle just mediates that interaction. Or to put this differently, the human and the computer together, interact with the task

Question 4

Good example of interface becoming invisible

Answer 4

Video games - actions on controller match screen, user feels like they’re in the game world

Question 5

Example of interface being more visible than it should

Answer 5

Multiple remotes to turn on audio, video, etc. for the task of watching TV

Question 6

What is HCI relative to similar fields?

Answer 6

Industrial design, HCI, and product design all fall under Human Factors Engineering

Under HCI, you have UI design, UX design, and Interaction design

At the top, Human Factors Engineering is fed into by Engineering and Psychology

Question 7

HCI vs User experience design

Answer 7

• HCI is largely about understanding the interactions between humans and computers. User experience design is about dictating the interactions between users and computers. In order to design user experiences very well, you need to understand the user, you need to understand their interactions with interfaces.
  * And that’s why I personally consider user experience design to be a subfield of the broader area of HCI.

Question 8

What’s important to do when you pursue HCI?

Answer 8

Leave behind what you know.

Question 9

Why is HCI so important nowadays?

Answer 9

A few years ago, you wouldn’t have found computers in refrigerators and wristwatches, but as microprocessors became cheaper and as the world became increasingly interconnected, computers are becoming more and more ubiquitous. We now have ubiquitous computing.

Question 10

Context-sensitive computing

Answer 10

Equipping user interfaces with historical, geographical, or other forms of contextual knowledge

Question 11

Information visualization

Answer 11

• Computers give us a powerful way to represent data in complex, interactive ways
  
  • What’s particularly notable about data visualization and HCI is the degree with which it fits perfectly with our methodologies for designing good interfaces:
    
    • Match the user’s mental model with the reality of the task at hand. In the same way, the goal of information visualization is to match the reader’s mental model of the phenomenon to the reality of it.

Question 12

CSCW

Answer 12

Computer-supported cooperative work

* Help things like distributed teams
* Community is usually designed in terms of time and place. This course is different time, different place.
* Things like Slack and Hipchat would be examples of same time, different place.
* Kiosk at a museum asking users to enter their hometown would be different time, same place.
* Video production (of this class for example) is example of same time, same place.
* CSCW mediates cooperation across traditional geographic or temporal borders, but can also help us with co-located simultaneous cooperation.

Question 13

Social computing

Answer 13

Recreating social norms within social computing

Question 14

Special needs domain

Answer 14

• One of the most exciting application areas for HCI is in helping people with special needs. Computing can help us compensate for disabilities, injuries, aging.
  * Of course, part of that is engineering, part of it is neuroscience. But it’s also important to understand how the person intends to use such a limb in the tasks they need to perform. That’s HCI intersecting with robotics.

Question 15

5 tips for identifying a task

Answer 15

1. Watch real users. Don’t just speculate and brainstorm. Get out there and watch them.
   
   2. Talk to them! You don’t have to just watch them. Recruit participants and have them talk their way through it.
   3. Start small. Look at individual little interactions. Don’t interpret things you see in terms of what you already believe.
   4. Abstract up. Working from those small observations, try to abstract up to your understanding of the task that they’re trying to complete. Keep asking why they’re performing these actions until you get beyond the scope of your design.
   5. You are not your user. Even if you regularly perform the task for which you’re designing, you’re not designing for just you. You’re designing for everyone who performs the task, so leave behind your own preconceived notions and previous experiences about it.

Question 16

3 views of the user

Answer 16

processor, predictor, and participant

Requirements, evaluations, pro’s, and con’s of each:

Processor: fit within human limits, quantitative experiments, objective comparisons (may use existing data), expert-focused, what (not why), optimize (not redesign)

Predictor: Fit within user’s knowledge, qualitative studies, Fuller picture and may target novices, Expensive to analyze, prone to biases, ignores context

Participant: Fit within usage context, in-situ (real-world) studies, authentic context and faithful user attention, Expensive to perform, needs real interfaces, subject to interference

Question 17

Ex situ

Answer 17

In a controlled or otherwise inauthentic environment

Question 18

In situ

Answer 18

Within the authentic context

Question 19

Design is like weather

Answer 19

it’s never not there, but it can be good or unnoticeable, or bad and interfere with what you’re trying to do

Question 20

Feedback cycles

Answer 20

the way in which people interact with the world, and then get feedback on the results of those interactions.

Question 21

Gulf of execution

Answer 21

distance between a user’s goals and the execution of the actions required to realize those goals

Question 22

Gulf of evaluation

Answer 22

the distance between the effects of those actions and the user’s understanding of those results

Question 23

Feedback cycles are everywhere

Answer 23

• Feedback cycles are incredibly ubiquitous, whether or not there’s a computational interface involved. Everything from reading to driving a car to interacting with other people could be an example of a feedback cycle in action.
  
  • They’re how we learn everything, from how to walk to how to solve a Rubik’s cube to how to take the third order partial derivative of a function. We do something, we see the result, and we adjust what we do the next time accordingly.
  • You may have even seen other examples of this before, too. If you’ve taken Ashok’s and mine knowledge-based AI class, we talk about how agents are constantly interacting with, learning from, and affecting the world around them. That’s a feedback cycle.

Question 24

5 Tips for bridging the gulf of execution:

Answer 24

1. Make functions discoverable. Imagine a user is sitting in front of your interface for the very first time. How would they know what they can do? Do they have to read the documentation, take a class? Ideally the functions of the interface would be discoverable, meaning that they can find them clearly labelled within the interface.
   2. Let the user mess around. You want your user to poke around and discover things so make them feel safe in doing so. Don’t include any actions that can’t be undone, avoid any buttons that can irreversibly ruin their document or setup. That way the user will feel safe discovering things in your interface.
   3. Be consistent with other tools. We all want to try new things and innovate, but we can bridge gulfs of execution nicely by adopting the same standards that many other tools use. Use CTRL+C for copy and CTRL+V for paste. Use a diskette icon for save even though no one actually uses floppy disks anymore. This makes it easy for users to figure out what to do in your interface.
   4. Know your user. The gulf of execution has a number of components, identifying intentions, identifying the actions to take, and taking the actions. For novice users, identifying their intentions and actions are most valuable, so making commands discoverable through things like menus is preferable. For experts though, actually doing the action is more valuable. That’s why many experts prefer the command line. Although it lacks many usability principles targeted at novices, it’s very efficient.
   5. Feed forward. We’ve talked about feed back, which is a response to something the user did. Feed forward is more like feed back on what the user might want to do. It helps the user predict what the result of an action will be. For example, when you pull down the Facebook newsfeed on your phone, it starts to show a little refresh icon. If you don’t finish pulling down, it doesn’t refresh. That’s feedforward, information on what will happen if you keep doing what you’re doing.

Question 25

5 tips for bridging the gulf of evaluation

Answer 25

1. Give feedback constantly. Don’t automatically wait for whatever the user did to be processed in the system before giving feedback. Give them feedback that the input was received. Give them feedback on what input was received. Help the user understand where the system is in executing their action by giving feedback at every step of the process.
   2. Give feedback immediately. Let the user know they’ve been heard even when you’re not ready to give them a full response yet. If they tap an icon to open an app, there should be immediate feedback just on that tap. That way, even if the app takes awhile to open, the user knows that the phone recognized their input. That’s why icons briefly grey out when you tap them on your phone.
   3. Match the feedback to the action. It might seem like this amount of constant immediate feedback would get annoying and if executed poorly it really would. Subtle actions should have subtle feedback. Significant actions should have significant feedback.
   4. Vary your feedback. It’s often tempting to view our designs as existing solely on a screen and so we want to give the feedback on the screen. But the screen is where the interaction is taking place, so visual feedback can actually get in the way. Think about how auditory or haptic feedback can be used instead of relying just on visual feedback.
   5. Leverage direct manipulation. We talk about this a lot more, but whenever possible, let the user feel like they’re directly manipulating things in the system. Things like dragging stuff around or pulling something to make it larger or smaller are very intuitive actions. Because they feel like you’re interacting directly with the content. Use that. Again, we talk far more about this in another lesson, but it’s worth mentioning here as well. By loading these things into your short-term memory several times, we hope to help solidify them in your long-term memory. And that relationship is actually something we also talk about elsewhere in this unit.

Question 26

Seven questions for bridging gulfs (Norman)

Answer 26

1. How easily can one determine the function of the device?
   2. How easily can one tell what actions are possible?
   3. How easily can one determine the mapping from intention to physical movement?
   4. How easily can one actually perform physical movement?
   5. How easily can one tell what state the system is in?
   6. How easily can one tell if the system is in the desired state?
   7. How easily can one determine the mapping from system state to interpretation?

Question 27

User-centered design

Answer 27

design that considers the needs of the user throughout the entire design process

Question 28

ISO standards - principles of user-centered design

Answer 28

1. Design is based upon explicit understanding of users, tasks and environments
   2. Users are involved throughout design and development
   3. Design is driven and refined by user centered evaluation
   4. Process is iterative
   5. Design addresses the whole user experience
   6. Design team includes multi-disciplinary skills and perspectives

Question 29

Types of stakeholders

Answer 29

• The user themselves is what we call the primary stakeholder. They’re the person who uses our tool directly.
  
  • Secondary stakeholders are people who don’t use our system directly, but who might interact with the output of it in some way.
  • Tertiary stakeholders are people who never interact with the tool or even interact with it’s output, but who are nonetheless impacted by the existence of the tool.

Question 30

4-phase design life cycle

Answer 30

(it’s pretty general and subsumes many other life cycles)

    1. Needfinding: In Needfinding, we gather a comprehensive understanding of the task the users are trying to perform. That includes who the user is, what the context of the task is, why they're doing the task, and any other information related to what we're designing. 
    2. Develop multiple design alternatives. These are very early ideas on the different ways to approach the task. It's important to develop multiple alternatives to avoid getting stuck in one idea too soon.
    3. Prototyping. We take the ideas with the most potential and we build them into prototypes that we can then actually put in front of a user. Early on we might do this in very low fidelity ways like with a paper and pencil, or even just verbally describing our ideas. But as we go on we refine and improve.
    4. Most importantly, we perform user evaluation. We take our ideas that we prototyped and put them in front of actual users. We get their feedback, what they like and what they don't like, what works and what doesn't work, and then the cycle begins anew. The feedback we gain from the users, as well as our experience with these prototypes and design alternatives, improves our understanding of the problem. We now know new areas of the problem we might need to explore with some more need finding. Now we might have some new ideas for design alternatives, or some new ways of expanding the designs that we already have.

Question 31

Nominal data

Answer 31

• also referred to as categorical data. We observe the # of instances of different categories.
  * Single-nominal vs multi-nominal: can a person be in more than one category at the same time?
  * Binary vs non-binary: 2 options vs more than 2 options. Important to know because the statistical tests we do with binary data are different.

Question 32

Ordinal data

Answer 32

• similar to nominal but there is some explicit ordering to the categories.
  * Ordinal can also be multi-ordinal, but Dr. Joyner hasn’t seen a compelling example of it.
  * Also as binary and non-binary, just like nominal data. In the binary example, we interpret an implicit ordering between fail and pass.

Question 33

Interval data

Answer 33

• data: we do know the exact difference between values (unlike in ordinal data)
  * We know the intervals between the numbers, but we don’t know their ratios. E.g., 8AM is 4 hours later than 4AM, but it’s not “twice as late”.
  * Dr. Joyner says interval data use is relatively rare.
  * Tests used for interval and ratio usually the same. Same goes for nominal and ordinal data.
  * In Interval and Ratio, there’s also a distinction between discrete and continuous
  * Discrete means something countable (how long is your average commute in minutes?) with a whole number. Not expecting something like 15.257 minutes.
  * Continuous: (sensors in people’s cars timing how long their commute is) This distinction, just like binary/non-binary, sometimes informs the statistical tests we perform on the data.

Question 34

Ratio data

Answer 34

• just like interval data, except it has a 0-point.

* We know that a commute of 30 minutes is twice as long as a commute of 15

Question 35

types of qualitative data

Answer 35

usually much more closely integrated with the way in which they were generated

• Transcripts
• Field notes
• Artifacts: reviews left from interfaces or the existing interfaces themselves
• Etc.

Question 36

Qualitative data is…

Answer 36

• strong because it paints a richer picture, but with that strength comes costs:
  * More expensive to analyze
  * More prone to interpretation biases
  * Therefore, we often code it to quantitative data

Question 37

Coding

Answer 37

• process of taking free-form qualitative data, and boiling it down into numeric categories. Typically these categories are nominal, which allows us to do whatever statistical tests we’d normally do on nominal quantitative data.
  * During this process, we lose some of that rich data, but we gain a numeric representation we can use in new ways. Plus, we don’t really lose our rich data, it’s just not part of the output, so we can go back and look at it if we need to.
  * The other thing that comes out of this process is a documented methodology for coding the qual to quant data, allowing us to argue that our interpretations aren’t biased, but actually rigorous analyses.

Question 38

Data inventory

Answer 38

• Before we start our need-finding exercises, we also want to enter with some understanding of the data we want to gather.
  
  • These are the questions we ultimately want to answer. That’s not to say we should be answering them every step of the way, but rather, we want to gather the data necessary to come to a conclusion at the end. Now, there are lots of inventories of the types of data you could gather, but here’s one useful list:
    
    1. Who are the users? What are their ages, genders, levels of expertise?
    2. Where are the users? What is there environment?
    3. What is the context of the task? What else is competing for users’ attention?
    4. What are their goals? What are they trying to accomplish?
    5. Right now, what do they need? What are the physical objects? What information do they need? What collaborators do they need?
    6. What are their tasks? What are they doing physically, cognitively, socially? And seven, what are the subtasks? How do they accomplish those subtasks? When you’re designing your need finding methods, each thing you do should match up with one or more of these questions.

Question 39

Problem space

Answer 39

• Where is the task occurring, what else is going on, what are the user’s explicit and implicit needs?

Question 40

5 biases and how to avoid them in Needfinding

Answer 40

1. Confirmation bias is the phenomenon where we see what we want to see. We enter with some preconceived ideas of what we’ll see, and we only notice the things that confirm our prior beliefs. Try to avoid this by specifically looking for signs that you’re wrong, by testing your beliefs empirically, and by involving multiple individuals in the need finding process.
   2. Observer bias, when we’re interacting directly with users, we may subconsciously bias them. It might be more helpful, for example, with users using the interface that we designed compared to the ones that other people designed. On surveys, we might accidentally phrase questions in a way that elicits the answers that we want to hear. Try to avoid this by separating experimenters with motives from the participants. By heavily scripting interactions with users, and by having someone else review your interview scripts and your surveys for leading questions.
   3. Social desirability bias, people tend to be nice. People want to help. If you’re testing an interface and the participants know that you’re the designer of the interface, they’ll want to say something nice about it to make you happy. But that gets in the way of getting good data. Try to avoid this by hiding what the socially desirable response is by conducting more naturalistic observations and by recording objective data.
   4. Voluntary response bias, studies have shown that people with stronger opinions are more likely to respond to optional surveys. You can see this often in online store reviews. The most common responses are often fives and ones. For us, that means if we perform quantitative analysis on surveys, we risk over sampling the more extreme views. Avoid this by limiting how much of the survey content is shown to users before they begin the survey and by confirming any conclusions with other methods.
   5. Recall bias, studies have also shown that people aren’t always very good at recalling what they did, what they thought, or how they felt during an activity they completed in the past. That can lead to misleading and incorrect data. Try to avoid this by setting tasks in contexts by having users think out loud during activities or conducting interviews during the activity itself.

Question 41

5 tips for naturalistic observation

Answer 41

1. Take notes. Don’t just sit around watching for a while. Be prepared to get a targeted information and observations about what you see.
   2. Start specific and then abstract. Write down the individual little actions you see people doing before trying to interpret or summarize them. If you jump to summarizing too soon, you risk tunnel vision.
   3. Spread out your sessions. Rather than sitting somewhere for two hours one day and then moving on, try to observe in shorter 10 to 15 minute sessions, several times. You may find interesting different information, and your growing understanding and reflection on past exercises will inform your future sessions.
   4. Find a partner. Observe together with someone else. Take your own notes and then compare them later so you can see if you all interpreted the same scenarios or actions in the same way.
   5. Look for questions. Naturalistic observations should inform the questions you decide to ask participants in more targeted need-finding exercises. You don’t need to have all the answers based on observation alone. What you need is questions to investigate further.

Question 42

Participant Observation

Answer 42

experience a task for ourselves

ow we do have to be careful here though. Remember you are not your user. When you’re working as a participant observer, you can avail useful insights, but you shouldn’t over represent your own experiences. You should use this experience as a participant observer to inform what you ask users going forward.

Question 43

Hacks and Workarounds

Answer 43

• We need to get inside users heads a little more to understand what they’re thinking and doing. If you’re trying to design interfaces to make existing tasks easier, one way to research that is to look at the hacks that users presently employ.
  
  • How do they use interfaces in non-intended ways to accomplish tasks or how do they break out of the interface to accomplish a task that could have been accomplished with an interface?

Question 44

5 tips for interviews

Answer 44

Interviews and focus groups can be very helpful

    1. Focus on the six W's when you're writing your questions. Who. What. Where. When. Why and hoW. Try to avoid questions that lend themselves to one world or only yes or no answers, those are better gathered via surveys. Use your interview questions to ask open-ended, semi-structured questions. 
    2. Be aware of bias. Look at how you're phrasing your questions and interactions, and make sure you're not predisposing the participant to certain views. If you only smile when they say what you want them to say, for example you risk biasing them to agree with you. 
    3. Listen. Many novice interviewers get caught up in having a conversation with a participant rather than gathering data from the participant. Make sure the participant is doing the vast majority of the talking. And don't reveal anything that might predispose them to agree with you. 
    4. Organize the interview. Make sure to have an introduction phase. Some lighter questions to build trust and a summary at the end so the user understands the purpose of the questions. Be ready to push the interview forward or pull it back on track. 
    5. Practice. Practice your questions on friends, family, or research partners in advance. Rehearse the entire interview, gathering subjects is tough so when you actually have them you want to make sure to get the most out of them.

Question 45

Think-aloud

Answer 45

• Think-aloud protocols are similar to interviews in that we’re asking users to talk about their perceptions of the task. But with think-aloud, we’re asking them to actually do so in the context of the task. So instead of bringing Morgan in to answer some questions about listening to audiobooks while exercising, I’ll ask her to actually think out loud while listening to audiobooks and exercising. If this was a different task like something on a computer, I could have her just come into my lab and work on it. But since this is out in the world, what I might just do is give her a voice recorder to record her thoughts while she’s out running and listening. Now think aloud is very useful, because it can help us get at users thoughts that they forget when they are no longer engaged in the task.
  
  • But it’s also a bit dangerous by asking people to think aloud about their task, we encourage them to think about it more deliberately and that can change the way they actually act.
  • So while it’s useful to get an understanding of what they are thinking, we should check to see if there are places where what they do differs when thinking out loud about it.
  • We can do that with what’s called a post-event protocol, which is largely the same, except we wait to get the user’s thoughts until immediately after the activity. That way, the activity is still fresh in their minds, but the act of thinking about it shouldn’t affect their performance quite as much.

Question 46

5 tips for surveys

Answer 46

1. Less is more. The biggest mistake that I see novice survey designers make is to ask way too much. That affects the response rate and the reliability of the data. Ask the minimum number of questions necessary to get the data that you need and only ask questions that you know that you’ll use.
   2. Be aware of bias. Look at how you’re phrasing the questions. Are there positive or negative connotations? Are participants implicitly pressured to answer one way or the other?
   3. Tie them to the inventory. Make sure every question on your survey connects to some of the data that you want to gather. Start with the goals of the survey and then write the questions from there.
   4. Test it out. Before sending it to real participants, have your co-workers or colleagues test out your survey. Pretend they’re real users and see if you would get the data you need from their responses.
   5. Iterate. Survey design is like interface design, test out your survey, see what works and what doesn’t and revise it accordingly. Give participants a chance to give feedback on the survey itself, so that you can improve it for future iterations.

Question 47

How to write GOOD surveys

Answer 47

Be clear, concise, specific, expressive, unbiased, usable

Question 48

At the end of needfinding, we have requirements for guarding:

Answer 48

• functionality, what the interface can actually do,
  * usability, how certain user interactions must work,
  * learnability, how fast the user can start to use the interface, and
  * accessibility, who can use the interface.
  * We might also have some that are generated by external project requirements, like:
  * compatibility, what devices the interface can run on,
  * compliance, how the interface protects user privacy,
  * cost, how much the final tool can actually cost, and so on.

Question 49

Direct manipulation

Answer 49

the principle that the user should feel as much as possible like they’re directly controlling the object of their task.

Question 50

Invisible interfaces

Answer 50

• Whether through using direct manipulation, through innovative approaches to shrinking these gulfs or through the user’s patience and learning, our ultimate goal is for the interface between the user and the task to become invisible.
  
  • What this means is that even though there is an interface in the middle, the user spends no time thinking about it. Instead, they feel like they’re interacting directly with the task rather than with some interface.

Question 51

Invisible interfaces: good vs. bad

Answer 51

• Good design:
  * Interfaces that are metaphorically invisible.
  
  • Bad design:
    
    • Interfaces that are literally invisible. Well, kind of, just your base interfaces are in one sense literally invisible. That’s actually why it’s so important to give great feedback. Because otherwise, it’s tough to gauge the success of a gesture interaction.

Question 52

5 steps for designing invisible interfaces

Answer 52

1. Use affordances. We talk more about affordances when we discuss design principles and heuristics. But affordances are places where the visual design of the interface is just how it’s supposed to be used. Buttons are for pressing. Dials are for turning. Switches are for flicking. Use these expectations to make your interface more usable.
   2. Know your user. Invisibility means different things to different people. Invisibility to a novice means the interactions are all natural. But invisibility to an expert means maximizing efficiency. Know for whom you’re trying to design.
   3. Differentiate your user. Maybe you’re designing something for both novices and experts. If that’s the case, provide multiple ways of accomplishing tasks. For example, having copy and paste under the Edit menu keeps those options discoverable. But providing Ctrl C and Ctrl V as shortcuts keep those actions efficient.
   4. Let your interface teach. When we think of teaching users how to use our software we usually think of tutorials or manuals. But ideally the interface itself will do the teaching. For example, when users select Copy and Paste from the Edit menu, they see the hotkey that corresponds to that function. The goal is to teach them a more efficient way of performing the actions without requiring them to already know that in order to do their work.
   5. Talk to your user. We’ll say this over and over again, but the best thing you can do is talk to the user. Ask them what they’re thinking while they use an interface. Note especially whether they’re talking about the task or the interface. If they’re talking about the interface, then it’s pretty visible.

Question 53

Memory/cognition terms to know

Answer 53

Chunking
Recognition vs. Recall
Cognitive load

Chunking = grouping together several bits of information into one chunk to remember

Question 54

2 kinds of learning

Answer 54

• Procedural is how to do something. That can be doing work on a computer, playing sports, playing a musical instrument. It’s a task in which you’re engaged or an activity you are performing, it’s something that you do.
  * Declarative learning is knowledge about something. It’s what you know in your head. It’s what you can answer when asked. So if I asked you, what’s the hotkey for paste? I’m asking for a declarative knowledge.

Question 55

5 tips for reducing cognitive load

Answer 55

1. Use multiple modalities. Most often, that’s going to be both visual and verbal. But when only one system is engaged, it’s natural for it to become overloaded while the other one becomes bored. So describe things verbally and also present them visually.
   2. Let the modalities complement each other. Some people will take that first tip and use it as justification to present different content on the two modalities. That actually increases cognitive load because the user has to try to process two things at once, as you just noticed when Amanda put something irrelevant up while I said that. Instead, focus on letting each modality support, illustrate or explain the other, instead of competing with the other.
   3. Give the user control of the pace. That’s more pertinent in educational applications of cognitive load, but oftentimes interfaces have built-in timers on things like menus disappearing or selections needing to be made. That dictates the pace, induces stress, and it raises cognitive load. Instead, let the user control the pace.
   4. Emphasize essential content and minimize clutter. The principal of discoverability says we want the user to be able to find the functions available to them, but that could also raise cognitive load if we just give users a list of 500 different options. To alleviate that, we can design our interfaces in a way that emphasizes the most common actions, while still giving access to the full range of possible options.
   5. Offload tasks. Look closely at what the user has to do or remember at every stage of the interface’s operation. And ask if you can offload part of that task on to the interface.
   * For example, if a user needs to remember something that they entered on a previous screen, show them what they entered. If there’s a task they need to do manually, see if you can trigger it automatically.