Design Process and Support Tools

From CS2610 Fall 2014
Jump to: navigation, search

Contents

Slides

slides

Readings

Readings Critiques

Wenchen Wang 19:15:59 10/4/2014

<Reflective Physical Prototyping through Integrated Design, Test and Analysis> <Summary> This paper introduces a new tool, dtool, which helps designers to prototype appliance through design, test and analysis approach. It is a very useful tool with three contributions. <Paper Review> Designing prototype is tedious but necessary. The motivation of dtool is to provide a tool for designers to facilitate the process of designing prototype in three ways. Firstly, dtool provide a set of interaction interface by introducing a visual, statechart-based prototyping model. Design can have visual-only input and output components by dragging and dropping from the interface. Secondly, Hadoop provides a more flexible extensive hardware architecture for physical interfaces. Designers are able to plug in some external physical hardware, such as chips and make the design more flexible and convenient. Thirdly, dtool integrates design, test and analysis together. To be specific, dtool will record the users’ behavior when volunteers are doing test in dtool, so that designers could review the video and get what functions could make user confused and make an enhancement. <Where Do Web Sites Come From? Capturing and Interacting with Design History> <Summary> This paper introduces an informal history capturing system for early-stage information design <Paper Review> The system provides design history by main timeline, local timeline and synopsis view. For main timeline, users could view the history of the entire design process. Due to some undo/redo, the entire history is represented by branched time visualization. In this way, designers could have a whole picture of their design process without missing any undo operations. For local timeline, designers could have a view of one object design process, which could help designers improve a certain part of the web design. For synopsis view, bookmarker could be generated by two ways. First is manually created a bookmarker by designers. Second is system will automatically created a bookmarker every 12 actions. Synopsis is kind of some important notes to be viewed for future, which is a very significant function for designers. For me, I think this kind of informal history system is very useful for my current research project. We are designing a supervisory control system. We usually stick a lot of stickers on the white board in a conference room for our design, which is very inconvenience and ineffective. We will easily forget our previous thoughts without recording the history of the design. So I think this kind of system is very useful for many kinds of designing besides web site design.

nro5 (Nathan Ong) 1:02:13 10/5/2014

Review of "Where Do Web Sites Come From?: Capturing and Interacting with Design History" by Scott Klemmer, Michael Thomsen, Ethan Phelps-Goodman, Robert Lee, and James Landay The authors present a system of augmented collaboration, the Designers' Outpost, similar to the Digital Desk, but on a vertical wall surface instead. Participants of their user study wrote on sticky notes, which then were placed onto the wall, where a camera would record the note that was placed and other context-based information at the time of placement. The system also provided a historical timeline to show where objects were placed by whom and at what time with what content; providing different styles of timelines for those who want to see a filtered history. I found the title to be misleading. I assumed the paper was going to be a survey on the literature of interface design for websites, which I may have preferred at the time when I read the title. Regardless, the paper exposed some of the challenges associated with gathering context-aware information. There are so many ways to use this data, but even limiting their scope to editing history, the authors realized that the data could ultimately cause confusion. Their timeline editing history scheme allowed users to filter different snapshots in time by the person who posted it, the meeting it was posted in, etc., and the authors mentioned that navigating through this timeline would have been difficult in a naive implementation. For example, their initial editing history provided a tree-like structure on their timeline, which ultimately became very complex, especially near the leaves. Their second version may have looked a little cleaner, but it still seems that it may become too complex after the addition of multiple branches inside stubs. While a very similar concept to the Digital Desk, it seems the main contribution of this paper is the timeline viewing of previous edits. Their attempt to recreate a more useful editing timeline through the use of context-aware data is commendable, but based on the current implementation, it seems a lot more work needs to be done before a non-linear edit history will be useful. The problem with making an edit history be branched is that the level of complexity increases greatly over a linear timeline. The second problem is that there needs to be a way to summarize the edit, but currently there is no way to do so. The authors attempted to show this via a mini-size version of the board, lacking the content of the sticky notes, but showing their approximate position on a smaller map. This may be useful for short-term retrievals, but I find it not helpful at all to quickly finding information in a particular point in the edit history. It seems maybe there is not a good way to represent so much data in such a succinct way. Review of "Reflective Physical Prototyping through Integrated Design, Test, and Analysis" by Björn Hartmann, Scott Klemmer, Michael Bernstein, Leith Abdulla, Brandon Burr, Avi Robinson-Mosher, and Jennifer Gee This paper provides a toolkit to enable rapid prototyping of "information appliances" in the context of helping others to quickly develop devices for ubiquitous computing. The way they provide this is including a prototyping board and attachable modules and sensors, while simultaneously providing a software system that they claim has a low threshold to use for most simple devices, but also including a high ceiling by the use of a programming language they provide. I have always been skeptical of programs that use a tile-based programming language as a method for lowering the threshold. While it is true that they indeed lower the threshold of programming languages (e.g. Alice or Lego Mindstorms), I have larger doubts that if we asked all students to engage in these lower threshold programming languages that they would go on to pursue further studies in programming, let alone computer science. In my experience, students and society alike tend to dismiss tile-based programming as both only a hobby and a language that is unable to fully express their desires for more complex ideas. In a sense, it is true; the ceiling is low for a tile-based programming language, so it is usually supplemented by a character-based programming language. I believe more in the idea that a programming language should become closer to natural English. While the English language (and most other human languages) has the tendency to be ambiguous, especially without context, I do not expect nor ask programming languages be equivalent to a human language. However, I do believe that if we are able to make commands become English-like, then not only will the threshold be lower, but the ceiling should also be as high as any other high-level language. The paper's contribution, however, is not on the hardware, or the language, but instead it focuses more on the seamless capture and analysis of the prototyping system. Generally, in order to test any system, it would involve a difficult and time-consuming process, especially since users need to be hired to test the system. However, with the d.tools toolkit, users can test the system, and a quick analysis can be done on video and sensor data in a timeline. This is extremely important for rapid prototyping in order for developers and designers to understand how their appliance may be used and how frequently certain features may be used. This data can guide them to develop a better product, and allows them to develop quickly and efficiently.

Phuong Pham 22:23:03 10/5/2014

Reflective physical prototyping through integrated design, test and analysis: the paper introduces d-type, a prototyping tool for iterative physical designing. This can be considered as a human-centered designing toolkit because it supports fast prototyping. The most interesting point of this paper is the toolkit was built from many existing technology. The authors used Eclipse as a framework for state-chart based programming, a small plug-n-play board to retrieve multiple types of input. d.tools gives me a feeling of the UNO board for HW2 in this course. Obviously, the tool is very helpful for fast prototyping a device getting certain inputs and produces some outputs determined by a state-based chart programming which is more friendly for non-programmers than textual programming environment. However, there are more rooms for improvement of d.tools that I can imagine: the state-chart based programming can be considered as a pre-built library that designers can quickly use. However, the expressing power of the library is domain-depend and would need extra labor for new domain. The hardware board can help in the very first phase of the project where designers only test input, output transition. If a device benefits from an innovated physical design, designers still need to build the device from scratch. Last but not least, I wonder if the evaluating with video is a framework or a real automatic function. Because recording may require flexible in recording angle, duration, environment, etc and the video annotation is labor consuming. However, there would be certain cases where we can facilitate the evaluation process by automatic or semi-automatic annotate the video. ***Where do web sites come from? Capturing and interacting with design history: this paper presents an iterative process for building a human-centered system. The authors have asked different group of end users giving feedback for the system from the initial state (identifying the problem) to early prototypes and evaluating the final model. It is interesting that end users can point out problems of early prototypes which guide the development team to make a final model that really helpful for target users. However, there are some points that I concerned about the paper. First, the evaluation seems to be taken informal. We know the contribution of the project is obvious that facilitating group colloborative work. However, I wonder if the system can handle multi-user actions at the same time, e.g. 2 users move 2 posts or 1 add a new post while the other move another post. That would be very important for a colloborative working environment. Furthermore, there is a big gap between physical world and digital world when undoing, the physical board cannot be automatically undo. We know that this problem could be solved with nowaday technique, e.g. large touch screen where end users work completely digital. However, I think it would be interesting and more helpful if the authors share some of their thoughts about how to solve this problem given technology at that time.

