A3+FAQs


 * [[image:Faqs.jpg]]

Type in any FAQ's about the //third// assignment here.**


 * //Question// || //Answer// ||
 * 1. What does PACT stand for? || PACT = People, Activities, Contexts, Technology. ||
 * 2. In part 3 of the proposal instructions we're told to add "documentation" and "inspirations". What are those? || These are any sources that are helpful as you explore your topic.... really anything of interest that you come across or develop. For example, if your team is concerning with signage in the airport, then it may be worthwhile to take some photos of airport signs, signs in other places, interesting icons or [|wayfinding] approaches to generate ideas. Along with this, annotate your research with description and reason for inclusion so you can build an ongoing diary of research. Think of it as a scrapbook of things (could be articles, websites, sounds, images, or whatever) in order to document your gathering of ideas and serve as inspiration to advance your design concept. ||
 * 3.Does the Proposal have to be in full sentences or is point form okay? || Pretty much any form of representation is fine. The goal here is to outline a research project and document your early thought processes around the effort. If point form seems best to make your point, use it. If full sentences help clear things up, great. If visual models, photos, videos, etc. help, super. ||
 * 4.When it comes to group's roles, should we use group terms (project facilitator, editor ..) or more business oriented terms (IT manager, web designer)? || What roles you pick are entirely up to you. Feel free to be creative - although in the end, it's probably best that the roles mean something, even if their names might not be all that obvious or serious. ||
 * 5.Do we have to have set roles? What if we just do things as necessary and split the work the best we can? || Having a set of roles (titles) is a way tp divide the work eaisly and equally. When you assign members tass, those are considered roles as well, even if you do not have titles. That said, you do not have to have titles for roles, but project tasks will probably be assigned to different members, which is synonymous to having a role (just without a title). ||
 * 6. Any examples of user study methods? || Some useful notes taken from tutorial and also further information is available in the textbook. ||
 * 7.What is an example of a scenario? Is it an actual story of a person interacting with the machine and what types of concerns that person may have? || Generally, yes. It takes information from your user studies and builds a story about a typical user in a typical usage context. The scenario should be about the technology //as it presently exists// - in other words, it does not yet include any information about redesign. From these stories, you note what types of requirements are important and what requirements are not yet being met by the present technology - that's where your focus your efforts in redesign. It's really helpful to use your survey's or questionnaires when creating scenarios to incorporate current frustrations, lack of affordances etc. in the current design that most people encounter regularly. interviewing people who use your technology would be key to writing your scenario-- this will then help you fulfill the requirements later on in the process. ||
 * 8.Are we only suppose to list requirements or do we have to list and explain why we put them there? I am askin because in explaining requirements, we would be repeating the problems written in the Scenerio section || It's less repeating things than deriving requirements from the scenarios. There's overlap to be sure, but that's by design - the user studies inform the scenarios, which in turn inform a list of requirements. The requirements list is where you start talking about what you're going to be fixing, so it is conceptually different - it's less a story about problems and more a beginning to a solution. So, scenarios and requirements are related, yes, but play two complementary roles. ||
 * 9. What are the 'final deliverables' required for the design concept? It looks like they are missing or were never added. || When you check the history of Assignment 3, you would notice that it's updated about once a week. This implies that the Professors are adding things to it as we go through the course. Thus, the "final deliverables" for the design concept are not up yet; however, they should be posted soon. **NOTE:** The final deliverables are now posted. They include the Display Poster (5%) and Documentation Wiki (5%). **Note 2**: These bits were there for a while - since Oct. 3 at my reading of the history. The final deliverable is the redesign itself, which we've been aiming towards since the beginning of the project, including the poster/presentation and documentation to sell the concept and back it up. ||
 * 10. Any comments on how we should design our posters, or have you left it on us on what we can include? Any suggestions? || According to the TAs from this weeks lab session the posters should include the actual redesign as well as the process towards that final design. Also, it should not have large amounts of text but small chunks that can be easily read. Pictures, diagrams, graphs and other visuals can be used. The whole presentation should only last 1-2 minutes and groups should have planned what to say before hand (cue cards, script, memorized, practiced). Some have asked whether a prototype or brochure or something else could compensate for a poster. It might make the poster simpler, but something representing the process as well as the final result will help - if you can do both without a poster but through some other means of expression, it should work, but probably best to check with Mike or David first. ||
 * 11. What's the documentation wiki all about? Do we have to do anything more than what we've done? || It is the wiki you've been using throughout to organize project details. It should conclude with some information on your final redesign effort, esp. anything that doesn't necessarily fit the poster/presentation (e.g., figures, sources, explanations, alternative prototypes, etc.) Otherwise, it represents progress from start to finish and should itself be intuitive enough to follow for those who wish to get more information about your project and how it came to be. If you've been active in maintaining this documentation throughout and do the same with respect to your final deliverable, it's probably the least of your worries. If the organization and content of it has improved appreciably through the process, that's great too. ||
 * 12. For the requirements part, what exactly is meant by the Moscow rule? || The MoSCoW rules refer to the concept of prioritizing requirements since most projects have limited resource, and therefore we must choose some redesigning ideas over others. In the textbook, it follows: Must Have - fundamental requirements, without which the system will be unworkable and useless, effectively the minimum usable subset. Should have - would be essential if more time were available, but the system will be useful and usable without them. Could have- of lesser importance, therefore can more easily be left out of the current development. Want to have but won't have this time around, can wait until a later development. ||