I can’t believe we are done! Putting together our final presentation gave me a really good overview of how our system actually developed and I was really impressed with how everyone (not just us, but all the groups) was able to reach this final phase from what started out as pieces of paper and cardboard.
The only thing that I really wish we had time for was actual testing and interaction with users. I remember when I was taking the HCI class last semester, the feedback from users was always very surprising. Although we as designers claim that all of our work is user-oriented, there are so many things that we fail to see from a designer’s point of view.
Our system is also still in its very initial stages and there is a lot of future work to be done. First of all, all the information in our system is canned. Given the time constraint, we had to keep it canned, but it would be really great if we could connect our system to a database containing all the artwork and exhibitions at the Davis Museum. Also, now that mobile devices are becoming tools that are beyond just calling devices, we could probably connect the interaction from the surface to users’ mobile devices and eliminate the need for printouts. Mobile devices can also be used for post-visit tools. We discussed adding a post-visit component to the system, where visitors, especially students, can save the information of their visit in their one-card (Wellesley ID cards) and access the information once they’ve left the museum. Instead of having one-cards, we could use mobile devices.. the possibilities are endless but I think a post-visit tool would be extremely useful.
The biggest value of this project and this course, I think, was being able to work with the Microsoft Surface. It was very interesting to read and hear about all the TUI research that’s been done so far but it’s really difficult to imagine the interaction especially since it is not a prevalent form of interaction, yet. Being able to work on the MS Surface, was a really good introduction to understanding what a tangible user interface and interaction really looks like and I feel really lucky to have gotten a chance to play around on it!!
Today, we presented our final project to the class and guests. We went over the entire design process, from our problem and user description to our very last design decisions and gave a video demo. Here is an overview:
Problem Addressed:
Our system was created to address several problems that the Davis Museum currently faces. One of the problems is the low number of unique visitors despite its diverse collection. Another problem is the current layout of the museum lobby and its inability to serve as an informative and inviting introduction to the museum.
We thought that these problems could be solved by introducing a surface in the center of the lobby that would enhance and personalize each museum visit. We targeted the needs of the most common visitors at the museum: Wellesley College students, faculty, and staff.
Description:
Our design has 5 key components: attractivity, tangibility, exploration, customization, and contextualization.
Attractivity:
As mentioned, one of the problems was that the museum was low in number of unique visitors. So we thought that it was extremely important that our system is fun and interactive so that it could serve as a tool to attract, not just inform and personalize. Although not implemented for the project, we also thought that the surface could be playing a fun animation or have an introduction screen that would naturally draw more users and visitors.
Tangibility:
We categorized the types of tasks that the users would accomplish and decided to represent those tasks using tangible objects instead of a GUI. This not only enhances the fun aspect of the interaction, it encourages exploration, which I’ll talk about next
Exploration:
We chose to implement our objects using a scatter view, not a structured tree, to encourage exploration. This also allows multiple users and visitors to collaborate and explore at the same time.
Customization:
In addition to categorizing the tasks, we added the tour creation feature so that each visitor can personalize their visit within the different tasks that they already chose.
Contextualization:
We allow the users to see how their personalized tour and tasks fit into the entire museum visit using this final feature: map creation and printing. As mentioned many times in the previous phases, we eliminated the “wizard-like” step-by-step interaction by allowing the users to see the map as it is being created. They just need to drag down the “footprints” from the top of the screen, which represents the tour map.
Objects:
This is how our final objects look like! As mentioned in previous project updates, we wanted our objects to speak for themselves. The first image shows how a course object would look like. It resembles and ID card, which all students carry, and has the assignment prompt is written on the front. This size and design would allow the objects to be passed out easily in class. The 2nd photo is of our tour object and the 3rd is of the printing object.
Martina, who was in charge of making these objects, said the following about object creation:
I chose to build the objects out of foam because I thought it was more dynamic then using the laser cutter or rapid prototype machine. I can easily build a CAD model to implement in either of these machines, but as I was prototyping the figurines I found that the process was dynamic, I was constantly building on my original idea, and it was hard to anticipate what something was going tofeel like in my hands unless I built it myself. That being said there are some really interesting services which democratize design by allowing common people to create professional looking projects. One such service can be found at ponoko.com
Demo:
For full documentation, click here. *if you are not connected to the Wellesley network and want to access the website, please email me for id & pw.
Today, Erin Treacy Solovey visited our class to give a presentation about a research she is working on, called Tern.
The basic idea is that you create program for robots using physical objects like wooden blocks. Since the shapes of the blocks already limit what kind of programs you can create, there is no such thing as a syntax error with Tern!
I thought that this is a really good example of the benefits of TUI over a GUI. I keep thinking about this because I know how reluctant people are to adapt to a different kind of interaction. Over Thanksgiving break, I was talking to a friend who works at a museum about our project and he couldn’t figure out why we can’t just have brochures and displays that would basically accomplish the same tasks as our system would. At first I thought the answer was obvious (the MS surface is so much more fun, the interactivity, exploration, etc etc) but then I don’t think it is for anyone that doesn’t know what a TUI is..
When you look at a system like the Tern, you can see clear benefits:
introduces the concept of programming to children who may not understand it otherwise
eliminates one of the most frustrating/difficult part of programming (syntax errors!)
still captures the essence of programming (program -> compile -> run) in a really fun way!
I think there is a lot of value in the novelty of our system and how it adds to the fun-ness and exploration component of the interaction. However, it would be really great if we had a chance to somehow measure or observe the benefits of a TUI. Erin mentioned how they observed the benefits of a TUI by testing a GUI-form of the system that uses just a monitor and a mouse. The difficult thing, she mentioned, was that there are some components that can’t really be categorized as one or the other. Either way, I think it’ll be really useful (and interesting) to observe the differences in interaction for a GUI-focused vs. TUI-focused system. Especially for something like our system where users aren’t familiar with what the interaction itself is “supposed to” look like… just a food for thought.
Not surprisingly, we still have issues with making our system as fluid as possible. Why is this so difficult! Although our system definitely improved from the last, it seemed like our system was still very wizard-y in the eyes of others. This only makes sense since we divided up the tasks in 3 distinct steps: explore, create tour print. After some discussion, we decided that everything should be updated live and accessible at any point in the interaction. So for example, as you are choosing exhibitions to add to your tour, the tour map is being created and you can view it any time by dragging the map down to the center of the surface. This should make more sense once our final prototype and demo is up.
2. Objects
We also did not address the problem of our meaningless objects. Our objects were currently just differently colored and shaped blocks that represented what we wanted them to represent. However, their shapes and colors had no relation to their actual meaning, making them completely NOT intuitive for users who have no idea what our system is about. So, we decided to physically build object that could tailor to the needs of our system and make them as intuitive as possible. We are still discussing what these objects would look like, but the goal is to make them scream out Courses, Exhibits, Tours, and Print upon FIRST glance and eliminate any extra description or explanation.
Professor Shaer also posted a really helpful video clip showing examples of how objects are used with the MS Surface. So many possibilities…
The goal of this project milestone was to present a horizontal (broad but shallow) prototype and a feasibility (narrow and deep) prototype of one particular part of your interface. We felt that the riskiest part in our system was creating a tour because the concept of customization presented through this feature is very novel.
Screen shots of prototype:
Prototyping process:
Our prototyping process for this phase looked similar to our initial prototyping and design process because we had to step back and re-create our storyboard. One of our biggest concern was that our system was losing the benefits of being a TUI and instead doing something that any GUI can accomplish. So we focused on making the interaction as fun, interactive, and fluid as possible.
The most difficult part of this process was actually dividing up the work and making a significant contribution. Before we got started on this phase, we listed all of the tasks that needed to be accomplished and divided them among the group members. Megan was in charge of the initial programming, Martina was in charge of creating and documenting our new storyboard and design decisions, and I was in charge of starting the overall documentation process by creating a website and also gathering and creating images we need for the floor plans and other interaction.
The difficult part came because this was all happening right before and during Thanksgiving break. And the more difficult part for me personally was that I was entering the final phase of my job search process, which required me to be off-campus and travelling almost everyday for the next 2 weeks or so. Luckily, communication was good and we were all able to establish our goals and tasks but I felt that the process could have run much smoother had we had more time. I didn’t feel too good about my personal contribution to the group; I wanted to contribute more especially in the programming aspect and be able to discuss our design decisions more thoroughly but we had to settle with sometime abrupt meetings and decisions.
Hopefully, the next phase will look differently for me, at least and I can’t wait to hear feedback on our prototype!
Because of the changes that we made after the feedback received (see P1 draft 2), we took one step backwards and re-did our storyboard to fit our new design. Here is what we came up with:
Location of the kiosk is the same: the center of the Davis Museum lobby.
Users notice 2 different types of objects: tours and special exhibitions. Users might come with a 3rd type of object (academic object) that they received from their professors.
Users place the objects on the surface and the relevant pieces and/or tours show up on the surface as a collection of scatter-view items. Concurrently, a “tour deck” shows up at the bottom of the surface. This is one of the features that was modified in order to make our system more fluid.
Users can explore the objects and the related scatter-view items (tapping on a scatter-view item will flip the item to show the information that’s on the other side). Users then drag the desired items into the tour deck to create their personalized tour.
Users can browse through the tour that they created and place the print object on the surface to get a print-out of the map of their personalized tour.
a very interesting way to group and visualize image search results. I can see so many potential for its use but the jump from surfing through the categories vs. surfing through the actual images could be improved. But it looks that that tree/stem graphic just works really for visualizing information and categories..
apparently there is another similar tool from microsoft called the bing visual search. I wanted to give it a try but it told me to I had to install ms silverlight or something to use it. I knew it wouldn’t be worth the trouble so I just stopped there. If you are trying to attract users, you should probably make the path toward your product as easy as possible, not add an extra annoying step!
“The Computer for the 21st Century” by Mark Weiser
Summary: Make computers an invisible part of people’s life by seamlessly integrating them into the world.
divert attention from a single box (like a monitor) and make the system aware of its surrounding
create tabs, pads, and boards that scale in different sizes (from post-it sizes to blackboard sizes)
pads are a cross between paper and laptop (think of them as “scrap computers”)
they need to be cheap, low- power computers (this is easy for the smaller tabs, not so easy for the bigger ones)
they also need to have software for ubiquitous applications and a network that ties all the tabs together but this is a bit difficult right now with operating systems that don’t have different hardware & software configurations for changing surroundings
this type of ubiquitous computing will prevent information overload and make more information available at our fingertips at any time, anywhere
“Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms” by Hiroshi Ishii and Brygg Ullmer
Summary: Allow users to grasp & manipulate bits by coupling the bits with everyday physical objects and architectural surfaces.
attempt to bridge the gap btwn cyberspace and physical environment by making bits (digital info) tangible through 1) interactive surfaces, 2) coupling of bits and atoms and 3) ambient media
emphasis on both foreground (hands-on interactions) and background (perception of ambient light, sound, airflow, and water flow)
metaDESK: use multiple phicons (physical icons) to control, eliminating the need for a single locus of control (like in a point-and-click mouse interaction)
ambientROOM: integrate background and foreground information into the activity using phicons and handles
transBOARD: digitally-enhanced whiteboard activity stored in hyperCARD; whiteboard activity can be distributed to users realtime and through recordings
Similarities
both systems aim to make computing integrated into the natural world by removing the focus away from a single source (like the monitor)
both systems still use tools (like tabs or boards) but they are digitally-enhanced versions of non-digital ools we use in our physical environment
Differences
the tab/pad/board system still uses a GUI-style interaction but the bit system uses already existing physical devices and augment them using digital technology
My Project & Invisible Computing Although our system may look very similar physically, the main goals of the systems are different. The main goal of the two systems is to seamlessly integrate computing into our physical space whereas the goal of our system is to provide a useful tool specific to a set of users with particular characteristics (in our case, Wellesley students) using a tangible user interface. In fact, our proposed system has been designed NOT to be integrated into the physical space, but rather to disrupt the physical space in order to guide visitor traffic to out system (this was necessary because the current layout of the museum often misguides the users). In a sense, our proposed system does augment reality by providing information and tools that are currently only available in the form of paper brochures and guides.
Although the focus of our proposed system has been to improve the informative tools at the Davis museum, we could easily expand the goal of the system to invisible computing as well. If this were the case, it would make a lot more sense to integrate our system into the museum floor space (where the galleries and exhibitions are) instead of the lobby space. Then, ideally, viewing the artwork/galleries and getting the information (currently provided through brochures) would become one, single interaction, rather than multiple interactions (maybe by using something like the tab, since most students tend to carry out small notebooks to take notes anyway) while still retaining the museum experience as well.
Today Google announced some of their design concepts and documents for their operating system, Chrome OS. I wanted to post this because their documentation and the design sketches looked very similar to the kinds of documents and sketches that we were creating in our project planning process (except much more detailed and.. complete, I guess) and I was encouraged and inspired that what we are doing applies to larger-scaled projects like operating systems and so on.
anyway, go here to take a peek at the Google Chrome OS. and here are some of their (very thorough) design documents.
After we presented our ideas in class, the general feedback that we got was:
the concept of the “objects” was too vague and confusing (do they represent exhibits or specific works?)
we should more clearly identify the users – are they students? are they general visitors?
the tour “reel” and the visualization of the tour add unnecessary extra steps for the users — the system should eliminate this
there are too many options and choices with the current system; by identifying the users, we should be able to make more choices for the users
to what extent are the physical tokens beneficial? why not use just digital information?
I think this tends to happen a lot during the first few design phases.. the designers get too enthused about the system itself that they fail to see it in the users’ perspective. After hearing some of the feedback, I can see that our system failed to address the needs of any specific user because of its broad-ness. so…
we came up with the following modifications:
Users: We narrowed down our user group to Wellesley College students and our system to be specific for the WC Davis Museum
Objects: We narrowed down the objects into 3 categories of objects:
1. Academic objects – these are obejcts that have been pre-defined outside of the museum by professors. They will contain information about pieces and/or tours that are specific to an academic course
2. Specific exhibition objects – these are objects that represent specific exhibitions that are being held at the museum. These will contain information about pieces in the exhibition, related exhibitions and tours. These can also serve as a tool to promote and/or attract more users to the ongoing exhibitions. We also discussed the possibility of extending the objects to something that can be printed and brought from home. Users can pre-browse ongoing exhibitions through the website and print out a map or information card that can serve as an object that is recognized by the surface.We decided to add this category of objects to address the problem Jim mentioned regarding the plasma screen display that is currently at the museum. The current display limits the curator and museum directors on what information can by displayed and these objects can serve to provide more flexibility in displaying the desired information to the users
3. Pre-determined tour objects – these objects represent a tour that has been pre-determined by the museum curator. Most likely, these tours will be for permanent collections at the museum and will not be changed very often.
Tour card: We elimited the tour reel. Once the user places objects in the tour card, the system will generate the tour based on the optimal distance between each work. Users can still manipulate the tour on the next step when the tour is graphically displayed on a 3D blueprint.
Post-visit: One of the comments we received was a possbility of using onecards (Wellesley student ID cards) as a token. Based on this suggestion, we decided to add RFID readers to each artwork, where each visitor can tap her onecard and store the information for post-visit tool. The onecard would store information about all visited works that can be accessed through the surface and sent to the user via email.