Bhavin Modi 13:23:24 10/6/2014

Reading Critique on Where Do Web Sites Come From? Capturing and Interacting With Design History The paper demonstrates an implementation of a history interface built as an extension to the existing Designers’ Output, a tool that supports informative web design. The aim for creating this history mechanism was to create an informal and more natural method for designing web sites, and assists in brainstorming and managing of ideas and versions easily without putting too much load on the users. The three main features of design history are the inclusion of the global timeline, the local timeline and the synopsis view. The filtering options by actions, commands, and bookmarks are features and guide the view of the timeline. The working of the history implementation closely resembles that of smart boards and others methods shown and discussed in previous papers, The digital desk and ubiquitous computing, both written Xerox researchers. The implementation uses capture of post-its can converts them to an electronic format, saving them as thumbnails. Changes can be made to a current state or node by using annotations, links, or adding and removing some node. The interesting thing to note is the use of physical interfaces in combination, like the knob to go through the thumbnails, makes it more natural and does not expect the user to get up every time to access the board. This explains the concept that everything is good something. The work is designed such that one can view the history of design work carried out, and go back and try new approaches, while at the same time not losing and getting confused by the work previously carried out. For that purpose they have a new system to show and remember branching history and sequence contained within another, expandable on request. The various feature implementations are shown clearly, which helps to understand the system. The system is tested by professionals and some problems that emerged where loss of calmness, due to presence of many branches, and while using the View all filter. The result of which is now there is more scope for future works in the system. The feature of juxtaposition and comparison, creating collaborative systems for use of history across multiple offices and geographical locations. The author hopes that this implementation of a collaborative wall-scale design will inspire such use in other professional fields too. --------------------------------------------------------------------------------------------------------- Reading Critique on Reflective Physical Prototyping through Integrated Design, Test, and Analysis The paper introduction to a new design tool “d.tools” created for rapid design and prototyping, with an integrated testing and evaluation support. The tool was built for developing physical prototypes and testing them keeping in line with the iterative model. d.tools has been created learning from previous work in the field and the need for efficient design tools that have a low threshold. It is based on previous research on tools for prototyping and video evaluation and physical computing, the tools from which inspiration was taken are SUEDE, Phidgets, iStuff, and Maestro to name a few. The foremost advantage of d.tools was that it allowed a lot of flexibility by allowing three points of extension, hardware-PC, intra-hardware, and the circuit level, this was not offered by previous tools. The option to add libraries helped to raise the ceiling for complex tasks. The plug and draw model introduced a low threshold and the inbuilt libraries managed the rest, which can also be managed through Java Programming environment with the use of eclipse makes the programming easier. The presence of testing and evaluation techniques like video recording the user interaction while testing and showing state graphs to depict transitions and flow of control provides a good model for evaluation. The state graphs for designing makes designing more intuitive, and draws attention the design needs rather than being caught up in programing. The single user analysis methods of state-charts to video, vice-versa and the group analysis of multiple scenarios also make the tool more attractive for designing. The problems or shortcomings discussed were the absence of a flash utility, which is needed to create “shiny prototypes” for clients who want abstraction. The other was, no software simulation, hardware was needed to be attached. The third was managing sensor parameters, abstraction in the form of graphical ranges was used to resolve it. The major shortcomings was for complex systems, in which the visual design space was hard to understand, example the desk prototype mentioned. The previous paper also focused on creating new design tools and mechanisms and one could even integrate the two, to have the benefits of history on d.tools. The focus now shifts to creating a design space for developing interfaces, this is another field of HCI that has immense scope for research as mentioned in the future works of the paper.

Qiao Zhang 21:17:29 10/6/2014

Where Do Web Sites Come From? Capturing and Interacting with Design History This paper directly follows the previous paper of ubicomp. Their system is inspired by both work in design rationale and in capture and access applications. This paper is inspiring in the sense of how to assist users to do creative jobs. The authors have created a web site design system called Designers' Outpost that can deal with variations of designs and keep a track of the design history. They provide a main timeline view and an assistant Contour Design USB jog dial for direct physical interaction with the system. They provide hierarchical rather than linear history tracking as in most other applications. They also provide an innovative collapsed approach to display the history tree, to lift the burden of early stage design. An important lesson learnt from this article is that before the authors began any developing on Designers' Outpost, they conducted design and field study to learn from the actual end users. They captured the users' needs and carry out the corresponding designs. The authors also did user studies after implementing the system and analyzed the users in different scenarios. They also record users' favorite features and adjust the design (adding save functionality) according to users' needs. ================================ Reflective Physical Prototyping through Integrated Design, Test, and Analysis This paper presents d.tools, a toolkit that embodies an interactive-design-centered approach to prototyping information appliances. This toolkit provides a low threshold for early-stage prototyping, extensibility of hardware, and integrates design, test, and analysis of information appliances. The main concern d.tools is iteration. It frames a design challenge of working it through rather than just thinking it through. It provides three modes of design phase: design, test, and analysis. In design mode, d.tools offers an integrated environment of software design and hardware interface. In test mode, d.tools records a video of the user's interaction with the physical device and logs interaction events to structure the video. In analysis mode, it allows the designer to review the data from user test sessions. It can either analyze a single user or users as a group. The authors did a user study of thirteen people, which to me seems to be a small number. I was wondering how large a user study should be. Also, they improves their system by discovering shortcomings from the user studies. When I was reading the paper, I found the presented system d.tools is actually very mature and has great potential to be commercialize. Thus I googled d.tools, and I found that it is already an established company now. Although it seems to be changed from a hardware-based design tool to a pure software design tool.

Eric Gratta 22:11:04 10/6/2014

