Getting a Grip on Ubiquitous Computing Through Prototyping
From CS160 User Interfaces Fa06
Lecture on Nov 20, 2006
Readings
- Reflective physical prototyping through integrated design, test, and analysis. UIST 2006. Hartmann et al.
Simon Tan - Nov 15, 2006 10:47:13 pm
In the continuation of the ubiquitous computing theme, we now seem to be headed for the realm of physical UIs. The article explains that the same rules of UI prototyping, testing, and analyzing results still apply, and introduces the "d.tools" design tool for such an interface. While reading this, I kept thinking that this might have been the tool we would have used if this course's theme was different. The paper's purpose became unclear later on, because it was almost as if they were discussing the evaluation of their own product rather than discussing actual physical prototyping.
When it came to their product (d.tools), it sounded like quite an innovative design tool. At first, I was afraid that having a limited base device and a selection of "buttons, switches, sliders, knobs..." would result in every design coming out of their product to be similar, but they seem to cover the bases well and provide room to grow with the plug-and-play infrastructure. It looks like a very polished suite, and something I'd be interested in trying at least once.
Anirudh Vemprala - Nov 16, 2006 08:04:33 pm
A very interesting project! Indeed, one of the limiting factors in the design of rapid prototypes of devices (less so for software) is the ability to add in more complex functionality in order to test the effectiveness/utility of the device. The d.tools project appears to offer a bridge between this functionality and the rapid prototype. However, given the experience we've had with the R3 toolkit, I wonder just how easy it is to actually use this program in a prototyping scenario. The second interesting piece of functionality that it offers is the ability to record the exact sequence of user interactions with the prototype. In my experience, it is often hard to remember or record the exact sequence of clicks/button presses the users undertook w/o using a video camera. The d.tools framework offers a great way of solving this problem.
Tabassum Khan - Nov 16, 2006 10:37:49 pm
This reading reiterates the core principles of building a good UI design: Prototype to get early feedback and Iterate to refine the design. The concept of d.tools recognizes the physical and social nature of human interactions. In my opinion, one of the interesting functionality that d.tools provide to the designers is the ability to attach Java code to visual states to specify behaviors which means that the designers are not limited by the capabilities of the visual environment. I also liked the feature of recording user testing sessions that can be later analyzed in different forms. The result of the analysis will help the designer determine if the design is good fit for human use. I found the Eclipse Plugin interface (shown in Figure 2) also very neat. The plug-and-play method in which virtual objects mirror physical objects is very interesting. I like the ability to physically move the components around and define relationships between them.
Jonathan Yen - Nov 17, 2006 03:58:55 pm
This paper seems to discuss more of the hardware implementation of UIs. I'm kind of curious about what the design cycle was like for the development of d.tools. I think it's pretty cool how they've managed to provide so much flexibility in what can be made by allowing for hardware extensibility. In terms of the software, I would imagine that it would be good and would be very impressed if d.tools could be abstracted enough so that non-programmers could use this. Overall, it looks like a very novel project that could be very useful given further refinements.
Chen Chang - Nov 17, 2006 06:26:23 pm
Reflective Physical Prototyping through Integrated Design, Test, and Analysis - Finally we get a very recently dated reading so much of the examples presented relate to current technology rather than outdated devices. This reading reiterated much of what we have learned thus far this semester by starting off the with basic foundations important to have down: "it is through the creation of prototypes that designers learn about the problem they are trying to solve". I like certain italicized text which emphasized particularly important points to keep in mind, such as working it through rather than thinking it through. Perhaps the facet that really caught my attention through reading about d.tools is the live video feature to gather user feedback, live video and audio of user interactions are recorded along with event logs related to critical incidents. I think if we somehow had the resources to do such in this course, our user testing sessions could be much more productive than the way they currently are because we would be able to re-watch and review what we might have missed as observers the first time; not to mention test methods would be an easier process when you have video available to analyze incidents and compute summary statistics.
Hiroki Terashima - Nov 17, 2006 06:31:33 pm
I thought this project was full of good intentions and components to carry them out; I liked how d.tools offers capabilities to design, test, and analyze physical prototyping, and I especially liked the video recording capabilities. The video recording allows for greater range of analysis. Having these capabilities as one toolkit is like having a compiler and debugger together in eclipse/netbeans; it makes the design process hassle-free and allows users to concentrate on the task-at-hand more. Anirudh brought up a good question- how easy would this program be for people to use? It's like designing a designing toolkit or testing a testing toolkit or analyzing an analyzing toolkit; the article points out participants in the research who used the toolkit, and it seems like they liked the toolkit for making their jobs easier: "enabling usability testing (μ=4.6 on 5 point Likert scale), shortening the time required to build a prototype (μ=4.3), and helping to understand the user experience at design time (μ=4.25)." This sounds like a great tool for designers.
Robert Taylor - Nov 18, 2006 01:07:24 pm
This prototyping tool in this article incorporates a number of ideas we've learned into a comprehensive prototyping application. The application itself is very impressive; prototyping hardware with a software interface seems much harder than just software prototyping alone. The prototyping mechanism itself, as I mentioned just previously, incorporates UI concepts we've learned - video data is organized in a way to make it more accessible to the user - it wasn't that video data was made associative, as to further work with the way the brain works (this would probably be hard to implement), but matching states to portions of the video by color and flowchart seems a little associative at least and at best significantly helps in figuring out what part of the video you want to concentrate on. That most of the prototyping work is visual based, and elements and functionality are added to the prototype with mouse clicks probably helps prototypers create interfaces or modify functionality faster.The author mentions a shortcoming of d.tools is that it did not support flash for "flashy" high fidelity concepts you might show to someone you were presenting to. Given the nature of d.tools I don't think this should be a high priority option to include; d.tools seems like it would be better as a low-to-mid level prototyper, as it really deals with core functionality (and appears to work with this well) rather than how the final product actually works.
Ramy Ghabrial - Nov 18, 2006 05:29:55 pm
I thought the test/video capture/video analysis mode was the most useful part of d.tools. This seems like it would have been handy to use while testing our users and running them through our prototype. Another interesting part was the automated sensor value recording, which while simple (you would probably still need to put in some work to allow for Anoto gesture recognition) might nevertheless have helped us in our project code in a few areas.
I agree with previous comments that this is an interesting counterpart to what we have been doing in this course, focusing more on hardware/tangible interface than software interface design.
Ming Huang - Nov 18, 2006 06:55:31 pm
The paper describes d.tools, a reflective physical prototyping tool used to design, prototype, and test electronic information appliances. There are many good aspects of this approach that many other computer-aided design tools enjoy. One is the enforcement of the traditional design cycle through explicit manifestation of each stage in the software interface. The other would the ease of modification, easy storage and retrieval of design changes and documentation. Last but not least is the efficient analysis of user test data by employing computation to places where manual work had been required. The correspondence between the physical construction of the prototype and its representation in the design interface, however, is not necessarily synchronized. This makes it a little awkward to change the design in the software interface and then having to update the hardware to reflect the change. This “short coming” can be considered in two ways. In terms of usability, nothing beats physical prototypes that people can hold on their hands and interact with it in a real-time fashion. In terms of efficiency, the prototype can be simulated right inside the design environment, much like the debugging of a program. When using this method, however, the variety of the components that make up the prototype, and the diversity of functionalities the designer is trying to explore and present may be very limited, depending on the design of the toolkit. Certain techniques, like specification of transitions through real hardware demonstration, is not feasible in a purely software environment. The running time is also subject to the performance of the machine that runs the design tools. Therefore there is no clear win regarding how fast tests in pure software can be done. Lastly, the software provides enough visual feedback so that inconsistencies and oversights can be quickly detected in testing and be fixed. An amusing aspect of this project is that it has undergone the same design methodology and process itself is trying to implement, like the “chicken and egg” thing… anyway, in summary, this toolkit brings the affordances of computation to the systematic design process and is itself a very effective design.
Bowen Li - Nov 18, 2006 10:17:16 pm
Wouldn't it be hard to test ubiquitous computing devices in such a crude manner (as just hooking up wires, etc. ) because many of the more subtle interactions with the device may not be revealed in lower fidelity prototypes. Sometimes, a user may need to have it in the correct environment to have an accurate test of how the device performs. I can imagine how it would be extremeley annoying to to mock prototyping with Excel and Photoshop (heck, even for our simple programs, using PS was just a pain in the butt).
I really like the feature that allows users to attach real code to visual diagrams. I think this type of approach is useful in many situations, not just in prototyping, but in other coding situations as well. Overall, it seems as if the group managed to produce something that is both useful and fun to use.
Yimin Yao - Nov 18, 2006 10:01:47 pm
It's very interesting to read about the designing, testing, and analysis process for a application that's created for improving the exact same tasks. The d.tool designers identified the major problems with the current design process, such as "think-by-doing", high threshold prototyping, time-consuming testing data analysis, etc. The flexibility in the type of input/output hardware devices is a very valuable feature; addition of the software simulation capability also seems to be a smart choice. The testing and video synchronization is a very useful tool for designers during user studies; although the timed input recording inherited in the interface already can provide of a basic timeline of users' actions, synchronized video can in addition capture and allow easy access to quotes and other behaviorial information such as hestitation and confusion incidents. Last but not least, the d.tool aims to allow users to focus on design thinking by direct manipulation of interface features; I am not sure how well this feature can been designed and implemented, but it surely would be a convenient function to have.
The d.tool seems to be a very useful tool overall. The interface to me seems a bit overwhelming on the first look, thus I do wonder how easy it is to master all the features of this application. The article indicate that all the users tested received an initial training period; I am a little curious about how long the period is.
Maksim Lirov - Nov 19, 2006 01:24:57 am
I really liked the d.tools feature of extensively logging the user interactions in the testing cycle. I believe by having the video view and the statechart editor function, the designers are better equipped to pinpoint weaknesses/confusing aspects of the design. Also, I wish we had something resembling the Group Analysis mode of d.tools for our projects, because it looks like a great way to compare how different testers responded about specific features of the design.
It seems that the designers tried to standardize as many components of d.tools as possible - going with Java and eclipse on the software side and popular components that can be plugged into the board. As was mentioned by the authors, "no such [small number of widgets that cover the design space] exists for physical UIs because of the greater variety of possible interactions in the real world", but I can see how d.tools' use of a standardized backbone and available components would make iterating over a physical design several times possible. I do think that using d.tools isn't as "plug-and-play" as the paper makes it seem and also that the d.tools board's limited number of component connectors could limit the design space that the designer could explore (the authors mention that one of the benefits of d.tools is that it gives designers the opportunity to explore more of the design space). However, d.tools looks very promising and it does make the physical UI design process a lot more standardized and smoother overall.
Michael Moeng - Nov 19, 2006 02:14:08 am
I like the concept behind the d.tools toolkit--I felt that our low-fi prototype felt "cheap" and that may have negatively affected our user responses, causing them to take it less seriously. Also, the videos that correspond to the "state" of the UI seem very helpful, kind of like the pictures corresponded to timestamps in the Butterfly Net example earlier this semester.
The most limiting factor I could see, excluding the "shortcomings discovered" covered in the paper, is that the hardware-software interaction seems somewhat limited. Many companies, unfortunately, use proprietary hardware IO--this doesn't seem as though it would work well with the d.tools. Also, if somebody wanted to try out a truly revolutionary design, it is possible that d.tools may not support the necessary hardware interface needed depending on how "out of the box" somebody was thinking--this limits the number of really good ideas that can be expressed with d.tools.
Tak Wong - Nov 19, 2006 02:57:52 pm
It's interesting to read about an interface that help prototype hardwares. The hard part about designing interface for hardware is that they contain more physical component that have to be compatible with each other. They also have a lot of software support to facilitate editing in a group setting, which can be useful in sharing common knowledge. They even have many possible extensiblity with personalized code and such. Despite these good things, I can imagine a lot of frustration with using this system. Even a software based system, like the Anoto, gave us a lot of problems. I'm not sure if it is worth using this interface to prototype because of the frustration that leads to using the interface itself and not the design.
Antonis Mannaris - Nov 19, 2006 05:20:23 pm
d.tools, as presented in this article, is an excellent prototyping tool that offers great advantages to the designer. The state chart flow gives an easy way to develop complex transitions between the design without the need of complicated coding. The drag and drop implementation scheme means that you do not have to be a programming wizard to develop the UI, and most importantly you can follow lo-fi designs directly. It also provides abstractions for hardware interaction which is even harder to do programatically. The most impressive feature however is the ability to go over your test sessions (with video playback included) and analyze your results. This is a great tool as a detailed analysis of tests is very important in useful in the evaluation of a design.
Sean Carr - Nov 19, 2006 05:39:33 pm
The features of test mode sound very useful, such as the video/audio recordings of the user interactions. I wonder exactly what they mean by "automatically structure the test videos." It is surprising the multitude of I/O functions/devices they support. I guess without that it wouldn't be useful for as many projects, but it seems like implementing all that support would big a very big task. The user interface also seems surprisingly well developed, but even so it seems like learning the details of the system would take a long time and might inhibit people from switching away from their current, well understood processes. It seems like it would be a lot of work just to get the system working during your first prototype, but then after that the iterations would be rapid and productive. This is coming from a software engineers perspective though because much of the electrical aspects seem complicated and require having the needed physical devices instead of just using easily accessible lo-fi tools. I guess though that design studies have easy access to and know-how with these materials so that if the benefits are great enough the rest is not an issue. The deployment of d.tools in a class project setting reminds me a lot of our course project using a toolkit still in the research stage.
Tony Yu Tung Lai - Nov 19, 2006 08:55:40 pm
I really like the idea of d.tool and the fact that it support so many different stages of the design process. One thing that concerns me regarding d.tool, though, is the level of difficult to implement lo-fi prototypes. Although it was mentioned in the paper that the implementation is easy, it is hard to tell without seeing the actual program. Afterall, the ease to create and change are the main concerns for lo-fi prototype, and it is hard to imagine the implementation system in d.tool would be easier to use than pen and paper (and tapes, and scissor...). However, the final product, at least from the screenshots in the paper, do look extremely good. I suppose it would be a fair trade if the lo-fi prototype is not that difficult to implement using d.tool.
Kang Chen - Nov 19, 2006 11:36:46 pm
This d.tools seemed like a really versatile and useful application to aid in prototyping and implementation. One of the biggest features I liked about it was the support for statecharts. This is one of the more informative diagrams in the unified modeling language which is often used by developers and non-technical clients to define the specification. While the diagram provides quick mock up of the specification, it often takes a long time to actually implement it. The statechart editor as demonstrated in one of the screen captures would greatly reduce that time. It would be great if d.tools offer support for other types of diagrams in UML as well.
Alex Wallisch - Nov 19, 2006 08:06:43 pm
I'm impressed with the ability of d.tools to provide a UI for hardware. I've always been under the impression that coming up with a UI that contains enough functionality to test a prototype was difficult. Even after having taken this class, I understand that a non-trivial amount of work is required to build such an interface, and that's just for software. Having a tool like d.tools available to actually be able to plug in hardware and try out your design on it seems almost too good to be true.
One thing I'm worried about is the limited ability of d.tools to cause hardware to have the exact function desired. When we designed the interfaces for this class, we begun by designing on paper, which allowed full creativity for what we could do. We then moved to java, which provides enough functionality to do just about anything we could have thought of on paper. With d.tools, however, it seems like there might be a temptation to alter one's design to conform to what d.tools is able to easily produce. This is more a function of d.tools being the only tool of its type available and it still being in development, but it is something to think about nonetheless.
Roland Carlos - Nov 19, 2006 11:53:59 pm
I'll echo a lot of previous comments regarding praise for the fact that d.tools lends support for the entire prototyping process. Not only is d.tools designed to help with the design phase but it also supports the test and analysis phase. Looks like this project is aimed towards project designers who do not have that much experience with programming. Am I incorrect in assuming that d.tools does some of the programming for you as you set up the design in it? If so, it's a remarkable thing, for d.tools to be able to program hardware enough that project designers can use it for actual design. It gets rid of some of the delay of communicating a project designer's design to the programmer to make a high-fi prototype for testing.
I also like how the analysis aspect of d.tools smartly maps the results of various hardware interactions (pushing buttons, holding down states, working a slider) to results that are natural to the user (for example, you can tell how long a button has been pushed down with a quick glance to the results graph).
All in all this is a very interesting project. I'm intrigued to see how further development will continue.
Yang Wang - Nov 20, 2006 12:17:39 am
The idea of the UI for hardware is very interesting. The whole semester, we have really been focused on the design and UI for a software interface that I nearly for got hardware also have UI issues. This paper described really interesting points and problems that doesn't exist in a software interface. However, many of it doesn't really apply in the case of a software interface. One thing that I do point out is that a lo-fi prototype will apply more in this case rather then that of a software design. Although the author didn't really go into the idea of creating a lofi prototype. For a hardware, it is much easier for users to imagine the physical existence of a button and switches. For a software, we seems that have a double layer of representation. While the software on the screen emulate a button in the real life, we emulate the screen on the paper. I believe also, one of the classmate mention above. The lo-fi prototype for the software seems really cheap, out of place, and even comical. I believe that probably may cause significant problem to our test result. If we had designed for a hardware product, the situation will be greatly improved.
Rayhan Lal - Nov 20, 2006 02:04:26 am
The study presents some quite compelling data in favor of the toolkit. Many of us have encountered issues transitioning from low-fidelity prototypes to code. Any system that could help carry out some of this legwork would be invaluable. Being able to generate skeleton source code directly from a low-fidelity model gives the parsimonious programmer the idea that his/her keystrokes are not being wasted. I very much enjoy the way d.tools abstracts away the hardware specifics of I/O devices and uses the PC’s CPU in place of dedicated hardware.
Andrew Tran - Nov 20, 2006 03:31:06 am
I agree with how design is a thinking-by-doing process. D.tools looks so cool, it would have been helpful if we had this when designing our interface, although i don't know how the Anoto pen could be connected to the hardware interface. This article makes me wonder if ipods or zune was designed with something similar to d.tools. One of the features i like about d.tools is that u can create state charts for your product. This easily allows you to see what happens when users click or push certain buttons, and make sure you can transition to any state. This application even allows you to put timers in for automatic transitions, how cool is that. I also like how d.tools have the feature of watching a video of the user using the product, and being able to directly link which part of the state chart the user is in. Within this article, iteration was mentioned as a big concern for UI tools. After reading the article i still not quite understand how d.tools gives a new solution to the iteration problem.
Johnathan Hawley - Nov 20, 2006 09:39:24 am
Reflective Physical Prototyping through Integrated Design, Test, and Analysis - Wow, d.tools looks pretty promising. It seems to put all the tools a prototype designer needs into his/her hands. I like the quote "the companies that want to see the most models in the least time are the most design-sensitive; the companies that want that one perfect model are the least design sensitive." Whenever I draw or do anything design oriented I seem to lean toward the 'one perfect model' mindset. I suppose it is theoretically more efficient to get something perfectly right the first time. However, realistically this is impossible so shifting to a more 'interactive' frame of mind is the obvious thing to do. This is of course very applicable to what we're doing in class. It is amazing to see the progress we have made given that we have had so many opportunities to iterate.
Robert Held - Nov 20, 2006 09:56:16 am
The paper outlined the development and testing phase of an impressive developer tool for creating what I would consider to be "medium-high fidelity" prototypes. The device is certainly much more refined and interactive than a low-fidelity prototype, but it doesn't quite have the spit and polish of a high fidelity implementation. It seems like it maintains a nice balance between low programming complexity and functionality. One of my favorite, small aspects of their computer-based analysis mode is the use of variable line width to indicate the number of times a state transition was traversed. The graphical representation provides a quick way to compare the number of traversals between the various states. Also, it does so without displaying any numbers or text, which would be overkill.
Scott Friedheim - Nov 20, 2006 10:04:23 am
I really appreciate the level of thought and detail the designers of d.tools put into the project. It is an excellent project that has tons of utility. I love the visual state chart and the fact that it allows for easy modification. That alone warrants the project because trying to figure out states in hardware just by viewing code is much more difficult and becomes more error prone. Also very useful was the tools for the testing phase; having the video tied to the state chart tied to a timeline provides a lot of very important data to the testers that otherwise might not be collected or requires much more work.
David Hoffman - Nov 20, 2006 09:31:04 am
This toolkit seems to offer a lot of help in bringing design ideas to a testable stage. Possibly the most impressive argument they made was that they asked several design students to make a design using their software in only 90 minutes. We spent much more than 90 minutes on the hello world assignment. It is a little bit difficult to get a sense for how easy this software really is to learn and use from their description but it reminded me of another piece of software that I used to use. Labview, offers many of the tools that this software offers, including making glossy prototypes with elegant preset displays built into the system. One advantage of the d.toolkit is that it sounds like it helps an evaluator really track the user's performance on the prototype.
Andrew Hao - Nov 20, 2006 10:27:22 am
Amazing, this visual state-chart editor. That's a perfect example of good interface design itself -- allowing the designer's visual facilities to aid in the cognition and understanding of the product itself. Although I'm still not very sure whether d.tools allows the designer to design more creatively by aiding in the iterative prototyping process or design in a limited fashion according to the specs of the hardware interface, the concept and implementation (any Eclipse plug-in has got to be good :D) is a fascinating one. Okay, so I don't really get the video recording interface, perhaps somebody could explain that to me?
Eric Yoon - Nov 20, 2006 10:43:29 am
d.tools sounds like a very innovative project -- I guess it is a work in progress, I am amazed that no one has thought of it before. It's interesting to note that in the field work that they did, the d.tools authors confirmed what I suspected was a weakness of the low-fi prototype -- that testers found that sliding around paper or Photoshop layers could not fully convey the feel (and therefore the flaws) of the interface. It's neat that d.tools is implemented in hardware as well as software -- that you can actually place buttons, screens and various other commonly used interface tools. And the addition of a camera, using live video and audio to track the actions of testers, is excellent. Lastly, although I'd have to actually get my hands on d.tools to really know, I suspect d.tools is pretty friendly to the non-expert-programmer. It was comforting to see that in their field work, the authors recognized that most designers are not heavy duty programmers. I imagine the tools will be particularly useful in reducing the need to outsource prototype iterations to programmers, thus cutting the overall UI design time a great deal.
Heung Tai - Nov 20, 2006 10:52:42 am
dtool seems to offer everything I need to carry out design, prototyping, evaluate phrases. A nice feature of it is the option to connect the prototype with real physical device. That means the prototype can fit into various stage of the hardware development. For example, if I want to make a electronic dictionary, I can just build the keyboard first and let software does the rest. Then at later stage I may have a screen, so I can have a electronic dictionary that consist of a keyboard, a screen, and a software behind to do the processing of input and output. dtool also has various way to let programmer has higher control of different components of the prototype such as the ability to attach java code for dynamically generate graphics. To get popularity, it provides plug in for existing popular software, eclipse. I think this dtool would be more successful if it can provide some free video tutorial online (like what microsoft did for visual studio).
Joe Hart - Nov 20, 2006 11:17:19 am
d.tools seems like a rather ambitous project. Whenever a designer takes on using a design tool the tool designer starts to have more of a say in the product being designed than is perceived. The product designer must work within the confines of the tool and is both restricted and hindered by it. With a lo-fi prototype the sky is the limit... in d.tools what the tool designer has thought to put in and get working is the limit. I think that d.tools can be a great asset to any project but work outside the system should be complete before trying to implement the design in a project based tool to avoid possible conflicts.
Patti Bao - Nov 20, 2006 11:26:24 am
The premise for d.tools is very convincing, as I think we all discovered that working through stages of the design process were much more productive than merely thinking them through. It's great that d.tools can be connected to physical prototypes and then used to evaluate and adjust component properties through a very visual interface. I particularly like the d.tools support for testing prototypes, and it would have been very useful in our own testing methods to have had a set of timelines like the one described, complete with the ability to indicate positive and negative instances. As others have mentioned, the strongest case for d.tools is its success in three different studies - the projects built with d.tools look very interesting and I would actually like to learn more about how d.tools was used to carry them out.
Sung Yi - Nov 20, 2006 11:36:56 am
The d.tools provides an effective way to design, prototype and implement. It is a toolkit to transition from a low-fi prototype to med-to-high prototype -- especially I find the visual state diagram very useful in that it is very easy to see the whole structure and modify where necessary, just like the UML diagram I am using in software engineering. However, One concern with this is that hardware implementation using such software tool seems a bit harder than usual.
Vijay Rudraraju - Nov 20, 2006 11:32:42 am
The interface of d.tools brings to mind the first example in the Hutchins, Hollan, Norman article about direct manipulation interfaces. The gulf of execution is made smaller by making the metaphor of connecting states and devices direct. That is, in the program, to indicate a connection between two devices, the user simply drags the two devices onto the stage from a library and connects them. Because the software is extensible, there is the hope that any lack of expressiveness in this programming language can be overcome by extending the current toolset. I think that the developers of this software have addressed many of the concerns of developing a robust, flexible prototyping software suite.
Julius Cheng - Nov 20, 2006 11:38:05 am
This really is an interesting project - it's something that I've thought of, but always imagined it far too complex and difficult to implement.
In effect, d.tools is a software implementation of lo-fi prototypes and "wizard-of-oz" techniques, and offers UI designers the ability to make rough drafts that look and feel much closer to the finished product. I remember from the lo-fi prototyping reading that one of the drawbacks of lo-fi prototypes is that they don't indicate progress to non-UI designers, that higher-ups or investors wouldn't understand the progress made when seeing them. d.tools allows this kind of prototyping to look much more professional.
A disadvantage to using d.tools over lo-fi prototyping is that it would probably take a very large amount of time to design a complete model of a complex interface, simply from the overhead of creating each state frame, when the finished product isn't much more advanced than a lo-fi prototype that one can use physical input devices with.
Melissa Jiang - Nov 20, 2006 11:44:18 am
dtools does seem like a great idea for designers who want good feedback. I had always thought that it could be costly for major companies to iterate from lo-fi to med-fi then to hi-fi prototypes before getting the final product rolling. However, with the dtool, iterations will take less time and they can record the testing and place the clips on a timeline. It provides a great way of integrating all good designing concepts and turned it into one system for easy access to change and testing results. Also, the dtools team does not seem to be fazed by adding additional features such as flash. I wonder where their limit is...could they design it so that a person can design a breadmaking machine?
Vahe Oughourlian - Nov 20, 2006 10:59:29 am
Reflective Physical Prototyping through Integrated Design, Test, and Analysis
The idea proposed by this paper basically brings together all the tools that the rapid prototyping model provides and extends to a rapid prototyping method for a physical device. The extensibility of the system is also impressive, in that new physical devices can be added to the d.tools toolkit. However, I still wonder about the prototyping type for a setup like this, in that it seems to want to become a more mainstream prototyping model, trying to save on time and money, though a system like this seems like it would cost much time and money to purchase and deploy (the custom USB interface, the physical devices to connect, the software). The heartening piece of this document is where they admit their failings and remand them, as when the software simulation section was added in response to user study (the self-referential nature of this, in the prototyping and user testing, is quite amusing).
One feature I found quite interesting was the video integration with the prototyping system. In the beginning, it was not quite clear the utility of this, but when they introduced the timestamping and section-by-section editing of the video material, the utility became quite obvious. These were exactly the difficulties we encountered in the last phase of the project where we couldn't come up with an accurate measure of, for instance, mouse clicks. This utility offers accurate measure of nearly every interaction of this type.
Huangnankun - Nov 20, 2006 12:13:29 pm
This is an interesting article because it shows the design/testing process of a tool that is used to help others conduct design/testing. The toolset here is called D.tools and it’s an integrated development environment that allows rapid development/testing/evaluation of user interfaces. D.tools fits in somewhere between low-fidelity prototyping and high-res prototype, it aims to provide the ease of construction/use of low-fid prototype and yet have the advantage of a polished look and finished of a high-res prototype. At first I thought that D.tools would be just like another fancy UI creation tool like flash, but upon reading the article further, I realized that it has much more advanced capabilities. D.tools can actually simulate a physical system and is not limited to simply a computer desktop interface. The external hardware interface provides these features. I’m excited about using this for our project.
Jason Lee - Nov 20, 2006 12:00:18 pm
This paper was a very interesting read, as it encapsulates many aspects of assignments from the first half of the semester into a neat little package. It would be interesting to know how designs would have been affected had this toolkit been available to us to utilize and employ. While it's true that the toolkit is designed more for hardware purpose than software purposes, it would still be somewhat of a valuable tool to have. The paper recognizes this as a shortcoming, even going as far as admitting that the first iteration of their software lacked the support of software simulation and that they had to add it in later. It would have been nice if the paper went a little more in-depth of some of the features of the software simulator, as it seems very focused on the hardware design aspect of the toolkit.
Having said that, I still believe that there is merit to doing lo-fi prototyping the way that we did in class. There are tradeoffs betwen the two methods of prototyping and both have their own merits. Lo-fi prototyping on pen and paper is far less limiting as far as design goes, as you can simply draw how you envision your own design and can make more subtle additions and changes. With pen and paper, you're not limited to the library that the software provides for you. Of course, there are added benefits to using the software, such as automatic changing between states, keeping track of timing between states (a bit harder to do on paper without a stopwatch), and automatically keeping track of user interactions.
Incidentally, on first glance, the design of this toolkit reminded me of a program I once saw demonstrated at a career fair that allowed the user to create "mind-maps", those things where you connect circles or boxes with concepts/ideas written inside them with others, branching in a logical fashion. The flow chart of designing prototypes is similar to interacting with mind-maps.
Utsav Shah - Nov 20, 2006 12:18:39 pm
This was a fairly enjoyable reading as it reiterated the iterative design cycle in a slightly different manner. The idea about d.tools is very clear from the beginning and it makes you want to continue reading. I believe it’s a toolkit that helps greatly to build any physical UIs as we saw in the examples. It does have some drawbacks such as making the designers little careless since the entire iterative process is integrated into one. One can’t stress enough how important iterative design cycle is as this article talks about. I’ve done many interviews and design cycle is that one thing every recruiter wants to hear regardless of the position you’re applying for.
Eric Vacca - Nov 20, 2006 11:53:57 am
This article seems relevant to our course in multiple ways. First of all, obviously the Hartmann and Kelmmer have designed a design tool to enable the coordination of prototype iteration and testing. How i understood d.tools was that the designer can first visually connect elements in the project before implementing anything to get a general work flow. These elements can be implemented as they are needed in eclipse and various information about each element can be stored (such as variable states). Once a prototype is created, the designer can then test it on people directly using d.tools allowing the designer to test usability. This program seems like it would have been very useful for this class considering the emphasis on iteration.
Secondly, the methods they used to test their design tool followed all the techniques we have learned this semester. They tested the design tool with designers and found parts of d.tools that worked and ones that needed improvement. I found it very interesting (and mind numbing) to think about the design iteration of a design tool created to facilitate design iteration. Now that they have a working model, will they use their own tool to further their progress?
Tom McClure - Nov 20, 2006 12:21:58 pm
Fun tool. From the perspective of an implementor and not a designer, I failed to see its utility until the in-depth description of the video markup and query features. We definitely could have benefitted from a tool such as this in our usability study.
Affording the ability to graphically create a semi-functional prototype to a designer who doesn't have to write a line of code is a challenging one. Balancing ease of use with power is always difficult, and the design decision to limit graphically directed transition behavior to simple booleans is a good example of this. I'm not sure it was the best solution, since it violates one of the goals (requiring code for any state changes that are even moderately complex, from designers who are not supposed to have to know how to code).
Kimberly Lau - Nov 20, 2006 12:32:09 pm
This paper describes a very nice, useful tool. Being able to prototype hardware with software would be such a useful implementation method for testing. As mentioned, prototyping hardware is usually scheduled for later, more advanced design stages because of the extensibility and detail required to make it work, so having it earlier would be advantageous. One particular feature that I enjoyed the most was capturing live video of user feedback.
The design process outlined in this paper is very reminscent to that which we followed in this class. Cool!
Bryce Lee - Nov 20, 2006 12:32:07 pm
It is interesting this research would focus on designing a UI for UI design itself, which is at worst a helpful aid to a highly undeveloped, yet documented, process. The presence of a development kit alone provides more of a structure for designers to work within and clearly understand the paths necessary for development. Additionally, the production gives a lot of face value to the work, allowing individuals to show companies their progress. I especially like the integration of the physical device with the software interface, making them a single unit in a way. This eliminates breaks in abstractions, such as having to upload code to the machine.
Jonathan Chang - Nov 20, 2006 12:24:24 pm
d.tools is a good solution to the problem of being able to rapidly turn out multiple iterations of a prototype, yet still make it of sufficient quality to make any kind of user trial meaningful. I'm still skeptical of all the overhead, however. It seems that while the individual parts of the tools are intuitive and simple, like the drag-and-drop CAD, taken as a whole, the toolset could still prove a little daunting to first-time users. Also, people designing a physical device, which d.tools seems to be trying to target as opposed to a purely computerized application, still run into the problem of designing something tangibly slick enough to make a difference in terms of user response. If you're designing something like a camera or game controller, you still need to design I/O ports and implement physical characteristics, and d.tools seems to essentially be serving the part of a smart videorecorder.
Siu Pang Chu - Nov 20, 2006 12:13:05 pm
The paper introduces a “iterative-design-centered” application called d.stools. This application can be used in early stage low fidelity prototyping and extensible to high fidelity. The interesting part of this project for me is it can connect to hardware. It provides integrated support for designers to test prototypes with and analyze the results. Figure 4 seems very useful, I like the timeline and video data are put to together. So the user can easily compare different set of data. Another important issue that I learn from this paper is process of designing this application. He conducted lots of interview and testing with designers and students.
Yen Pai - Nov 20, 2006 12:29:11 pm
Echoing an earlier point, while I believe the application can help with rapid prototyping, the prototypes shown were of fairly low fidelity. Is that the point? For ubiquitous computing devices where the physical interface is so important, I would imagine the fidelity of the prototypes would have to be fairly high in order to get an accurate gauge on the merits of the design.
Also, from the paper, it was a bit confusing to me how the various state machine elements tied in with the software.
Jae Chang - Nov 20, 2006 12:35:24 pm
The article emphasizes the ubiquitous computing environment is needed in order to make the iteration process of the the cycle, UI prototyping, testing, and analyzing, faster. The article introduces “d.tools” that helps such task. I think one of the good features of “d.tools” is that the “d.tools” connects a computer to the physical device so developers can test and evaluate their prototypes seamlessly. I believe that this tool promises that developers can reiterate the design cycle faster so developing time can be significantly reduced. However, since this tools cannot be used for lo-fi prototyping, using “d-tools” does not have any benefit on the lo-fi prototyping stage; it is useful for hi-fi prototyping only. So, I think “d.tools” is good for building a product but not for UI evaluation.
Dexter Lau - Nov 20, 2006 12:50:56 pm
d.tools appears to be an amazing tool to link the rapid prototyping to the functionality of the system that we wish to achieve. One of the key features is the ability to link Java code to various states within the system. d.tools came about in order to check the correlation between the intended interface and the true physical systems created. It has the ability to log the activities of the users throughout the iterative process of HCI. Similarly, its abilities to deal with a group of testers and their results. By using it, interface designers now have can have a set standard to streamline the process of interface design to a very effective process.
Michael Mai - Nov 22, 2006 02:33:37 am
At first glance, the look and feel of this toolkit reminds me of Matlab for hardware. It incorporates many elements of good UI design, from ease of use and layout of the prototype objects to concrete representation using images and graphs. Referring back to Matlab, the API allows for creation of objects with dial or switch activation along with black boxes filled with code for customizable use. With the plug and play hardware feature, there is no limit to what pieces of hardware can be combined to create a successful system. This toolkit also draws directly into the cycle for product/interface design, with the design, prototype, analyze loop. The UI design and testing shows a steady learning curve for many users, although I feel that they should test the tool with people who do not have design experience.
The most interesting portion of the reading was the broad set of testing and analyzing features that came along with the tool. Using the recordings, data can be efficiently obtained by sources that are in a remote area away from the testers themselves. The flexibility of the statecharts allow for excellent organization and management coupled with the compatibility with the video recordings. With a tool such as this, the aggregation of data and turn around time for the next iteration of the cycle will be reduced drastically. Thinking it over, this can also be a useful tool for the creation of tutorials on hardware.
Aleksandr (Sasha) Ashpis - Nov 23, 2006 02:46:22 pm
- This is a very interesting idea, it is the first I have heard of merging hardware and rapid prototyping. I think this will be a great addition to mechanical and electrical engineers, not quiet as sure how big of a benefit this will be to software engineers. However, this will make it easier for some to become an electrical/mechanical engineer and dramatically shorten the time it will take to make a high quality product and bring it to market.
- Although the tool seems to greatly improve the time needed and quality of the analyzing step, with ubiquitous computing devices, I am not sure that one could build a new prototype quickly to continue testing and improving ones product, and to fully take advantage of d.tools. Just like in computers, something is always the bottleneck, the PC has gone through its cycles, where RAM, CPU speed, cache, hard drive, video cards, etc… have all been the bottleneck in personal computers, and money and research would be poured in and that bottleneck would be removed, only to be confronted with another. Where I am going with this, is that I don’t believe that the testing is the bottleneck at the moment of testing ubiquitous devices, and even though this is a good toolkit, I believe it solves a problem that is not there at the moment, but will however be in the future, which makes them ahead of the game, whether that is good or bad, is yet to be determined.
David Eitan Poll - Nov 27, 2006 08:50:56 am
This was an interesting paper, but I'm skeptical as to how it scales. It seems like it would not be uncommon to have HUGE numbers of states in any given application, all of which would need to be modeled in this visual editor. Even for a prototype, this seems like it could rapidly become unmanageable. The author even remarks that the number of states grows exponentially (w/ regard to parallel state diagrams). I have a hard time wrapping my mind around the notion of using something like this to design and prototype anything beyond relatively simple software applications. Editors would seem to be extremely complex (how many states would there have to be for anything with unlimited user interaction a la Word?)
At my internship last summer, I worked in a UI Framework group, and spent the whole summer helping to design a framework for rapid development of complex UIs for business. One of our benchmarks for the effectiveness of the framework was how easily one could build a number of canonical applications: notepad, a finance tracker a la Quicken or Money, and a pluggable component gallery (along the line of desktop widgets, but for an application). The goal here was to reduce all of this to something that could be done using a visual designer. The system also integrated with a Workflow manager, which has many similarities to what was described in this paper, but doesn't attempt to control UI. Instead, the Framework had hooks for the Workflow manager, which separated UI design and state transition into individual steps. I wonder how similar the design process was for d.tools.
Randy Hilarbo - Nov 27, 2006 09:45:46 am
i find dtools as a very useful tool in designing physical interface. The way it enforces design thinking more than implementation-thinking would accelerate the time of designing an interface. It is interesting how dtools integrates the design-test-analysis cycle when it itself seemed to have gone through the same cycle. The designers of dtools seemed to have really thought about designing dtools. Their choice of OpenSoundControl (OSC), for example, is affected by the availability of the API as well as the human readability of the adressing format.
i also find it interesting how dtools is built using existing devices and made it so that it addresses the aspects that are not addressed by similar tools. For example, it adapted SUEDE features that are very useful while supporting the video-tracking feature, which is not supported by SUEDE. The video feature of dtools seems to be really useful. I think that other areas can adapt this feature.
Qingyun Tang - Nov 27, 2006 09:26:55 am
The article starts with describing D.tools as some sort of tool kits that will help people to develop innovative ideas of designing. I didn’t realize D.tools was actually a piece of hardware until I read the detail. It is an integrated development environment that allows rapid development, testing, and evaluation of user interfaces. At first I thought this tool kit was just another flash-like UI with a fancy hardware piece. But to my surprise, after reading further through the article, the tool kit had much more advanced features and nice properties than I expected. D.tools actually could simulate physical systems and is not limited to just computer hardware. However, it lacks software simulation, which is a really important feature for software developing. But having these cool features alone would be a lot helpful for user interface improvement. I wish we could’ve used it for our project.
Keenahn Jung - Nov 27, 2006 12:20:14 pm
D.Tools looks like a really good way to bridge the gap between real world objects and the digital world. What I like most is that it provides a very quick way of prototyping the most common type of features you want in a device. Reading input from sensors and making decisions based on this input is pretty fundamental to any intelligent device, so it is great that D.Tools makes this really easy. I also like the idea that they device can be in several, orthogonal states.
Most importantly is the ability to use plug and play components and how this ties in seamlessly with the software package. We can quickly generate working, low fidelity prototypes that will actually resemble the final device. Our low fidelity prototypes were made with paper, so they did not really accurately portray the affordances of the mouse and keyboard and other input devices. Since the devices we can make using these plug and play components and d.tools are physical objects that actually resemble the final product (instead of paper), we can get much better user feedback during the low fidelity prototyping stage.
CharlesLeung - Nov 27, 2006 12:42:32 pm
It seems ilek this article deals a lot with physical hardware prototyping. Although I doubt that I will every attempt to design hardware in this fashion, it is interesting to read about how they go about designing hardware devices. I thought that it was funny to read that d.tools allow users to wizard of oz things if they do not want to exactly implement that feature as of yet. I also like how it trys to force the designer into thinking in a certain type of way. That probably helps the designer in the long run by focusing on what's important.
I thought that the group analysis part of d.tools was very interesting in that it kept video clips of the different sessions. Although having lots of video clips definitely can be useful, I think that for any sizeable project the sheer amount of video clips could make them kind of useless. It's like having a whole bunch of pictures in your hard drive, if you have too many clips, then it may be hard to find what exactly you're looking for, especially when there's so much footage.
Cheng-Lun Yang - Dec 07, 2006 10:17:10 pm
1.The d.tool is a good idea for user interface design. The software interface reminds me of Matlab which allows engineers to draw circuits and model their behaviors. The hardware interface looks like the circuit boards I used when I took CS150, the hardware design course. However, the learning curve is definitely still higher than pen and papers.
2.A user interface that helps prototyping hardware is more useful than prototyping for software. Hardware is harder to build and costly if not mass produced. Having a tool like d.tool to convert lo-fi prototype to more high level prototype for the designers to review is a big plus in user interface design. Some problems need to take into account is the interference of wires and chips in actual hardware. It can not be modeled correctly without real life tests. There is still limitation to how accurate hardware prototype can model.
Siyan Wang - Dec 07, 2006 03:11:58 pm
1.) This suite of tools seems pretty interesting and quite comprehensive for designing a viable interface. All the linking of the video with the different states seems reminiscent of the butterflynet application with Anoto, and seems like it would be very intuitive to corroborate the video evidence with the states. Such testing with such accurate measurements seems like it would be even easier than running heuristic evaluations or cognitive walkthroughs. One can simply begin to have users interact with the prototype and record them.
2.) I wonder if d.tools could be used to develop something like d.tools, or even improve upon it. It seems odd that the state transitions that the designer views every state are not context specific to the state, since that would seem more appropriate. However, these tools are more of a proof of concept instead of a perfectly designed tool. However, if they go through the iterative design cycle, I suppose they could have further improved their design.
Robin Franco - Dec 15, 2006 12:09:38 pm
Comment 1: I found it interesting how the developers used video and audio in their research for the tool. This non-invasive approach of information gathering is probably something that would have been nice to use in our own studies. It's beneficial in the fact that it allows one to observe the user in a more “natural environment”. Over the summer, I worked at Microsoft. In our product-testing, they video taped users interacting with the product. They were given a set of tasks on paper and then told to complete them. These videos were then accessible to the entire team to learn from. This form of user input, in my opinion, was very helpful.
Comment 2: D.tools itself is an impressive piece of software. Hardware is very difficult to test and prototype simply due to the processing constraints. By reducing the time it takes to test out a design, this reduces the entire design cycle, meaning one can afford to iterate through more design cycles which then leads to a better design. And a better design is the ultimate goal for developers.
