数据分析--Data Visualization.zip

[MUSIC] So now we understand information visualization. We can start to think of how we would design an information visualization system. So when creating a visualization system, you're really creating a user interface. It's an interface between the user and the data facilitated by a computer. And so data visualization systems are really graphical user interfaces. You're using the computer to graphically represent the data. So principles from user interface design are important in constructing a good, effective visualization system. You already have an understanding of the system, of how the graphics works in the system, and how we display data with the system. You have a good understanding of how users work based on what we covered in Module 1 of this course. We'll also need to focus on the goals. What does the user hope to achieve, and the tasks that they'll be performing to achieve those goals. And also the interaction. We'll need to be able to represent and understand the interaction of the user and the system, and, for example, describe a dialogue, a language of clicks and selections, and so on, so that the users can perform tasks in a way that's intuitive and productive. So we'll follow some standard sequences of forming a system design. Designing a visualization system is similar to designing a software system or other systems in general. We start with a basic requirement specification. And that's basically going to try to figure out what specific problems the system is going to solve. Who's the system going to serve? And how will that person be able to make a decision based on your visualization system? This involves a lot of discussions with the user. I see focus groups used for this, but it's important that the focus groups and interviews with the user aren't asking the user specifically what kind of interface or what kind of visualization system they want, because you're going to be the expert of the visualization system. Often the users don't know what's out there, what's available, what will serve them best, and so you want to focus on what questions they want to answer with the system and how can you get that information to them so that they'll have everything they need to answer those questions. Then there's an architectural design, and this is breaking the full system down into component systems. If you're making a visualization dashboard, then these would be the individual elements of that dashboard. And then there's a component design that you're going to figure out how to implement each of those elements. And then you go through a step of actually implementing, actually coding or setting up the system for each of these components. Then you do some debugging to test each of the components. And then an important step is user evaluation. Once you have these components, you'll want to make sure and test them with users to make sure they're doing want they're supposed to be doing, that the user is using them the way that you intended to use them. And also to use some statistics to make sure that you're not just basing your evaluation on anecdotal evidence, but that the user is actually using the system effectively. And then finally maintenance documentations for the system and fixing. It's easy to underestimate this process, and when people make estimates of how long it will take to implement such systems they, focus on implementation, and you'll see implementation is maybe one of seven steps here. And that's why we say when we're designing software systems or user interfaces or visualization systems, you want to take the amount of time you think it should take, and then you want to double it. And by doubling it, you're then realizing that you're going to have to be doing debugging and some component design. And then you want to double it again, because you also need to do the analysis and the requirements specification and the evaluation and the maintenance. And so, if we tend to underestimate by just looking at implementation, it really takes six to eight times as long to actually create a system when you're doing it right. Some other advice when making these systems is to use prototypes. We talk about user evaluation here at the end, but you should be doing user evaluations and user testings at every stage of this, checking with the user in some form or another, either with a model of the user or with the actual user. And so you want to use prototypes to simulate how the system might work when you're doing a requirement specification and then move to an architectural design. For the architectural design, you might want to have a mockup of a possible interface and put that in front of the user to determine that that meets the requirements that the system needs to provide. Or, you may even have a Wizard of Oz system where you simulate the system without it actually working the way it's supposed to on a very specific case. You can hard-code a system to work and you can see as you're doing component design if that was in a biosystem, that simulation of the system that you designed is going to satisfy it before you actually invest the time in implementing the system. You don't always have to go back to the user to get these answers. Often, especially as you're working on the design stages of the system, that you can use models of the task and dialog. So the user model, based on the requirement specification you'll have an idea of what goals the user will want to solve. And you can start decomposing tasks and creating task analyses that go into the layout of components that can make sure that they meet the requirements as specified. And finally, as I mentioned before, don't wait until the very end to do this component testing. You'll want to test each of these if you've created a good model of the user, and the dialog, and the tasks, and so on. You can start to do some testing of your design before you've invested in the implementation time. So for user modeling, there's a variety of different techniques for modeling users. You want to focus on what the user needs to answer a question. You want to provide a visualization that will help the user answer a question, and you don't necessarily want to create the fanciest visualization or use every facility that's available on the computer system. You want to try to get into the head of the user. Try to look at the system from the user's point of view instead of, for example, the programmer's point of view, or a system designer's point of view. And you want to know your user. What's the user familiar with? What other tools are they using? What's the user's role among other users, or among other people in their organization? What might the user know, and what might the user not understand? And then finally, what's the users motivation in using the system? How can you best provide the information in a way that the user will want to use the system and know what to do to properly use the system? Finally, it's good to do a cognitive walkthrough, put yourself in the head of the user and map out, write out in diagrams what should be on the mind of the user as they're using your visualization system, so that you can better present data based on what the user is currently focusing on. And so there's a variety of user modelling techniques, one of them is an old one, it's called GOMS. It stands for goals, operators, methods, and selections, and it helps you to understand what a user might be thinking of. Users are going to be goal-oriented, and so it's good to map out the goals for the system. It's also good to think of the operators as you're designing the system. What are the operations, the basic user actions that the user's going to be using to achieve the goals? And the user's going to be forming methods by stringing together these operations, and there may be multiple methods of achieving a goal. Which ones are you going to support, try to support as many of them, there's more than one way to skin a