Where Do Web Sites Come From? Capturing and Interacting with Design History (2002) Scott R. Klemmer, Michael Thomsen, Ehtan Phelps-Goodman, Robert Lee, James A. Landay To have a meaningful understanding of a design in its current state, it is necessary to have an understanding of the process by which it evolved into that form. As a possible solution to this, the authors have created a new, collaborative web design system that maintains a history of all changes made to the design. Metadata on past design states allows for unique views of the history, both at different semantic time intervals and organized by different contexts. Techniques used for developing this system included building upon past research and doing user studies. An important method the researchers used to discuss their project was to explicitly cite and discuss all of the previous work that inspired the features of their current work. By doing this, they provided a detailed history of the origins of the ideas, much like their proposed system is intending to do. This makes it clear that the authors are building upon previous work and gives a context for their ideas. Not only did they consult past research, but they also consulted potential users of their system to figure out what issues might arise before doing any development – they interviewed many professional website designers. This research also involved user studies in multiple groups, and the authors made an effort to go into detail about the process by which the design adapted in reaction to user feedback. They described the modifications that occurred after each user group tested the system, and kept the discussion of the system focused on how it could map appropriately to designers’ common practices. A theme that appeared here that was familiar from our past papers on ubiquitous computing was the idea of minimizing interruption of the user’s workflow. Although in a sense helpful, the system’s automatic refreshing of the history after every action was distracting and intrusive to the users’ visual focus, and so many users reacted to that aspect of the interface. Possibly the most useful thing about this paper is that the discussion of designing an interface for interacting with history (in terms of the process of creation) was done in such a way as to be valuable for any domain, not just web design. By presenting detailed information about how the web designers worked and viewed the system, the authors provided context for others to try and understand how a historical interface might apply to some other domain of work that would benefit from an application that permitted historical state interactions. --------------------------------------------------------------- Reflective Physical Prototyping through Integrated Design, Test, and Analysis (2006) Björn Hartmann, Scott R. Klemmer, Michael Bernstein, Leith Abdulla, Brandon Burr, Avi Robinson-Mosher, Jennifer Gee This paper introduces a newly created “statechart-based visual design tool” called d.tools and elaborates on the value of prototyping in the design process and how software might support prototyping. The authors clearly state their methods for assessing the system in their abstract: a user study, researchers’ use of the software to do real work, observation of others using the system. Some points they emphasize are that design is a “thinking-by-doing” process that necessitates working with physical materials and going through multiple iterations of design. By observing the weaknesses of past work in this area, the researchers decisively made their system more flexible, offering extensibility at 3 different levels of hardware (hardware-to-PC, intra-hardware communication, and circuit) and at the software level (Java hooks). It seems like a very direct parent of the Arduino system we have been using for our homework assignment, but looking at the date reveals that this paper comes the year after Arduino. Interestingly, the paper claims, on page 6, to have contributed “Plug-and-Play” hardware. One key difference between d.tools and Arduino is that the circuitry is abstracted away from (by using common connectors) so that the designer does not need to spend much effort connecting components. The authors made an attempt to address the issue of accessibility to recorded history; d.tools records video of user interactions with the prototype but this information is only useful when designers can quickly find the relevant portions of the videos. This issue was reminiscent of the difficulties faced trying to interact with design histories in the other paper. Both teams used context, or implicit information about the physical/computational environment, to structure data visually for the designers. One lesson that the paper tries to get across about designing design systems is that designers are not programmers. Programming or other textual manipulation should be abstracted away from so that designers can keep their focus on the problem domain. This lesson can be applied to design for any other field – users should be able to directly manipulate objects at the level of their expertise.

Longhao Li 22:39:42 10/6/2014

Critique for Capturing and Interacting with Design History In general, this paper introduced a new system to keep design history that can give users an easy to use redo and undo functions. This system also support direct manipulating interface, which use people’s natural way of operation on board as input. To my understanding, the research result in this paper is important. It not only gives user an interface that can use computer in their natural way of operations on board, but also a great history managing system. Traditional way to manage history to achieve redo and undo function has its disadvantage. After undo, if the user edit the file, the user will not be able to redo what was undo before, by which means that the system don’t store the whole history. This new system did support the storing of the full history, and it gave user different ways to display the histories, which are showing main timeline, local timeline and synopsis views. Also users can do filtering by time, note and author etc. It gives user an easy way to look at the history in order to improve their development. This is important since it can help developers achieve a good result in a shorter time. Recently, there are some systems that have some similar history managing strategy in the market. One of them is GitHub. It is good at version control of software development. People can undo the changes and people can see the highlighted changes between different versions. Also it supports branches so that users can have multiple timelines for one software development. It is a great system to use, but it doesn’t have the direct manipulating interface mentioned in the paper so that it need to take some times of users to learn how to use it frequently. Critique for Reflective Physical Prototyping through Integrated Design, Test, Analysis This paper talked about a new prototyping system that support a lot of functions, which are very useful for developers to do iterative design cycles. It not only support software simulation, it even support real device simulation for testing. This is a great improvement for software engineering and interface design works. I do think it is important. In the origin, developers doing the test of prototypes only by paper based interfaces. Even though it is easy to do, but it is still different with real interfaces. There are not animations, no real feelings of operating on real interface so that the test can only be used for collecting general ideas about the interfaces. The final software may need a lot of test and changes. It talks a long time. By using this system, developers can save a lot of time, since they can do a lot of simulating test before they make the product real. Also the system support video recording of the simulation test, and it can combine the state change of the prototype and video together to give developers a good idea about users’ feeling about the software. This is very convenient for the iterative development since the analysis from system give developers very in depth understanding about the interface. This system is advanced, but it still has its problem. Even though it can do a great simulating works, it still need a lot of time to make the prototype since it looks closer to the real product. There are some prototyping systems introduced in the market at this time. Some of them make the prototyping work so complicated that developers need to take a lot of time on it. This is not good. Therefore, finding a balance point on how complicated the prototype should be needs to be determined for different software developing team. If they have a lot of time, a complicated prototype is a great point. If they don’t have big budget and don’t have a lot of time. Simple prototype will be a good idea.

Qihang Chen 22:48:07 10/6/2014

Reflective Physical Prototyping through Integrated Design, Test, and Analysis. This paper introduces a tool called d.tools. This tool aids designers in allowing them to easily test and analyze an interface by allowing them to iterate a design both physically, and virtually, and then alayze the results, as well as test, all in the same tool. There are three major parts to the d.tools application. The first is the building of a prototype. d.tools allows users to build both software based interfaces and the physical devices they reside on. Using a GUI to help the designer designate which action will lead to which result, and allowing designers with little to no programming experience to easily use the product, the authors reduced the threshold for using the tool. The main focus of the paper was in the making the product easier to use so that a designer could use it to help iterate their design, getting more prototypes in a shorter window. Throughout the design, they focused on the end user, and how they would interact. They followed the iterative design process, changing the end interface to include things such as flash and a java portion for visual display. The design of the tool itself ephesized the process that the tool wishes to aid in; the iterative design process. A second feature of d.tools was the testing feature. Instead of using a different tool to test, d.tools allows the designer to test in the same environment in which they build. Again, keeping the end user and their goals in mind, they provide a video for each testing session of the test subject and their interaction with the interface. As the subject progresses through the design process, the video would annotate and mark each interaction with the interface. This lets the designer see what the system was doing or which state it was in when the user was making an action. This also allowed the designer to look at many videos to analyze after many tests. Since the system is annotated throughout the video, the designer can go through and look at the video at each action, state, or time step. This allows the designer to connect where many users got wrong with what the system was doing as they made a mistake, or missed an easy way to do something. This kind of search and video review sets d.tools apart from its counterparts. Anther useful thing about this paper was its review and use of user studies and iterative design. The authors used many user studies, including a class in HCI at their university in order to test the design. Once the tests were concluded, they were able to make changes based on user feedback and evaluation on whether or not a goal was accomplished. d.tools embodied the iterative design process while attempting to aid others in using the iterative design process. <<Reflective Physical Prototyping through Integrated Design, Test, and Analysis>> This paper presents a toolkit for prototyping. Prototyping is a critical part of the whole HCI design, I think, since prototyping is to test the model in physical world, a shorter time to build the model is important. I really like the figure 2, which gives an overall view of the prototyping toolkit. I think this is similar to the interface of a hardware programming toolkit. Besides, this could be limited in units which are be programmed or to be able to connect to the physical units. A more complicated task, like how to make a cup, is too difficult to have a general design interface. Moreover, it simplifies the task to only key press or key release. Though we're now using more devices of multi-touch, click is still an important interation method.

Xiaoyu Ge 22:59:20 10/6/2014

