PREFACE
This document is written to capture the ideas which have grown and to provide documentation on the Lones Widget, a project of second-year Interaction Design students connected to the faculty of Art, Media & Technology at the Utrecht school of the Arts (HKU) in the Netherlands. The basis of this project was formed in an earlier project, Lones Intimate Stones, accompanied by Ben Schouten at a conceptual level and supported by David Kousemaker and Tim Olden from BlendID on a technical level. The aim of this second project, guided by David Garcia, is to take the previous project to a higher level without losing the created values. For the first project we only had one week in which we thought out the concept and played around with sensors and software. We wanted to make a working prototype as well as a little scenario-movie, visualisations and documentation. So we were able to add another week to work on that. This second project was planned for Thursday and Friday during seven weeks, but to make things work we all did a lot of extra work beside those two days. Everyone agrees these two projects contributed a lot to our developments and we are thankful to those who supported us achieving this.
Arne Boon Jan Jonk Ruud Burger Nikki Veldhuis Raïm de Reus Rajeev Siewnath Aduen Darriba Frederiks Lode Claassen Roy Oostwouder Interaction Design 2 HKU 2007-2008
TABLE OF CONTENTS
Introduction Lones Intimate Stones project Lones Widget project Deliverables Concept Description Action representation Action scenario Discarded concepts Technical Lones hardware Transferring data Widget Reflection Aduen Lode Nikki Roy Raïm Arne Rajeev Jan 3 4 5 6 7 8 10 11 14 16 20 21 22 23 24 25 26 28 30
INTRODUCTION
Lones is all about intimacy and how to stay intimate when love has to bridge a physical distance. We have tried to find a new kind of communication between lovers, using stones that represent certain values and meanings through physical expressions. From this concept we also made an information visualisation of the relation, according to the actions between the stones. Hereby Lones consists of two integrated projects: the first project formed the basis and the concept of Intimate Stones. In this second project we took the concept to a higher level and developed a widget to elaborate and support the stones. The first project was rooted in Ambient Intelligence: as a result of the computing technology that becomes ever smaller and cheaper it is now possible to integrate it into everyday material objects. This advanced integration of technology allows the computer to disappear into the fabric of life so that by manipulating material objects we are transparently interacting with the underlying integrated technology. The invention of wireless communication technology enables these integrated computers to cooperate with one another so that they can derive context about its environment. In this way technology can react on the needs, habits and expressions of people. The advantage is that users can be supported more naturally and transparently to achieve their goals. This follow-up project was about how to make the Lones stone more sustainable and less a gadget object by adding a service layer. In our case a graphical visualization of the interaction history between two lovers. Service design projects improve factors like ease, satisfaction, loyalty and efficiency right across areas such as environments, communications and products. This document covers the different aspects of the Lones Widget project to understand why we developed it the way we have, which metaphorical issues are involved, the technical solution and how to use it. But in order to do so the previous project Lones Intimate Stones is discussed first.
LONES INTIMATE STONES PROJECT
The assignment for the first Lones project was to imagine two people deeply in love but separated by distance for a longer period of time. With the challenge to design an intimate, personal, wearable object that helps their love transcend space and time. This design should use technology to communicate feelings of closeness or other emotions between our lovers. The following keywords were to be considered essential: ultra portable, communication, intimate and personal, physical experience, fashionable. We started thinking about being in this kind of situation, what could be an object that people would embrace as an intimate connection and allocate with personal values. We all agreed it shouldn’t be any device or hi-tech instrument. But more like a necklace, medallion, amulet or a ring – which are icons of personal values and objects preserving deeper meanings. However we faced a challenge since these objects already exist to provide intimacy. We came up with the idea of stones. Each stone has a unique shape, which facilitates a personal binding. Stones are solid and indestructible, in this way a trustful companion. Stones are very natural, they got nothing to do with technical stuff whatsoever. Stones are physical objects to hold in your hand and caress. And a stone can easily be put in a pocket or taken along in a ladies bag (or a special Lones bag). We concluded that stones would be the ideal objects for our requirements. The name Lones popped up immediately, it comes from love, stone, love stones, alone, lonely, the one. So with a pair of stones, one for each of the two partners, we got well-suited objects. The connection between the two lovers will be going through these stones. They can communicate with each other by practising physical expressions. These expressions are the shaking, smudging or cherishing of the stone which are reflected at the other stone as quavering, coloration and brightness of light. The information is only sent across when the stone is touched by the sender. For example, when the girl picks up and shakes her stone, the stone of her partner will quaver. This can be interpreted by means of drawing attention or expressing physical effort or excitement. The boy could react to this by shaking his stone, which leads to the quavering of the girl her stone too. He could also heat up his stone by smudging it, so the girl her stone changes color to red, which resembles sharing warmth. Or he could embrace and caress his stone so her stone starts to lighten up as a representation of his love shining for her. Sharing these expressions caused by emotions provide an intimate flow of contact, especially because it all happens real-time and it crosses any distance. It could possibly lead to a secret language between our lovers. We’ve built a prototype of two stones that are actually communicating these expressions. Together with the documentation, a scenario movie and visuals of the stones we finished the previous project.
LONES WIDGET PROJECT
So with this sturdy foundation the following project was about to take the Lones Intimate Stones to a higher level. How could Lones be developed as a service instead of a gadget? How could a 2.0 web interface or another software application make this happen? Can we broaden the concept over different disciplines without losing the values? Finding new ways of collaboration interconnected through technology, what is the role of design contributing to this collaboration? Things can’t survive in isolation, in that sense collaboration is essential. Could we build relationships on a community basis? Find new forms of doing this, but without losing your own background or territory. With these questions and statements David Garcia asked us to reflect this on Lones Intimate Stones. We started thinking this over. The values created in the previous project were those of intimacy through a non-technical object providing a sense of physical contact. Expressions through physical actions using metaphors of warmth, excitement, attention, light, cherishing and caring. And the possibility to share these meanings real-time over any distance, without pressing any buttons. Those are the core values to preserve. At first it was a bit odd that we had to think about the collaboration between the Lones stone and a desktop-computer because this is exactly what we wanted to avoid. We didn’t want to make some account based Internet community with an online dating facility and have the Lones Stones become a sort of Dating Stone. Nor did we want to have our lovers doing things like logging in on a site and invest time being popular and have many hits or messages in a community. And about the Lones Stones, we would like to make it possible to share more and be more involved with each other to make the intimacy more intense. However, they should stay stones and not become a hi-tech digital camera with integrated telephone and sound recorder as wireless email clients replacing existing devices. In order to keep the Stones stones, there is another device needed to deal with the software application. We did some thinking about how to handle this problem and we found a solution with the earlier loathed desktop-computer: let’s make a widget! A widget engine is the host of a software system for physically inspired applets on the desktop. It typically provides easy access to frequently used functions or provides some visual information. The making of a widget offers the Lones Intimate Stones a new dimension in the digital world. In our case we could feed it from the physical world as an extension of what is happening out there. It’s not asking for attention but can be easily accessed any time. It is an intimate piece of software because it’s unique at the owner’s desktop like it is nowhere else. And it offers us as developers a platform with a wide range of possibilities. Further on is explained what the concept with this widget is precisely, briefly worded the Lones Widget is about information visualisation of a relation. For more information you can check the chapter “Technical - Widget“.
DELIVERABLES
We determined what our deliverables would be for this project to work on. We came up with this list: • • • • • • • • Two hardware Lones, translating the physical world with sensors. A database filled with data from the lones. A widget which visualises this information. A functional design for interaction with the widget. A jottit-page keeping track on the developments: http://lones.jottit.com. Project documentation. A website with url http://www.lones.nl to present the project to the world. Promotional video showing the interaction between partners.
CONCEPT
DESCRIPTION
The Lones are a means to share intimacy over long distance. Because no verbal or linguistic actions are required, the artifacts are able to communicate meaning more interpretively and emotionally. To make the experience more tangible we’ve created an online service that visualizes the progress in your relationship. Our widget sits unobtrusively in the corner of the desktop and doesn’t report on activity until the lone is activated on the screen. When this happens, two entangling vines shoot up from behind the lones, each vine representing a partner in the relationship and it’s colour corresponding with their Lones’ colour. The vines will generate sidebranches and flowers depending on the interaction that takes place and they will entangle one and other whenever this happens. When the lones aren’t being used the branches will grow upwards in a winding fashion without entangling each other. Metaphorically this means that as there is no interaction the relationship grows apart. Our hypothesis is that a relationship grows over time and that the fullness and reward of such an experience can be visualised in something that resembles natural growth. The winding growth of the vines directly resembles the amount of movement done by it’s owner. The more he or she travels (and carries the lone around), the more his or her vine will twist and turn. But when one of the partners innitiates communication through the lones the vines will instantly grow towards and wind around each other, representing their connection at a distance. Flowers are the offspring of direct contact between the two partners. When a lone is touched it instantly generates a sidebranch onto where flowers can grow. A shake of the lone, as our means of communication, creates a bud on the branch. This bud can bloom into a flower if there is a reaction from the partner. In this way patterns of branches and flowers are formed. The lones widget communicates quality of relation through quality of reaction. Through the use of time-frames, actions can have a set of different outcomes depending on the speed of the partner reacting on an event. For instance: the size of a flower is dependant on the speed with which the partner reacts to a buzz from the stone. Other visual elements need similar interactions to evoke them. But the purpose of our widget is not to create the most beautiful flowering tree or winding vine. The visualisation is merely reflective of the actual relationship and should be viewed as such. The visualisation of the winding vines with it’s branches and growths works as a reflective tool. Instead of fleeting moments of communication there is a time-based digital structure with an organic feel. A structure that remains after the fact, that has events chronologically placed and can be used to look back at days or even months past. A personal history of your relationship.
CONCEPT
ACTION REPRESENTATIONS
Trunk • After the lones are connected to one another, two trunks are formed and start growing from behind the lones. • The growth of the trunks is continuous in height over time, meaning that however a person moves or initiates action doesn’t have on effect on the height of the trunk. • When a sidebranch is formed, the two trunks grow towards each other and entangle one and other. • While a sidebranch is formed and grows, the trunk will keep growing. • The winding of the trunk is influenced by the GPS module inside of the lone. • Events on the Trunk • A singular event occurs when the partners meet each other physically, this is visualised by an open flower that looks like an eye, branching of the trunk. • A thorn indicates the end of the day and the start of a new one. • A longer spikey thorn indicates the end of the week and the start of a new one. • A pale flower (reminiscent of a moonflower) indicates the end of a month and the start of a new one. • A crowsnest with a blinking ring in it represents the end of a year and the start of a new one. • The distance between the thorns on the trunk varies because the trunks wind individually. • The thorns are placed symmetrically, first inside on the one trunk, then inside on the second, outside on the one, outside on the second, etc. Sidebranch • A sidebranch is generated on the trunk of the touched lone. • The branch will grow for as long as the touch lasts and will wind upwards. • On the sidebranch buds form in place and time, the branch will keep growing after initiation of budding. • The branch winds a bit and ends with a curl when touch is stopped Bud • When the lone is shaken a bud is formed on a sidebranch of it’s trunk. • The lone of the partner buzzes. Timeframe • When a bud is formed a timeframe starts. • This timeframe is a time-curve that lasts for 12 seconds. • The first part of the timeframe is critical: the firsts 3 seconds. • The second part is the late timeframe and lasts for 9 seconds.
Late Timeframe Actions: Budding Flowers • When there is a reaction from the partner within the timeframe, the person that initiated the communication will have his bud grown into a flower, the reacting person will have a bud formed, a new timeframe starts. • If the initiator now engages the stone again within the timeframe, the bud on the partners branch will bloom and a new bud will form on his or her own branch • The size of the flower is dependant on the fase within the timeframe in which the reaction took place. • The distance between the buds on the same branch is also set by the fase within the timeframe in which the reaction took place. Critical Timeframe Actions: Bearing Fruit • when there is a reaction from a partner that takes place within the critical timeframe a maximum sized flower will bloom from the bud. • When the initiator reacts on the reaction gotten, and this reaction again takes place within the critical timeframe, the partners bud will bloom to its maximum size, but instead of getting a fresh bud on the initiators own branch a piece of fruit will grow beneath the big flower. Glow • The lones communicate temperature at touch and shakes. • When a sidebranch is formed, a bit of glow surrounds it. • The colour of the glow is dependant on that lones’ temperature.
CONCEPT
ACTION SCENARIO
A sketch showing a scenario of how the tree and its branches will act on what condition. Short translation list: Resultaat van handeling Aanraak Schud Ruim tijdsframe Blijvend Result of action Touch Shake Wide timeframe Continued
CONCEPT
DISCARDED CONCEPTS
In our proces to visualize what the widget would do and look a lot of different concept were tought of. After David spoke and warned us not to make it too effeminine or too sissy, we had a break of confidence in our concept and there were a lot of heated discussions. Many concepts were thought of and discarded, some are listed here. Sidescrolling Graphic’s Chart Visualising the lones-events through a graphics chart that scrolls sideways from right to left. The metaphors chosen are those of natural growth. The height of the graph is represented by the height of the plants. Previous days are seen on a blurred layer in the background. It’s possible to scroll through these layers to revisit previous days. Technically this was very feasible but it was decided by a majority vote to discard this concept as it wasn’t very visually interesting and would become too generic too fast. Lones World The Lones Widget visualised as a little world. The combination of events would be represented by a collection of objects and animations on the lone. Every day starts a new little world that will be filled in at the end of the day with all the data compiled and generated. Each lone world has a small path running over the length of the stone. When previous days are revisited stones are put next to each other and an animated couple (representing the users) walks hand in hand over the path from stone to stone, through the landscape they created with their actions. Optional user generated content. Users can design their own objects and upload them to a database on a central server. Users can choose objects or categories of objects from a database to display on their or their partners lones. Objects can be tagged and those tags translated to the combination of events possible with the
lones. This was a very complex to execute process with a lot of questions surrounding it. Visually it was well received but technically it was too hard, required too much work and wasn’t interesting enough to make. Topview Lones Dam The Lones put next to each other in a small stream that cuts off the water’s flow and makes a little pond wherein life can flourish. Every day would see a new pattern of plants and animals. Events from the lones are chronologically visualised in the pond, meaning that an event is placed on the diameter of a circle and these follow up on each other rotating clock-wise. Plants and flowers represent hard events (touches and shakes), animals and differences in surrounding represent soft events (light, temperature and gps). Visualising a relationship as a clock wasn’t a good starting position. Scrolling through past days couldn’t be conceptually accounted for. Discarded. Lones River The Lones, rolling through a river as stones do. An event let’s the stones hit each other and cause cause growth in the river, sparking life all around them. Hard events cause plants to grow in the river and on the river’s edge. Soft events cause schools of fish or big predator fish around the lones. Previous days are viewable as an animation of stones rolling through the river, picked up by the current and sparking life all around. This was too similar to the original concept and it was discarded in favour of working on the original concept and limiting changerequests.
Lones Castles The Lone as fundament to build on. A nudge to being the keystone of a relationship. Every day is represented by a single tower with an animation. With each day a new tower grows on top of or from an adjecent tower. Each tower tells a little story between two lovers; they quarrel, they fight, they make up, they love, they dance, they live their lives. There is a clear narrative and it’s very visual storytelling, but there is no generation of data from the event’s on the lones. Basically it’s counting events and pasting the proper story on the tower.
Lones Castles II Random generation of towers and spires. Every hard event makes a new tower appear. Soft events are represented by glow coming out of windows, growth of mos on the side of the towers and beams of sunlight. A bridge corresponds to the beginning of a new day. The castle metaphor and visual style was deemed ‘too disney’ and discarded. Coral Lones To keep the visceral feel of stone in the widget instead of the conceptually weak intertwining vines, coral was put forth as a solution. By using coral we’d have to link everything to oceanic metaphors. The colours associated with this were also deemed too sissy. This was discarded.
TECHNICAL
LONES HARDWARE
The Lones stone has been made in the previous project. The heart of the stone is the Arduino. The stone is fitted with four sensors registering user input. The four sensors are, light, touch, vibration and temperature.
Human action
Stone touch Stone shake Stone rub Stoen caress
Input
Touchsensor Vibrationsensor Temperaturesensor Lightsensor
Output
Shakemotor Color hue Color intensity
Effect
Stone activated Other stone shakes Other stone changes color Other stone colors more brightly
So every action with the stone is registerd by the hardware and software. In this project the software also sends the information even further over the internet to an online database. For more information on this you can go to the chapter “Technical - Transferring data”.
This graphic shows how the different sensors are connected to the Arduino.
TECHNICAL
TRANSFERRING DATA
The program called “Lone Connector”, written in Visual Basic 2005 with the aid of the Visual Studio environment. This programm will look for a connected Lones stone(Arduino) and a database to which the stone’s data must be sent and stored. If the program is unable to find either one of these it will not function. When a stone is found and a connection is established with the database the program can be started with a button. This button exists for debugging purposes only. When the program will exceed its beta status the entire interface will disappear and tje program will run on the background without any required user input.
Beta version of the “Lone Connector” interface. This interface will disappear in the 1.0 release.
On the next pages you will find diagrams showing a schematic view on the way the data is transferred from Lones to the database and, eventually the widget.
TECHNICAL
TRANSFERRING DATA
The diagram above shows how the “Lone Connector” works. Once it has been started it will start searching for the Lone and the database. If either one isn’t present, the program will return a false and will not function since no connection is established.
This diagram shows that once the Lone and database are found and a connection is established, the program will open the computers COM port and transfer data. The database is opened and if the proper conditions are met the data is transferred into the lones.nl database.
In this diagram we see how which sensors are connected to which input. The Arduino then outputs the data to the computer where the data is sent to the database over the internet.
TECHNICAL
WIDGET
The idea for our widget was to make a service layer for the Lones project. We decided on a visualization of the interaction. Two lovers share information about how they interact with their stone (duration, which action is undertaken, reaction on each other). We wanted to make this visible for both partners. As you’ve probably read earlier the result was a growing tree. In the chapter “Concept - Description“ you can read all about the possible actions and the graphical results of these. The Lones Widget is a small desktop application. The widget is made with Flash Actionscript 3 and Adobe Air. The widget extracts its data from the database to which the Lones stones are connected. This information is retrieved from the database, processed in the program code and when the script is done the information will be shown as a representation on the tree on the user’s desktop widget.
REFLECTION
ADUEN
My task was to write the software in order for the Lones to communicate with a database over the internet. I have never done this before so it was quite a challenge. First I looked for a suitable scripting language which is supported by both the Arduino and the database. Java and C where tried but eventually Visual Basic seemed to the easiest language to complete the task as efficiently as possible. I don’t think Visual Basic is a language in which I’d like to specialise, but I do think it will help me to take the step next time to use a more sophisticated language like C#. The project helped me discover these possibilities and I got to spend a little time with a few languages. Overall we had our difficulties in the project. Our design process wasn’t structured well enough and not everyting was clear to everyone. The outcome is that we didn’t get the coördinated good result we had hoped for. When I asked about this, David Garcia mentioned that a totally structured and precisely coördinated process is something we shouldn’t be aiming for at the moment. He felt that we did very well for second years and that the process is more important in the coming years. This year was more to just be creative and make what we wanted. I don’t agree with that and I think it’s more interesting to structure the process, especially this year. That way we’d get more experience and learn more which will come in handy in the coming years. The messing around was more something we should have done in the first year, not in the second year. Overall my opinion about the project isn’t all that positive. Mistakes were made with which we were already familiar with from reading literature. For most mistakes we even know the way it should have been done. To name a few mistakes I noticed: no defined usergoals using persona’s and scenario’s which resulted in us designing for ourselves. We also started building the object without a clear functional design and because of that a lot of the specifications were unclear to most people even in the later stadium of the process. The next time I would like to see more structure in the process and avoid the familiar mistakes to have more time and space to make new mistakes (and to learn from those).
REFLECTION
LODE
At the start of the project I helped in shaping the concept. When people began with their individual tasks I lingered at the concept with the conceptgroup. I worked on the concept for about one and a half week. I liked to think about all the conceptual things and I didn’t have a special task to do. This situation lasted a little bit too long and I didn’t feel entirely at home in the conceptgroup. I asked for specific tasks to do. I got the immediately. At first this pleased me, looking back now it was a bit too much and too undefined and loose which resulted in a few tasks not being finished. The first big task I got was to write PHP code to support Ruud (working on the Flash actionscript widget). I was asked to create fake GPS data (and later also a simulated Lone stone) to feed the Widget with fake data for testing purposes. After a week of working on that Ruud started working with the data and we discovered that it wasn’t enough. So I continued working on it. At first I was really annoyed that things were going this way. We had spent a few weeks working on the concept and thinking about every aspect. But when I stared building I found more and more things that were either missing in the concept, unclear or just wrong. That feeling passed away when Bart Barnard (teacher HKU) came by to check on us and told us that this is something you can (and will) encounter. The iterative production process. I felt better after that.
REFLECTION
NIKKI
Overall I feel the project went quite well. We had a lot of discussions and the result is a good product. The discussions went on for too long sometimes though. We lingered too long at some points. I think it was because some people had their own vision on how the project should be done and that made the expectations rise a bit too high. I think the whole idea of the tree as a metaphor for the growing of a relation was a great choice, but I think that we, as a group don’t have enough professional experience to get to a good looking solid product. There’s not enough knowledge about the scripting languages and integration. The possibilities of the Arduino (read: budget, little knowledge about the scripting and possibilities of the sensors) were also very important factors. Maybe we shouldn’t have continued with the Lones project, because I feel that Lones was already a good concept on its own. Nonetheless this project has been helpful to me, certainly at the conceptual level and the user interaction. David Garcia was very inspiring and has a noticeable amount of experience. It would have been nice if we had more time to discuss and talk as a group with David.
REFLECTION
ROY
Project 6 has been quite a ride. Working in this group is great. We all know each other for one and a half year now and even though we can discuss quite ferociously we also can work out almost every problem in a good way. Though some discussions were seemingly pointless and way too long, I really enjoyed them and just seeing how people can suddenly have a lot to say. I think it has been a good lesson in how to communicate as a group and how a good leader can have influence in the process (and is really needed). The moment where David came around and told us his opinion about the direction the graphics tended to go was quite amazing. He gave his opinion and told us that, given the available time and our hard work we didn’t need to change it. He was just making a point which we had to realise. Always know what you are doing and why. Pick a direction and go that way and don’t do things only half. After he left the whole group was in chaos and suddenly people were claiming that we needed to change the cocnept. Which was a complete misunderstanding of David’s words I think. But nonetheless we had a huge discussion and the group kind of split into two. One wanting to stay with the current concept and one wanting to change it and having a “clear” idea on the graphics to be used. Finally we decided to stay on the chosen concept and we worked further. Still, it was an amazing switch in mood an work motivation. I shared the task of manager (although Arne did all the important work because he is so driven and on top of everything before I even started to think about it) and the task of wildcard. Some way in the project I had the feeling that there was nothing for me to do because other people were better at it. And even though you want to learn stuff, you also want the best final result for the group. But not doing anything was more in my head than actual reality. I helped a lot with the concept, I assisted people when needed (graphics, even a little technical) and in the end there was suddenly a lot of text to translate and the whole document to design and put together. The whole design process went quite horrible. Nonetheless we got through it and made something we can be satisfied about. I think everyone is quite satisfied with his role and we all did our best to fulfill the roles as good as we could. The discussions went a bit out of control every now and then, but it’s exactly those discussions which were really helping us out. I learned a lot and the ideas that spawned from those sessions are quite interesting I think. And sure, the process could have been more structured and defined, but I think we shouldn’t forget that we are all creative minds and (I think) none of us have the ambition to be a leader/ manager. So for creative people I think we did well, and Arne was doing a really good job when the project was a bit further.
REFLECTION
RAÏM
During project 6 our idea was to expand Lones. We were askde to make the product more sustainable by creating a service layer (web interface in our case). David Garcia was our support and aid with the conecpt. Personally I feel that this project has been very helpful, because it gave us the space to think about the interaction between the stone and a desktop/web interface. David was motivating and brought good point which we were albe to consider. He helped us think outside the box. The roles were divided quite smoothly among the group. The concept phase progressed very slowly. We started to think about the concept with the entire group but at a given moment we got stuck. We tried to solve problems in a democratic way so that everybody could say what was on his mind. We should have made decisions in an earlier stage. It took us a week or 5 to get a good idea. Then we had to get more details right and there wasn’t much time to do so anymore. It didn’t help that somewhere in the project David critisiced our graphical approach. Suddenly there was chaos in the team because everybody started to doubt the concept. After a heated discussion we changed the graphics, but we stayed true to our concept. Together with Nikki and Jan I got to work on the design. I really enjoyed doing that. I know now that graphics design is what I want to do. I get better at it and I have my own style. With Nikki and Jan I made some really nice things and we thought very well about the graphics. Together we thought about how the desktop widget should work/look. The result was a growing tree on a riverbank. The tree is fed by the two Lones. We went on visualising the tree (went from a climbing plant to a fullgrown tree). I made multiple sketches and an animation detailing how the tree could grow on the desktop. With these as a foundation we picked one to use. Nikki started working on the tree and its animations (flowers, buds, etc.) and I worked on the widget design. After that I got started on the design for lones. nl. Working on the website was a refresher course to see whether I was still able to design a website. In the end it all worked out fine. I enjoyed wrking on this product and I feel that we’re all satisfied about the result. I learned a lot about graphical design, design software and working with a drawingtablet.
REFLECTION
ARNE
Right from the beginning of the project I felt very inspired and curious of what would come out of this. The choice of making a widget was an interesting starting point. As we started thinking of what we could do with this widget, David suggested one or two people taking the position of a manager. I had already shown a lot of initiative and was very enthusiastic in the group conversations so I figured this task would be suitable for me. I stood up together with Roy and the group agreed, so we both took this task upon us. I actually didn’t have any idea on how to divide this position and somehow it didn’t really work out for me to be one-half of a central point. I found that my partner didn’t take the role as initiator or standing up to take responsibilities. Maybe to blame on me because I did so and was on top of everything. We should’ve had a proper conversation on how to do this together right from the start. As a manager I tried to lead the discussions, initiate issues to talk about and to come to decisions with the group. But most of the time I was too involved in the discussion to lead it. And I suppose I was too democratic by trying to make every decision one that the whole group supported. It seemed like I wasn’t capable of leading a group of nine individuals who all have their own creative ideas, including myself. But on some fundamental issues I didn’t see an alternative than to discuss it with nine people because it would heavily affect the direction in which we would go as a group. I grant everyone to be a part of the project and its fundamental decisions. I don’t want to be a dictator delegating tasks or making decisions half the group disagrees on. So there were discussions that seemed to last forever, with a lot of arguing and time-wasting conflicts, but everyone had the chance to have their say. So in the end we did have an outcome everyone agreed on. In that way it seemed inevitable to go through these conversations. I guess in a professional context this is not how to handle it. Further on, the project finaly started to take shape and as soon as it was possible I tried to divide the group into smaller groups covering different aspects to have smoother discussions. This worked way better and as a central point I had talks with the groups apart. Together with the different groups I made a planning of what every group and individual would work on. I trusted on the autonomous insights of individuals to take their responsibility and manage their own tasks. I made lists and agreements covering who would work on which tasks and it did seem to work, but it turned out be too lose and undefined for some people.
When the project progressed I thought to have more grip on what was happening, but I was up-to-date of the progressions and not ahead of it - only planning on short terms. Besides all these shortcomings as a leading figure I learned a lot and kept the log of our developments (lones.jottit.nl) up-to-date. I did a lot of conceptual thinking with Jan. I took a big share in the documentation. I provided the content for lones.nl. I prepared the final presentation. I have been critical to the work of other people to make it better and sometimes I actually was useful as a manager or communication window between different groups or individuals.
REFLECTION
RAJEEV
Project 6 was a very pleasant way for me to recap all the things we’ve learned the last seven weeks at school, but even more about working in groups (you never seem to learn all of it). It was a nice ride going from idealistic concepts to a working prototype. Most of all I enjoyed the commitment of the entire group to the project. The heated discussions, the hard labour, the team spirit. It’s the proper way a project should be executed in my opinion. But enough mushy talk. Once a meagre concept was set up in the early stages. I volunteered myself to take care of the technical aspects of the Lones add-on. This was making proper communication possible between the Arduino module, which is used as input for the add-on and the computer. But before I began with that part I was assigned to create a user profile. But for me it was a bit weird to make a profile of a user. The reason for this was that Lones already existed. The add-on we were about to make was already based on a piece of hardware that already had (or should’ve had…) a defined user group with additional user goals. So I deliberately didn’t put too much effort in defining something that supposedly was already there. I felt that creating an entire new user profile would make our new product clash with the old one, making its overall compatibility weaker. Do I regret this? No, but looking back to project 5 and this project I see we should have defined our user much more concrete, detailed and much earlier. Despite our user analysis was poor, I think in the end it wouldn’t have affected the outcome of this project. The tree was bound to be created in a manner we felt most comfortable with. After this I committed myself to making the Arduino send proper data to a computer and catching this info. I did this with Aduen, because the project managers distributed tasks to couples or triples. Which was an excellent idea. Working with the Arduino was fun at the beginning, but took a much darker path over time. This was the second project with the Arduino, but this project ran parallel with another course where we’d use the Arduino. Which makes this the third project. For a second project it was still fresh enough to explore, but for a third it was getting old, not to mention the fourth arduino project next semester. I regret my role in this project a little bit. I have some skills in programming, so working with the Arduino seemed like a perfect role for me because I understand it, but I’d rather had chosen to do something completely new and explore a bit more, getting thrown in the deep. But there is always a next time. The creation of the concept was the most exciting part of the project for me. This was probably the hardest part of the entire project too, because all of us were involved in it. So coming to an understanding was quite hard.
At some time we even had a sort of split in the group (trees versus landscape!). But this was another excellent approach of Arne, and I would like to do it like that again if I had to do it all over. Most of the time every small group was doing his own thing, but when it was time to discuss the concept everybody was involved. Which is really important, because everybody involved should feel comfortable with the concept being created. It may take a lot of our time discussing back and forth, but good things take time. Working in small teams was the thing I appreciated most about the entire work flow. Because while you have enough room to work in your own area of a project, you always have someone who is watching your back, this saves lots of time (especially when you’re a programmer, didn’t see that typo you made? Luckily your co assigned programmer did!) and really improves your ability to solve problems. Though I felt a little insecure about the outcome of the project (whether we were able to realize everything in time), this feeling vanished when I saw everybody slowly tying up the knots. The guidance of the project managers was very supporting. Whenever you got lost in your work and had no idea what’s going on, Arne and Roy would put you right on track and I really appreciate their monitoring the entire project the entire time. Overall this was a very successful project in many ways. Personal growth, teamwork, recapping the entire semester, and a kick ass deliverable. It had it all. I want to thank all my colleague students, and David Garcia for this experience.
REFLECTION
JAN
The project took off with a blast. Everyone was very into the whole Lones thing. We were happy with our succes in the previous project and were eager and motivated to bring it to a higher level. It was quickly established that we’d make a widget for the lones that would visualise the use of them. I missed the first meeting but thought it was a great idea. I came up with some concepts involving vines, but quickly in the group proces the idea evolved to intertwining vines or trees with actions representing growths on the trees. David came in and liked the idea so we started working on it with good natured motivation. Nikki and I began researching different ways of visualizing the tree. But it was tough finding a good place that had a collection of art online that was searchable for tags or categories so the most part of my findings were more design than art. Together we decided on a moodboard for the lones trees that would give us a foundation for a visual style and since it was all about intimacy there was a strong sense of making it beautiful. In our next meeting with David he told us he had some worries about the general concept and that we shouldn’t make the visualisation too sissy. He directed some words to me I thought were a little harsh so I was a bit upset but took his general comments in and started working on the concept again. Davids comments spurred an almost complete chaos of heated discussion in our next group meeting but it felt like it was something we all needed at the time because we were making tough decisions. We discovered that we had made a lot of mistakes in the design proces. The research hadn’t been done correctly and the user research was almost non-existant so it was hard to establish the boundaries which we could work with. Especially Aduen had a very clear idea on what went wrong and I could agree with what he was saying completely. Different concepts were brought up, argued over and discarded. A concept involving a sidescrolling graph was nearly adopted but in this case I vehemently defended the current one. Things got a little ugly there and some of us, including me, said some things that we weren’t proud of. But it was a big learning experience. We decided to stick with the original concept and try to bring the project to a good finish since we were already late on our planning. From there on out the good natured motivation had drained from the project and it was all about making it work. Each begun working on his individual task and the proces was well guided by Arne’s diligence in projectmanagement, that we were also learning about in a different module. The interaction model I worked on proved to be more difficult than I initially thought and I had the luxury of drawing a lot different scenarios to figure out what should happen where and what the basis for our interaction would be. I enjoyed this greatly, partly because I could work directly on what the user would be doing and thinking visually about something as abstract as intimacy. But for a small part also because I could leave
behind the group proces of asking eight people if they agreed on some detail, since there’s always someone that doesn’t. And even though that person brings up valid arguments and has good points, that’s a lengthy and tiresome process. David took me aside at one point to tell me he regretted if he was a bit harsh the other day and I appreciated this. He showed me some modern art set in the context of our project to provide inspiration for our concept and it renewed my zeal, but when I brought it in I got the impression that the group at this point had closed themselves to change. We wanted the widget the receive data as ‘live’ as possible, not generated at the end of the day but fresh. As a means for reflection this might not be necesarry but I think for us it was pleasing to know we could see the tree grow. This meant that time came in to the equation and thinking along those lines I came up with the timeframes that would change the visualisation based on the reaction time of the user. But it was only thought of as a means to make the visualisation more interesting, to provide more variation. David recognized an important underlying psychological component in this interaction. That with these timeframes the lones communicated quality of relation through quality of reaction. We realised that people have a stronger sense of closeness when there is more direct contact, be it in time or place. We’d thought of the stones sharing intimacy over distance and now over time. The interaction still proved to be difficult to interpret and since the tech team was busy making it work there were little delays. Some things hadn’t been decided but only mentioned in passing and there weren’t clear lists of these. And while the tasks were properly divided and everyone was doing their thing, nobody but the projectmanager was keeping notes and group meetings felt a little reserved. Things got hectic and I had to let the animation/video feeler go because it wasn’t realistic seeing the time we had. The tech team started finishing up work and there was a proof of concept where things worked to a certain extent, but not in the way it should have. So it was good to have another couple of weeks to get things finished, even if those couple of weeks also meant the finishing up of other projects. The project was a very big learning experience for me. The need for interaction design principles to be implemented from the very start is clearer than ever. Concepts shouldn’t be argued over but evaluated with a clear mind. Things like requirements, careful workbreakdown, planning of individual tasks, and keeping track of hours shouldn’t be left behind. But this was also the first project in which we tried to manage everything like we should, learning how to do this together with the accompanying module Project-management. For the first time we tried to do things by the book, we weren’t always succesful, but it was a great proces of discovery.