Where Do Web Sites Come From? Capturing and Interacting with Design History Three visualization mechanisms are introduced in this paper: main timeline, local timeline and synopsis view. As for the timeline visualization, filtering thumbnails such as activity filter and inferred filter. A Timeline-navigation was also introduced in order to provide a direct manipulation interface for navigating the design history. Branch time visualization is also used to support multi-level undo/redo operation. The author also introduced a history system extended from a design tool Designers` Outpost. And the author also introduced the evaluation result by target user, professional designers. The author intended to introduced a user interface that can visualize the time and history on electronic devices which can make target users easy to access design details in different timeline which merge designer`s physical activity with the computer interface. I agree with the visualization concepts author introduced. This kind of product is very useful for designer since an organization of design with timeline highly increase the accessibility of design process. Reflective Physical Prototyping through Integrated Design, Test, and Analysis This paper introduced an iterative-design-centered prototyping UI tool d.tools to prototype physical UI. There are three advantage features. Firstly, d.tools is a set of interaction techniques and architectural features which provides a low threshold for early-stage prototyping model. Secondly, it offers hardware architecture for physical interfaces. Thirdly, it integrated design, test and analysis of information appliances. The author also introduced user study for the evaluation of the d.tools, and success and shortcomings of short of software simulation are discovered. The HCI d.tools integrating design, test and analysis are great idea for the for physical UI design. ARM have developed a similar product Quartus for embedded system design which integrated software hardware design simulation and testing at the same time. A simulation tool I have used LabView, also used similar prototype design method used in this paper. It can also draw the design in the editor and attach modules on hardware provided and use the computer to simulate the design result as the functionalities d.tools provided in this paper. The UI design methods and functionalities introduced by d.tools are adopted and developed by commercial produces now a day. The HCI design of the tool increases the accuracy and efficiency of the Physical UI designers, and reduced the cost greatly.

Yanbing Xue 23:44:26 10/6/2014

The first paper is mainly about information recording and retrieval system with complex history management capabilities. The implementation is embodied in Designer's Outpost. Storing a design's history in a way that allows efficient access is a difficult challenge. The information that needs to be stored varies from video to audio and even location. When designing a website it is important to be able to trace the history of its creation. This paper introduces a way to track this history. This method is based on four scenarios. The four scenarios are: reaching an unproductive point, writing a summary, finding the reason behind a decision, and creating a set of action items. Using real Post-It notes is a good idea because this is the medium most web designers were using, thus lowering the threshold of use. But this setup causes issues with navigating the history. For instance, if a Post-It needs to be removed to be in accordance with a prior state the system cannot physically remove the Post-It so it just highlights it in red, saying it should not be there. The paper emphasized three features: main timeline, local timeline, and synopsis view. At the heart of the system is the representation of the history as a timeline consisting of a series of annotated thumbnails showing the actions performed on the design web, this is the main timeline. This paper presents a toolkit that embodies an iterative-design- centered approach to prototyping information applicances. D.tools introduces a statechart-based visual design tool, three important types of hardware extensibility, and integrates design, test, and analysis of information appliances. It allows rapid production of protypes, so designers can work a problem as opposed to just thinking it through. This is based on a link between physical action and cognition. Statecharts seem to have some similarity to a finite state machine, but their implementation allows for some additional features. It seems to be more action based than state based. We could learn from the paper that the design ideas often come from users' need. By studying and interviewing experts on their need to a specific function, we could know what the functions could be like. By learning from real use cases, we could know how could the new function help and behave. By carrying out usability studies, we could discover new problems. The paper therefore gives us an example of typical design process of building new functions for specific areas. ========== The second paper is mainly about physical prototyping toolkit for designers doing prototyping. The high-level idea is to lower the threshold for physical prototyping by statechart-based visual design. It can also simulate with real hardwares by extending hardware-to-OC interface, the intra-hardware communication level and the circuit level. The user is able to build a statechart in visual interface within Eclipse IDE which lowers the threshold for early-stage prototyping. The user can also connect a device to the computer via USB and run the program on it, being able to see the program run through the statechart. By entering this test mode a video is capture of the user’s interaction with the devices. These videos can then be replayed with the statechart, as well as be annotated. The major contribution of this project is the combination of the visual programming found in other programs, like SUEDE, with the testing and design analysis tools. Being able to integrate these processes is crucial for quickly prototyping ideas. The authors argue that to refine a design prototypes must be created. The shortage I can point out is that the prototype might still be threw away like conventional ones in the later developing stage since newly generated details or requirements may require a serious change of the prototype. It will be great if we dispose the prototype.

SenhuaChang 23:56:51 10/6/2014

Where do web sites come from? Capturing and Interacting with Design History This paper introduces an informal history capture and retrieval mechanism that supports activities for collaborative, early-stage information design. The assumption of this paper is that all users share the same wall, and that wall should be responsible for recording the history of modifications on it. Users are able to browse more efficiently, on the timeline. Even though, the missing of merging will course that people cannot parallel their works very well and the modifications on the branches could be easily brought to the trunk, the idea of supporting history browsing could be useful for the designers. For example, in my experience, developers are easy to get lost in de developing process. Therefore offering the ability to look back and find the original rationale is way important for such kind of system. This kind of concept is very useful and interested, but the final product to support this concept can be done better in the future. Reflective Physical Prototyping through Integrated Design, Test, and Analysis This paper introduced d.tools, a prototyping environment that lowers the threshold for creating functional physical prototypes and integrates support for prototype testing and analysis into the workflow. I have to say, the d.tools project really looks cool, which allows us to build protocols for external devices very rapidly. The key idea behind this system is that the iterative design of ubiquitous computing devices differs from either pure software applications or traditional physical products. Therefore, a method that supports rapid construction of concrete interaction sequences for experience prototyping seems more effective. I think this tool is quite powerful because it not only integrated the essential design and quick deployment tools, and also provide the function of test and analysis. Also it provides good hardware extensibility through the Java, which makes it more adaptive to developers with specific needs. The method that abstraction is good for designer, so building an abstract layer for device is very good.

Mengsi Lou 23:57:03 10/6/2014

Reading critique 2014/10/6 Where Do Web Sites Come From? Capturing and Interacting with Design History This paper discusses the history system that present an informal history capture and retrieval mechanism for collaborative, early- stage information design. It implements in three mechanisms, that is a main timeline, a local timeline, and a synopsis view. The system mainly consists of board surface, front camera and rear camera. The user can create new pages by writing on new notes, post them to the electronic wall and organize a site by physically moving the notes around on the board. The principle is that the rear camera will capture the location of notes, detecting the adding or moved notes. And the front camera captures the contents on the physical notes. Thus, the two aspects of information will construct the system. ////////////////////////////// Reflective Physical Prototyping through Integrated Design, Test, and Analysis This paper discusses the d.tools that makes use of the prototyping iteratively to help the interaction design. The prototyping is the pivotal activity in the progress of designing contains design hypotheses and enable designers to test them. The d.tools brings benefits in three aspects. First, the statechart-based visual design tool that offers a low threshold for early-stage prototyping. Second, three important types of hardware extensibility makes it possible for designers to make the simple model out. Third, and is also the most important one is to integrate design, test, and analysis in designing. I’d like to talk about the third point in this paper. The main idea of d.tools is to support design thinking. It offers to enable the rapid design and evaluation of interactive physical devices. In detail, the progress is divided into three steps arranged in cycle. Starting from the prototype designing, d.tools support for authoring interaction models with physical I/O components. Then the second step is testing the prototype. In this step, it marks both positive and negative views for later view. The third one is to analyze. It separates from single user and group user using the statechart. The cycle path of the three steps is important that makes the best use of prototyping, especially the analyzing step back to designing step with the feedback. Prototyping will help designers make the developing progress more rapid and also more effective.

Nick Katsipoulakis 0:15:18 10/7/2014

Where do Web Sites Come From? Capturing and Interacting with Design History. : n the work of Klemmer et al., a system for design history capture and retrieval is presented. This system features a mechanism for using physical post-it as input and also providing the users for navigating freely among different snapshots of the design. The Designer's Outpost system promotes timeline navigation by presenting both a main timeline of the design, and a local timeline for each object. The former, is achieved by visualizing different snapshots of the design process, based on user defined criteria. Also, consistency among physical notes and digital notes is maintained and history branches are saved and presented to the user upon request. Turning to the local timeline, a zoomed in view is provided for each note, which is able to present historical information to the user. Finally, a synopsis view can be shown to the user either in list view, or in printed format. This system has been implemented and given for testing to six professional designers. Overall, the designers' experience was satisfying but they made some comments on further features to be added to the system. The first observation was the need for the prototype system to support simultaneous comparison of histories, and the second was to provide the ability to merge different history states. Finally, the authors mention that in the future they plan to explore heuristics for building concise histories, add the ability for audio capture and implement functionality for remote collaboration. //----------------------END OF FIRST CRITIQUE------------------------------------------// Reflective Physical Prototyping through Integrated Design, Test, and Analysis. : In this paper, a revolutionary toolkit for prototype designing is presented, which combines physical design with virtual design and supports video capturing on tests. d.tools concentrates on the fast and cost-efficient prototype construction. The design of d.tools allows the designer to define the prototype's hardware physically, by adding components on the test board. These changes appear in d.tools and the user is able to define the prototype's behaviour with statecharts. Also, the designer is able to test the prototype and videos are created that relate physical actions of a user with the state of the prototype. Elaborate testing has been done on d.tools. During a seven month period, d.tools has been used by designers that had to go through a training period and then trained for design thinking. Even though d.tools succeeded in most of the tasks, some shortcomings were revealed: lack of software simulation of an interaction model, complexity of the software model, physical size of the prototype and third-party software support.

yubo feng 1:15:24 10/7/2014

In today's reading part, both articles are about system: the first paper "Where Do Web Sites Come From? Capturing and Interacting with Design History" talked about a kind of informal history mechanism for collaborative design of information architectures; then the second paper mention about d.tools, "a prototyping environment that lowers the threshold for creating functional physical prototypes and integrates support for prototype testing and analysis into the workflow." From these two papers, I found that HCI not only lies in user end, as the designer and implementer, we are users in some sense, so, support a kind of interaction method to build connection between us, developers and machines are also important and should be paid attentions.

Andrew Menzies 1:33:02 10/7/2014

Where Do Web Sites Come From? Capturing and Interacting with Design History by Scott R. Klemmer et. al. It can be difficult to tell, from a design prototype, how and why design decisions were made. The authors of this paper present the Designer Outpost, which unobtrusively captures design idea history from the notes placed on a blackboard, letting users edit the notes and review their history at any time. The Designer Outpost system, similarly to the DigitalDesk system, obtains its input from users’ manipulation of physical objects, here sticky notes on a wall board. It tracks various actions such as notes added and removed as well as when a meeting occurs and who performs such an action. Later, users can navigate timelines which organize states of the board by various criteria (such as those during a particular meeting or those after changes by a specific person). Users can choose a board state in the timeline, and the system will project the notes from that state onto the board for the designers to review. Perhaps the best feature of this system is that it takes in input automatically, as users naturally do their design work with notes on the board. This process is called informal capture. The paper notes that systems with similar review capabilities but without informal capture failed. Those other systems forced users to think according to a specific syntax for later entry and maintain the idea history separately from the design history. The informal capture system, assuming it does interpret users’ actions correctly, should provide a more accurate history than those other systems, as it will not have to worry about users forgetting what they discussed during a meeting before entering it afterwards, or simply refusing to undergo the extra effort to maintain the history. Importantly, if the system does not capture everything a user wants to remember, they can still go back into the timeline and add annotations to their notes. One shortcoming of the system is that it does force the users to do their designing work using the board and sticky notes. It is not clear from the information in the paper whether the system could store something like a large drawing (too big for a sticky note) of the current layout design of a Web page, which is something the designers would be willing to draw (since the system is optimized for Web designers). Another concern is how well the system can tell the difference between a single edited note and two separate notes. This would likely be very difficult to implement without either adding a rule for users to follow like “Only edit notes while they are attached to the board” or adding technology to the notes themselves (making them into tabs, as in ubiquitous computing). Still, the system provides many useful functions for designers, as corroborated by the authors’ user trials. Reflective Physical Prototyping through Integrated Design, Test, and Analysis by Björn Hartmann et. al. D.tools is a hardware and software suite made to be used to design, build, and test prototypes. It is focused for use in an iterative design process without the need for programming skills. The tools provide several main features, including a visual interface for programming a prototype as a finite state machine as well as numerous hardware components organized similarly to a software library. The software also lets users record and play back videos of tests while viewing the prototype’s state during each test step. In fact, the tools are responsive, reacting to manipulation while the software is in design mode just as they would if it were in test mode, providing instant feedback for the user’s design choices. Two important qualities of any interface design tool are its threshold (complexity of operations required for users to make anything) and ceiling (maximum complexity of products the tools can be used to make). D.tools attempts to provide a low threshold and high ceiling. Visual programming of finite state machines is easier to work with than text-based programming, resulting in a low ceiling. However, the software states and transitions can be customized using textual Java code, and the hardware can be modified or extended. These facts let users create a wider range of prototypes than the visual programming and a limited set of hardware components would allow, raising the ceiling. One other point of interest is how the tools, made to facilitate iterative design, went through an iterative design process of their own. The authors performed a few small-scale user trials beforeWhen users in one trial asked for a way to test a component before building it, the creators added a way to use the d.tools software to simulate hardware. After another user trial, the creators added a Java API to allow prototypes to communicate with other systems. The authors mention that they may add support for Flash or a similar language to the tools to help users improve the looks of prototypes in the future. These changes highlight the real results that iterative design brings.

Wei Guo 1:55:47 10/7/2014

Reading Critique for "Where Do Web Sites Come From" This paper is about an informal history capture and retrieval mechanism for collaborative, earlystage information design. This system extends the Designers' Outpost. It contains three mainly mechanisms: main timeline, local timeline, and synopsis view. For the main timeline, it is using stub-branchingm and annotated synopsis view. Inside this paper, I get a chance to know the outlook and also the mechanism of Designers' Outpost. I also get a clear view of how this system designed to make timeline and synopsis communicate with each other. This paper is using a visual way to capture the history. Reading Critique for "Reflective Physical Prototyping through Integrated Design, Test, and Analysis" This paper is about a toolkit called d.tools. What is d.tools? d.tools is a hardware and software system, that let designers to prototype the bits and the atoms of physical user interface in concert in a rapid way. Which means designers can place physical controllers, sensors, and output devices directly onto form prototypes. They can then modify their behavior visually in the software workbench. There are several functions squares on the interface: device editor, statechart editor, property view, and asset library browser. User can graphically arrange icons of input and output components into a virtual prototype. And d.tools can dynamically detects the presence and capabilities of attached hardware components, then enabling the software editor to be coupled with the hardware configuration.

zhong zhuang 2:30:56 10/7/2014

This paper talks about a implementation of a designer’s tool to help people understand better the history of web. This system is called Designer’s Outpost, a wall-scale tangible interface for collaborative web site design. It is basically an electronic white board supported by front and rear cameras to detect physical documents. Similar products are mentioned in the paper also, for example, the classroom 2000 system which allows automated capture and access of classroom information. Another product is AudioNotebook which enables the audio information capture and processing. The history system interface includes timeline visualization, if basically display a series of screen shot and let user add note or bookmark in them. Besides, the paper also proposed synopsis visualization. When interacting with a design history, it I s important to create a list of states and then view that list, this function is implemented by synopsis visualization. A synopsis can be constructed in two ways, first it can be constructed via explicit user bookmarks. Second it can be constructed from a filtered history view.

zhong zhuang 2:46:16 10/7/2014

This paper is about physical prototyping, as ubiquitous computing continues to populate the world, many products are very physical now, for example. Smart phone, tablet devices, digital camera, etc. Designing prototype of these products is very important for designers. So providing a useful tool of physical prototyping becomes critical. Like in assignment two, the intel Galileo board is an excellent example of physical prototyping tool. It also adopts the idea presented in this paper, rapid and interactive physical prototyping. Instead of trying to design a perfect product in one time, the paper suggests the designer should design multiple rapid prototyping in a interactive manner . Let the designers work it through, rather than think it through. The d.tools design tool kit is explained in detail in this paper. First it provides a rich set of interaction techniques and architectural features that enable d.tools to provide a low threshold for early- stage prototyping. Second it offers an extensible architecture of physical interfaces. It is very flexible, it has three layers of interfaces, PC-hardware, interhardware and circuit level. Third, d.tools integrates design, test, and analysis of products together. It records a video of user interaction with the device and then enhances it by adding log and note for future post-test review and analysis. The most of the paper is devoted into how to do physical prototyping with d.tool. It almost serves as a user guild of the tool kit. Anyway, it is a very functional paper if one is interested in physical prototyping and using d.tool as the tool kit.

Brandon Jennings 2:48:12 10/7/2014

Reflective Physical Prototyping This paper talks about the idea of prototyping being the important part of the design process. It presents a tool, d.tool, that supports an iterative design approach for developing prototypes by lowering the threshold for creating functional physical prototypes and integrating support for prototype testing and analysis into the workflow. This paper is extremely relevant to today because prototyping is the most important part of design. It allows the designers to not only visualize but to physically analyze the product at the stage it is when it is prototyped. Most products have gone through many series of designs and there are dozens of prototypes before the final product is produced. The interactiveness of this tool with hardware components make it unique. The tool appears easy to use with graphical programming. Some of the important parts of the work presented in this paper are interaction techniques and architectural features that encourage a low threshold for early-stage prototyping. An extendable architecture for physical interfaces is also presented. It is important because it offers extension at the hardware to PC interface, the intra-hardware communication level, and the circuit level. d.tools also records user interaction with the physical devices and integrates the video with logs of interaction events to review usability data after testing. Where Do Websites Come From? This paper proposes a new method of analyzing design history. It presents different techniques for viewing history including a stub-branching main timeline, an in situ object timeline, and an annotated synopsis view. Visualizing design history is an important part of the process. These techniques enable designers to review past revisions of the systems they develop. For example, the highlighting features in the timeline visualization makes it easy for designers to discern differences between current and past versions. The branch timeline is particularly unique in that it can show the progression of stages if different paths were taken. So if designers have a few directions they may want to go, they can see all of their options. I think the user study could have been expanded more. It seemed limited by the small number of participants. It would have been nice to see these visualization techniques implemented in various settings for more projects. College universities groups and small business would be ideal for testing this system, as they can use the system and experiment with it, unlike larger companies who are already comfortable with their current methods. I would also like to see a more quantitative analysis of the results. It would be more interesting to see the efficiency of this system with current methods used by designers.

yeq1 6:38:43 10/7/2014

Yechen Qiao Review for 10/7/2014 Where Do Web Sites Come From? Capturing and Interacting with Design History In this paper, the authors had introduced a history system that allows designers to access timelines and synopsis views. This system supports the design process by allowing fast backtracking, and support limited rationale capturing. Backtracking is supported by storing branch history, and undo-redo the unique path between the current and the target nodes. Rationale capture is done by: 1) Annotation of sessions in synopsis view, and 2) links between the timelines. There are several interesting and novel ideas presented in this paper I had not considered before. As an undergraduate, my research concentration was on rationale capture. Design rationales today are typically represented in argumentation models. The professor who I worked with, who invented RATSpeak, prefers this method of representation. One of the most popular topic today in this field is automatic generation of rationale. Video, audio, and electronic documents can generally be used to achieve this purpose. I have never considered that a historical timeline may potentially store some parts of design rationales as well, nor did I ever thought perhaps a more informal representation model may potentially be just as good in doing analysis. The shortcoming of this paper is that the authors had claimed it as a feature but did not evaluate this claim at all. But the idea itself seems to be intriguing enough to warrant publication. In addition, I also think the Outpost system is interesting in that it augments physical notes with electronic notes to provide the history view. In some ways, this is similar to DigitalDesk paper, where the authors had a projector that projects onto a desk. However, the interaction with a wall is in some ways different from that of a desk: the wall does not need to take into account of different viewing angles as much as the desk, and the idea of using the board mounted on the wall as the sketchpad is more natural that using the desk. The only other part I have some issue with is the timeline view. I think both Figure 8 and Figure 9 were not optimal. In the user study, we saw that users who used the view in Figure 9 may want a view in Figure 8. But each has their own shortcomings. Figure 8 may cause information overload, and requires the user of a larger real estate. Figure 9 resolves information overload, but in such a way that provides only partial view of the system. Why not compromise? For example: provide a tree, but allow the user to collapse each branch if they want to, just like they did in the list. Reflective Physical Prototyping through Integrated Design, Test, and Analysis In this paper, the authors introduced d.tools, a prototyping toolkit for ubiquitous computing devices that is designed to support rapid prototyping design cycles. D.tools provide a low threshold by using a statechart-based prototyping model, a high ceiling by providing textual programming, and extensibility by providing Java hooks. With statechart editor, the users can simply drag and drop controls and use Boolean logic to label each transitions in the state chart. Java code can be attached to states to specify more complex behaviors. In addition to supporting fast prototyping, d.tools also supports efficient analysis by providing help during video annotations of user experiences, individually and in groups. In iterative design, both the development of the next prototype and the analysis of the current prototype are important steps that are potentially time consuming. The authors had correctly identified the problem and introduced an integrated solution that mitigates both of these problems. The use of statechart to provide low threshold makes sense in that the diagram is usually used by designers who are operating at implementing level. The use of textual programs to provide high ceiling is also natural as it was widely used by previous GUI toolkits (.NET, XCode, etc.). Integration of a previous work, multiple view interface, provides essential information for designers in annotation of video. While none of the single ideas presented in this paper is novel, the novelty comes from the correct integration of the individual pieces, and the contribution of this paper comes from the positive user experience and user feedback.

Jose Michael Joseph 7:57:10 10/7/2014

Where do web sites come from? Capturing and Interacting with Design History This paper predominantly talks about Designers’ Outpost which is a tool that can be used to effectively develop web sites. This tool is different from most other tools in the market because it has additional features that allow it to provide more versatility to the developer. This in turn enables the developer to make more efficient web sites in the given time frame and also help them to make the right design decisions. Designers’ Output is primarily a tool that supports information design for the web. It is built on the abstraction of a white board and post it notes. This abstraction is very effective as most web developers are already quite familiar with this abstraction and thus it helps form a strong conceptual model in the minds of the user. The setup has two cameras, one that is front facing and the other that is rear facing. The rear facing camera is used to capture the location of notes and any subsequent changes in that location. The front facing camera is used to capture the contents of the physical notes so that their electronic counterpart can be created by means of a projector. Another focal point is that Designers’ Output collects data in an informal way. This means that it is collecting data that would even otherwise be generated by the users in natural ways. This is extremely advantageous as this means that it does not rely on specific conscious input from the user. Demanding specific input from the user can leave the user feeling frustrated and thus it is always a great strategy to collect user data that is generally freely generated by the user. It then uses this data in its various computations like understanding which user posted which note. The visual design of their global timeline has been inspired from Chimera. It is a comic strip styled timeline in which the changes that have occurred recently have been highlighted. This is another great design decision since most users are familiar with comic books and hence will have the right conceptual model about the particular component of this system. They would “intuitively” know which is the item that has been changed since they are familiar with the comic strip model. Another common problem that has been addressed by Designers’ Outpost is that most designers forget the history or evolution that their work went through to get to the current stage. This is important as if modifications need to be made it would be futile to keep backtracking hopelessly until reaching some arbitrary point. To correct this feature the Designers’ Outpost created a history system that resembles more of a graph or a tree. In this way the designer always has an idea about the design decisions that had to be taken to reach to the current stage and this allows the designer to backtrack at any given moment. This also allows the designer to compare the various design modifications they have created and choose one that they are most comfortable with. The drawback of such a system though is that creating and maintaining such an extensive history could consume a lot of memory and as the list keeps expanding, even searching for a state could prove to be costly. The paper has suggested cache as an alternative to this problem but has not implemented it instead stating that such a feature is best left for the commercial variant of this product. On the entirety, the idea seems like an excellent idea and has used some very strong design decisions to enforce a strong conceptual model in the minds of the users. It still has some drawbacks as mentioned above but none that can significantly affect the performance. Most of these drawbacks would be addressed by a commercial implementation of this product, if it happens, and thus should not be considered as a major flaw.

Jose Michael Joseph 7:57:39 10/7/2014

Reflective Physical Prototyping through Integrated Design, Test and Analysis This paper talks about an important tool, d.tools, and its effectiveness in making prototyping much simpler. d.tools has a variety of features that have simplified the process of prototyping and have made it easier for the designer to view the final product. The main highlight of d.tools is that it has kept iteration as the main theme of the design process. Thus the structure of the tools lie in enabling the designer to keep iterating through the various designs and learn from the past experiences. Thus as the paper says it promotes a “working it through” mentality. The drawback of such a mentality is that at times designers might not put thought into their suggestion and would just implement every whim that they have. This could lead to a lot of time wasted on simulating faulty design concepts. An ideal combination would be one where the designer puts ample thought as well as has the ability to rapidly prototype his ideas. Another great feature of d.tools is that it has visual authoring as well as textual programming. This is great for those people who are comfortable with programming and thus would like the textual output that can direct them as to the precise things that need to be changed. The drawback of this is that those who are not as familiar with programming might find this distracting or intrusive. d.tools also offers a wide variety of library components making very flexible methods of implementation as it allows the designer to simulate a wide variety of applications that use various different components at the same time. Thus it supports design thinking rather than implementation tinkering. Another important feature is that it allows a designer to create visual only input and output components by using drag and drop feature. This could be very beneficial to designers with limited knowledge about coding as it helps them to quickly visualize their idea without having to struggle to see if it’s feasible by means of coding. The drawback of such a feature would be that although the visual representation might be close to what can be achieved by coding, it generally is never the same. Coding gives the designer much more power as often it allows them to control the intricate details which further allows them to change the looks in a way that a visual representation could not have come up with by itself. Probably one of the primary features of d.tools is that it allows the user interaction to be captured via logs and videos in “test mode”. This is especially beneficial because it ensures that the developers have an idea about how their product is being used and what can further be modified. Generally the biggest problem is having to analyze all these videos but d.tools has a feature that sorts videos according to the section of the application that they’re referring too. Hence this makes a great feature as this allows the developers to understand the needs of the user while watching them interact with the application.

Xiyao Yin 8:07:08 10/7/2014

‘Where Do Web Sites Come From? Capturing and Interacting with Design History ’ talks about the design history in three mechanisms and describes the functionality of each of these and illustrate their utility in the context of the scenarios presented previously. These three facilities includes a stub-branching main timeline which displays a history of the design using thumbnails, an in situ object timeline which offers the user more detailed information about a particular note without visually cluttering the entire board, and an annotated synopsis view which displays each of the bookmarks on the left and a text-box on the right. Designers use 4 history usage scenarios to draw on field studies of web design. In my opinion, these four scenarios are quite well because they all have a strong relationship with each other. ‘Reflective Physical Prototyping through Integrated Design, Test, and Analysis ’ mainly discusses with d.tools which embodies an iterative-design-centered approach to prototyping information appliances. This design tool has three contributions including a set of interaction techniques and architectural features that enable d.tools to provide a low threshold for early-stage prototyping, offering an extensible architecture for physical interfaces and integrating design, test, and analysis of information appliances. This paper has a strong organization because each part in this paper has a strong relationship with d.tools. It shows opportunities for supporting iterative design, the most important interaction techniques, and how test and analysis mode work. In the tool support for physical computing part, the Phidgets system takes my eyes. Phidget is a physical representation or implementation of a GUI widget. For example, an on-screen dial widget could be implemented physically as a knob. Phidgets are a system of low-cost electronic components and sensors that are controlled by a personal computer. Using the Universal Serial Bus (USB) as the basis for all phidgets, the complexity is managed behind an Application Programming Interface (API). Applications can be developed in Mac OS X, Linux, Windows CE and Windows operating systems. Their usage is primarily focused to allow exploration of alternative physical computer interaction systems, but have most notably been adopted by robotic enthusiasts as they greatly simplify PC-Robot interaction. Phidgets are an attempt to build physical analogue to software widgets, allowing the construction of complex physical systems out of simpler components. Phidgets are designed and produced by Phidgets Inc. This system seems to be quite useful for research in this paper.

changsheng liu 8:48:30 10/7/2014

<Reflective Physical Prototyping through Integrated Design, Test, and Analysis> introduces a prototyping application d.tools, which embodies the iterative-design-centered approach to prototyping. Prototypes embody design hypotheses and enable designers to test them. Framin design as a thinking-by-doing activity foregrounds iteration as a central concern. The three contributions this paper presents are (1) it introduces a statechart-based visual design tool that provides a low threshold for early-stage prototyping, extensible through code for higher-fidelity prototypes (2) introduces three important types of hardware extensibility - at the hardware-to-PC interface, the intra-hardware communication level, and the circuit level. (3) d.tools integrates design, test, and analysis of information appliances. d.tools provides a set of interaction techniques and architectural features for prototyping. This allows a user to quickly create a storyboard driven prototype. d.tools adhere to a "design thinking" philosophy, which allows a more rapid prototyping phase. Developers can rapidly change and simulate their product in each stage of design using d.tools. <Where Do Web Sites Come From? Capturing and Interacting with Design History> provided a view of how the internet came about. The authors have created a capture and presentation system for the web that incorporates three mechanisms to show the history. The system included main timeline, local timeline, and synopsis view. A user can go back in time to see when objects have been created and changed using the timeline. After the history has been captured, the user can view it based on the main timeline, local timeline, or synopsis view. Each component in the system is suitable for different cases. Timeline is helpful for viewing state changes and visualizing a chain of actions. Synopsis visualization creates a list of the changes made for a concise overview.

Christopher Thomas 8:49:23 10/7/2014

2-3 Sentence Summary of Where Do Web Sites Come From – The authors discuss the design of a system which enables designers to see the history of design decisions – interacting with post-it notes on an electronic board. Users can make trees of post-it notes, budding off new research directions and annotating the notes to see the history of design making decisions. The authors also perform user studies with web designers to see how they like the system. One of the main results of this paper and the results of the design study was to show that having the history available provides great benefits to designers, when they are either going back over what was done to review or trying to come up with new ideas (so they can quickly see what was done in the past). I am reminded of the paper we read about brainstorming with IDEO – which urged people to think freely and to never erase from the board. I think a system like this would certainly be useful for them – where many post it notes could be placed up as people shout out ideas. Then, after a good idea sticks, a tree structure could be created from it as further refinements on that idea are made. Ultimately, if the idea turns out to be a dead end, it could be annotated as such and the designers could move to another idea. Someone who missed the brainstorming session, could load this design history feature and see exactly how the history was developed, reading the annotations along the way of why certain concepts failed, the history and refinement of ideas, etc. –something that may not be available just from seeing post-its on a board or notes that someone typed of the meeting. Thus, while the information itself is important, what the authors are showing is that the history of the process that lead to that information and those ideas is equally important. Another interesting thread of research which I found interesting in this paper is the idea that paper in the physical world becomes an input device for the electronic world. In other words, real paper post-it notes become an input channel to the system through the cameras. Thus, users can work comfortably, using post-it notes and writing on them, then effortlessly putting them up on the board and having that information instantly captured. I am reminded of the digital desk paper, where the authors used a similar technique – using real paper and real documents as an interface to the system, with the system interacting with the drawings and writings on those documents with a camera. In this way, uses get the convenience of working with a digital system - while retaining all the benefits of using traditional paper input channels which everyone is familiar with. Presumably, it wouldn’t be difficult to add the feature of adding virtual post-it notes through a projector so if a user wanted to input that way instead they still could. Thus, this system provides a great tool to companies like IDEO with lots of ideas on sticky notes on a board and disorganized. This system first of all captures those post it notes digitally allowing people to go back to it years from when it happened, despite having long thrown the real post-it notes away. But, I think the real contribution the authors are claiming from this system is the idea that it provides users a history of the development of those ideas- the notion that we aren’t just capturing the ideas statically in a vacuum, but rather the notion of capturing the thinking process that lead up to those ideas and how those ideas arose in a temporal context. By providing that context, users can better understand how the meeting progressed. Finally, and more generally, I think the paper gave a good example of how the design system itself was developed by providing a good history. The authors explained their initial ideas, how they worked and were thought to work and then they explained the results from the first user study. As a result of that study, they found some ideas didn’t work and that new ideas needed implemented. Thus, users aren’t left wondering why the authors made certain choices – as the decisions are clearly explained in the context of a user study. Thus, the authors show how the design history system itself evolved by providing a history of its design, which I thought was very interesting. 2-3 Sentence Summary of Reflective Physical Prototyping through Integrated Design, Test, and Analysis – The authors design a prototyping platform which enables designers to focus more on designing than implementation details. This prototyping testbed provides different modes for iteratively improving the design process, allowing designers to implement state-chart like prototyping, a test mode for evaluating the prototypes with videos and annotations, and an analysis mode which uses annotations on the videos to quickly and conveniently sift through a lot of data. One of the core concepts discussed here which I hadn’t heard of before is the concept of reflective practice, which is the idea of framing and evaluating a design challenge by actually working the design through. Too often, because of the complexities involved in working a design through, designers just think it through. What this paper showed is that actually a lot can be learned with a very simple state-transition prototype model. Too often, ideas which seem great in theory actually don’t pan out in practice, but discovering this takes far too long. Especially since many designers aren’t programmers, which introduces even more problems. However, by using a tool like this, designers don’t need to be programmers. They can very quickly design UI’s, even just as pictures / states, knowing essentially no programming at all – quickly moving from the design phase to the testing phase (iteration). It is this process which is critical as the paper on brainstorming with IDEO pointed out to us. Thus, the paper again underscores the idea of iteration as a core component of brainstorming and of the design process. The authors also discussed the concept of a threshold and a ceiling, which the previous paper also discussed: a concept we discussed in the toolkits paper. This system is, however, also a toolkit itself, so It was nice to see that the notions of ceiling and floor were in the designer’s minds of this system. One of the nice things about this system is that it doesn’t just provide tools for designing and prototyping, but also for evaluating those designs. The idea of test mode actually connects the prototyping system with the testing of the prototype through video annotations and state recordings. This allows designers to rapidly analyze the results of the test with annotated videos, advanced query features, etc. I thought this connection of design prototyping with the evaluation of the prototype itself in one tool is a great idea. It takes advantage of the information that is available, instead of just doing the evaluation in a vacuum. Another feature which I found interesting was the idea that designers simply had to demonstrate for the system an action on the hardware, for instance pressing a button or a slider. The system would then learn the parameters for that action automatically. This is something that I can see would be extremely useful, especially after doing HW 2 and seeing how difficult learning threshold values can be sometimes. It was also nice that even though they provided the capability of automatically learning these things, they still kept the options available for advanced users to edit. The authors exposed underlying API functions and allowed the system to be modified with code for experienced users. This is a great compromise, in that it doesn’t require people to know programming but it doesn’t limit or box in those that do. I think this idea of catering to experienced and inexperienced populations is key. I also liked how the authors explained each of the user studies they ran of their system. They explained after each of the user studies what shortcomings were discovered and then took steps to improve upon those shortcomings. Thus, they were using an iterative design approach to build an iterative design prototyping system, which I thought was very ironic and interesting. At the same time though, it was a great demonstration of how the iterative design process works.

Vivek Punjabi 9:39:14 10/7/2014

Where Do Web Sites Come From? Capturing and Interacting with Design History: The paper gives an informal history capture and retrieval mechanism for the design of information at an early stage. There are 3 ways to access any design history: a a stub branching main timeline, an in situ object timeline and an annotated synopsis view. The authors have provided a set of four scenarios in the paper: reaching an unproductive pint and heading off in a new direction from an earlier point, writing a summary of a design session, finding the rational behind a decision and creating a set of action items from a design session. They have provided some interesting examples and scenarios to explain each of the visualizations They intend to inspire their work in other professional domains as well. They have provided a much easier way to understand the design history of web sites which makes it inspiring. As usual, the paper should be updated with the new design systems and technologies. Reflective Physical Prototyping Through Integrated Design, Test, and Analysis: This paper presents a new prototyping tool called d.tool which uses an iterative design centered approach for prototyping information appliances.The paper broadly categorizes into 3 parts: the tool used for prototyping, the hardware extensibility and integrating design, test and analysis. The paper focuses on iteration as core concern for UI tools. It first gives the need for prototyping and them gives some important features of d.tools. The d.tools provides some easy and efficient way to create prototypes such as plug and draw and demonstrations. It also has seperate modes for design, test and analysis which makes proper segmentation. One of the interesting features is to convert any state of the statechart to video with automatically filtered annotations. and also vice versa. The paper then focuses on the hardware and software tools of d.tools. It has a plug and play facility, hardware extensiility to certain extent and compatibility with some modern softwares. Finally, they explain the methods in brief that they used to evaluate and refine this tool. They have extensively provided successes and shortcomings of each method which makes it easier for new researchers to make certain assumptions. The paper provides an extensive approach towards iteration of prototyping. The structured and thorough approach makes it easier to understand the concepts. However, the author could have given some case study or an example with complete prototyping which could have made it easier to use d.tools right after reading the paper. This paper will definitely help us to create some early stage prototypes for our projects and thus help us to analyse and evaluate our results at an early stage.