Wednesday 8 February 2017

Internship Opportunity in Stuttgart


The Intuity Media Lab (http://www.intuity.de/en/) is currently looking for an intern (PhD student or Master student) for the research project DAAN (http://daan.dfki.de). The intern will work in close cooperation with the HCI group from Albrecht Schmidt at the University of Stuttgart (http://hcilab.org).

The DAAN project investigates a technical platform, which supports Aging in Place especially for seniors with mental or cognitive illnesses. The supporting notification system consists of two phases. In the learning phase, the system adjusts to the respective user's behavior and daily activities. In the executive phase the systems support the seniors in their daily activities with providing courses of action and relevant information in context. The system shows the provided courses of actions unobtrusively with ambient and adaptive notifications. Therefore, the system will support multi-modal interfaces embedded in the user's home to interact with user's home devices.

The task for the intern is to build and evaluate prototypes which support older adults in their daily lives. Our main focus for such a system is a smart calendar application that supports to maintain an active life. The calendar application can be connected to various physical designs or ambient notification systems. Also, the calendar can support multiple input methods to add manually or automatically new appointments into the digital calendar. If you are interested, please let contact us at IntuityIntern2017@hcilab.org. The internship could be between 3 and 6 months and the starting date is flexible.

Sunday 27 November 2016

A radical proposal to innovate the CHI-conference

In short: increase acceptance to 50% and have a mandatory discussion of at least 15 minutes per paper at the conference! 

Around this time of the year (starting with the rebuttal phase and then again when notifications are out) we have heated discussions about the review process and quality of our main ACM SIGCHI conference. Much of the discussion can be summarized as: ACM SIGCHI is a lottery, I got the wrong reviewers, they did not carefully read my paper, and this should have been accepted and the committee is too dumb to see it. I strongly disagree with these statements (and I am probably one of the persons with the most CHI rejects over the last years), but if we as a community feel this way we have to change the process.

Why to increase the acceptance rate? 

If we compare our prime venue with a lottery it would mean putting value to these publications, e.g. in hiring, would be absolutely wrong. As people in the community are really proud of their publications in CHI (and I have not seen much talk about lottery on the accepted ones) it seems that we only accept too few.

Looking through my Facebook comments and at the tweets during the rebuttal phase, many well established colleagues were surprised that their best papers did not get good reviews. So people with the highest esteem and highest peer recognition (CHI Academy, former chairs, …) are not able to know whether the paper they consider perfect gets in or not. They cannot judge the quality of their own work with regard to the CHI review process. If this is the case we are probably too selective and reject good work, hence my proposal to increase acceptance rate significantly, e.g. to 50%. The same people complaining about their paper not getting in rant at the conference about the low quality of papers and that we need to be more selective. Is this another filter bubble effect?

By increasing the acceptance rate to 50% we would make the conference predictable. It would no longer depend on the SC, ACs, 2nd ACs, and reviewers whether you get in or not. Reasonable papers would be very likely to get in. It would also decrease the value of the publication as such and would put the focus back on its content. Another positive effect I would expect is that people would not gamble by salami-slicing their work as they could be pretty sure a solid paper gets in and the value of a paper would be defined by its content and not by the fact that it is accepted.

Why enforce long discussions? 

I am pretty sure what the answer to the following question to ACs would be: if you have only one trip you could do, would you go to the program committee meeting or to the actual conference? We did not ask this question in 2014 but I ask many people what value they see in the physical PC meeting. And there were very clear answers: overview of many contributions made, expert discussion of the contribution – especially the controversial ones, and getting a feel for what the community values.

In contrast, going to CHI2016, UBICOMP2016, and UIST2016 I felt that the discussions were most often not existent or even embarrassing. In our prime venues we do not discuss the results that are presented. We do not engage with why people took a certain approach, we do not discuss the implications of the work, we do not discuss alternative approaches, we do not discuss limitations, and we do not discuss what value this contribution has for the community. Such discussions happen in other fields (I recently presented at a social science event and the discussion was very challanging but insightful). We have lost the discussion culture at our conferences.

By enforcing discussions (e.g. have the AC and 2AC present at the presentation) we would learn much more from the work people present and I would expect that some people would even be more careful about what they publish. If we do not challenge the research in discussions, we keep everyone in their bubble, having no real idea how the wider community receives and sees it. My suggestion would be to have talks of 15 minutes and 15 minutes of discussion. If no discussion happens the paper cannot be published. If the discussion reveals that the paper reports on major findings or even delivers a breakthrough the authors should be encouraged to extend it for a journal. We could even imagine that people at the discussion can non-anonymously either endorse or oppose the paper in the ACM DL.

Perception of Human Computer Interaction by others

I have a few prototypical comments below that illustrate how others view the way we publish. I have not received exactly these, but some with a similar meaning from colleagues from other fields:
  • “Interesting, you just present the work and there is no discussion? Maybe that is useful in your field as you can present more in the same time.”
  • “It’s is exciting that you follow an agile publication strategy in your field. Each web questionnaire, prototype, pre-study, and study is presented in a separate publication in your top venue. How do you keep track of this?”

CHI as benchmark is too little

Whenever there is the discussion that we need to reform the CHI paper process people argue: this is essential in the US tenure track process and hence we cannot change it. And the solution is to create another (minor) venue that is removing some of the competition for the “serious” researchers. It seems CHI has managed to become a great benchmark for hiring and tenure, but its function as publication venue may be at risk – especially if people talk about the “CHI lottery”. As I said I disagree with this observation, but I think we should make an effort to:
  1. Make the conference a predictable publication venue (e.g. senior people in the field would be able to place their own submission reliably into one of the three categories: clear reject, borderline, clear accept)
  2. Enforce discussion at the conference to avoid that researchers live in their bubble (where they and their friends believe it is good, but the community at large thinks it is not). 
This may not require the radical changes I have suggested in the heading, but at least we should start to discuss it!

Wednesday 16 March 2016

Keynote at PerCom2016 by Bo Begole: The Dawn of Responsive Media

Bo Begole is VP at Huawei is presenting a Keynote PerCom2016 on “The Dawn of Responsive Media”. He has worked in the Ubicomp domain for over 20 years. At PARC he investigated Contextual Intelligence as a logical follow-up of making context-awareness smarter and actionable. Aiming at “harvesting” the Ubicomp research at PARC he looked at business cases and business opportunities for Ubicomp, which resulted in his book “Ubiquitous Compting for Business”[1].

At Huawei his focus is on immersion and experience. He started out with outlining how people like “lean back experience” and how this is well supported by current technology. He argues that the traditional remote control supports this still more liked than gestures and people like this form of lazy media consumption. There is also a growth in “learn forward” experience, basically requiring high intensity interaction (e.g. gesture control, body activated games) that asked the user to be active. He reasons that the space in-between may be an interesting and important for future products.

In his talk Bo looked at a short history of Ubicomp and VR and spoke on to current developments and the buzz in the industry. It seems to many that VR/AR is the next huge thing changing media consumption and media sharing fundamentally, like moving from text to images. He puts up an interesting question on whether or not a second life like world is coming back? Many of us still remember the excitement (and investments) around second life the first time round.

Bo is confident that games are the killer application for VR and that hence it will sell very well. Once the technology is out with the users there will be further uses. At the same time, he questions if spatial placement (like in the HoloLens concepts seen in the media) is really helping people to organize their things, activities and data or not.

For immersive technology in the home he sees that high resolution screen will play a major role alongside mobile technologies. MirrorSys is an example of a research project of an immersive communication system. Key aspects are live sized presentation of people and a visualization that is close to the upper bounds of human perception. His calculations for the display is to have 30000 x 24000 pixel (=720 Mega pixel) as the upper bound for perception without head movement (this is roughly a factor 10 more than we have in the lab in Stuttgart [2]). At the same time camera technology is advancing towards high spatial and temporal resolution and towards camera arrays that allow you to move around the scene. He had some impressive examples of what you can do with a camera array that simultaneously captures scenes and allows you to navigate through scenes from different angles.

In his view speech interaction is also gaining more importance – moving towards conversational systems with a deep language understanding. He makes the point that especially with many devices in the Internet of Things (without classical user interface) this will play a more important role.

Finally, he suggested that user engagement is a key for responsive media. So far this has been a key in presenting advertising to customers. In the future this will be central to many applications, as the systems will optimize for engagement with the user and will adapt their content and presentation to ensure that the user is and stays engaged.

The research roadmap he presents is pretty wide with a lot of open issues to be solved.

[1] Begole, Bo. Ubiquitous Computing for Business: Find New Markets, Create Better Businesses, and Reach Customers Around the World 24-7-365. Ft Press, 2011.
[2] Power Wall at the University of Stuttgart, https://www.visus.uni-stuttgart.de/en/institute/visualisation-laboratory/technical-details.html

Tuesday 15 March 2016

Keynote by Cecilia Mascolo at Percom2016: Technology and Experiecne in the Physcial World

Cecilia Mascolo presents the keynote at Percom2016. Her opening statement is: “Technology must enhance and not substitute the physical experience”.

Cecilia makes the point that continuous sensing with mobile devices can overcome many issue that are well known with traditional studies (especially the classical problem of psychologist studying psychology students in a dark lab). One of here early papers (EmotionSense, see [1]) shows how we can move studies into the real world. This is not without difficulties, especially when you try to understand emotions.

Putting research apps into android market changes the game, large numbers of users become within reach. Higher numbers of participants require a clear purpose of the applications (Nielse Henze provide in [2] a nice recipe of how to do this). Her experience is that user engagement through gamification really worked. Even if the duration of participation of individuals is limited to weeks or months this generates very useful information. A short introduction to social sensing by Cecilia can be found in [3].

Different sensors have different energy and privacy cost and also different types of contributions. Correlating the accelerometer and happiness is really interesting. Users who are more active (not just movement, “being out and about”) are happier. Clustering accelerometer data and correlating it with other high level data opens exciting questions, e.g. health. Similarly correlating happiness and location leads to more surprising results: less happy at home and work, more when out and active. Looking at people’s personally and demographics shows that gender, age, employment, etc. has a clear correlation with activity and usage of communication.

Physical space matters! Using active badges they looked at how the change of physical space can impact peoples interactions [4]. The sensing approach allowed to understand how changes in physical space changes the behavior on a really fine grained level.

References:
[1] Rachuri, K. K., Musolesi, M., Mascolo, C., Rentfrow, P. J., Longworth, C., & Aucinas, A. (2010, September). EmotionSense: a mobile phones based adaptive platform for experimental social psychology research. In Proceedings of the 12th ACM international conference on Ubiquitous computing (pp. 281-290). ACM. http://csce.uark.edu/~tingxiny/courses/5013sp14/reading/Rachuri2010EMP.pdf
[2] Henze, N., Shirazi, A. S., Schmidt, A., Pielot, M., & Michahelles, F. (2013). Empirical research through ubiquitous data collection. Computer, 46(6), 0074-76. http://doi.ieeecomputersociety.org/10.1109/MC.2013.202
[3] Mascolo, C. (2010). The power of mobile computing in a social era. IEEE Internet Computing, 14(6), 76. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.466.2037&rep=rep1&type=pdf
[4] Brown, C., Efstratiou, C., Leontiadis, I., Quercia, D., Mascolo, C., Scott, J., & Key, P. (2014, September). The architecture of innovation: Tracking face-to-face interactions with ubicomp technologies. In Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing (pp. 811-822). ACM. http://arxiv.org/pdf/1406.6829.pdf

Tuesday 1 December 2015

Experimenting with EMG


In the upcoming issue of ACM interactions magazine I will talk in my column on interaction technology about the electrical interfaces to humans. This blogpost is written to give you a preview of the article and describes a little project I did over the weekend to explore Electromyography (EMG).

It is the simplest circuit I could find and it results in a very simple and easy to make EMG. It takes less than half an hour to build and plugs into the microphone input of a computer. It uses a single operation amplifier (INA128p) and is based on the description in [1]. Builing the filter into the gain branch is quite nice ;-)




For my Experiment I used the following components:
  • a INA128p (Precision, Low Power Instrumentation Amplifiers)
  • 2 Capacitors (100uF, Elco) 
  • a Resistor of 120 Ohm 
  • 3 copper pieces (e.g. 5 cent coins) as electrodes for the body 
  • a 3.5mm audio connector (from broken headphones) 
  • some cables and prototyping board 
The eagle CAD file is available for download
Connecting it to other parts of the body made a very simple ECG – more suitable to get the heard rate that the shape of the signal.



More sophisticated circuits are available, e.g. openBCI [2] or an EMG shield for Arduino [3]. If you look more for commercial device you will find in [4] a good overview and also an introduction to emotion sensing.
 

[1] Bhaskar, A, Tharion, E., and Devasahayam, S.R. Computer-based inexpensive surface electromyography recording for a student laboratory. Advances in Physiology Education 31, 2 (2007), 242–243.
[2] http://www.openbci.com/
[3] https://www.olimex.com/Products/Duino/Shields/SHIELD-EKG-EMG/ 
[4] Kanjo, Eiman, and Alan Chamberlain. "Emotions in context: examining pervasive affective sensing systems, applications, and analyses." Personal and Ubiquitous Computing: 1-16

Tuesday 9 June 2015

Security and privacy implications of memory aids

Ever considered what you risk when you use pervasive computing based memory aids? Can other people twist what you remember? Imagine someone tampers with your photos you keep in the cloud - will this change what you remember? Will this alter your memory. In the European Project RECALL we investigated pervasive memory augmentation through computing technologies. In an article for IEEE Pervasive Magizine we investigated privacy and security implications if memory aids.


The full article is at the moment available for free at http://www.computer.org/web/computingnow/content?g=53319&type=article&urlTitle=security-and-privacy-implications-of-pervasive-memory-augmentation

Davies, Nigel, Adrian Friday, Sarah Clinch, Corina Sas, Marc Langheinrich, Geoff Ward, and Albrecht Schmidt. "Security and privacy implications of pervasive memory augmentation." Pervasive Computing, IEEE 14, no. 1 (2015): 44-53.

Monday 1 June 2015

Crowdfunding - Interviews with Amanda Williams and Khai Truong

In the next issue of the IEEE Pervasive Magazine I will publish in the column on Innovations in Ubicomp Products the article: "Crowdfunding for Ubicomp Products: Interviews with Amanda Williams and Khai Truong" - Here are already the full interviews.

Interview with Amanda Williams

 Albrecht: You had a successful kickstarter project with a "lamp" – can you shortly describe the product (perhaps you have one or two photos, too)? And who was on the team?

Amanda: Our kickstarter campaign was for a smart, programmable lamp named Clyde. Clyde is a unique, jellyfishlike desk lamp that does both bright task lighting and colored ambient lighting (see figure CLYDE). He comes equipped with environmental sensors that he automatically detects and reacts to, so whether you want him to be "touchy feely" or "afraid of the dark", you can change his personality without programming. But if you do want to program (or learn how) Clyde is Arduino compatible and open-source, and we provide a number of guides and tutorials at http://fabule.com/clyde/.

Our team during the crowdfunding and manufacturing process was composed of myself, Bruno Nadeau, and Angela Gabereau. I did a lot of the interaction design, electrical engineering, marketing, and customer engagement; Bruno handled the design of the physical enclosure, design for manufacture, firmware, and testing -- he spent the most time on the factory floor; Angela is an all-round great software engineer, so she contributed to firmware development, coding up some of our test software, and setting up the back end on our website for ecommerce and customer support.

Albrecht: Why did you go with crowdfunding? What were the advantages for you over other funding approaches?

Amanda: If you're starting a company with a hardware product, your typical startup funding options tend not to match your cost structure because they are really optimized for software companies. If you're creating a software product, your major expense is just developer time; in the early stages you'll have founders working for nothing, which means your expenses are almost nil. As little as $25-50k in seed funding from an angel or an accelerator can get a software startup to the point where it has traction, customers, and revenue - if the founders handle everything really well. This is virtually impossible for a hardware startup, no matter how disciplined the founders are, because they will have to deal with the costs of materials, manufacturing, and shipping physical products. And certifications, which are a significant cost and a real hurdle for people who don't have prior manufacturing experience. Costs vary depending on the product, but I think it's pretty rare to be able to do this well for less than $100k, and even that is a stretch for all but the easiest hardware projects.

So you have this chicken and egg problem. Investors (quite reasonably) don't want to part with a ton of money until they see that your business can actually sell a product; but it takes a lot of money to manufacture a product that you can sell. This is where crowdfunding comes in. It can provide the money you need to cover non-recoverable expenses, and if it goes well, it shows potential investors that you have a market for your product.

There are a number of risks here. Crowdfunding can help you succeed, but it can also give you enough rope to hang yourself with. A failed campaign -- or even a fairly lackluster success -- can actually hurt your chances of attracting investors. It's also extremely common for first-time project creators to underestimate their expenses. People worry a lot about their campaign failing, but that's not the worst outcome. The worst outcome is if it succeeds, you take on the obligation to deliver what you promised, and then you run out of money without delivering. In my experience, I see it becoming increasingly common for startups to start fundraising the moment their campaign wraps up, without waiting to deliver the actual product. I think that's the smart thing to do. It's a moment where your company and your product is all potential: you've shown you have traction, but you haven't yet had the chance to make any ugly manufacturing mistakes. Securing conventional funding to supplement the crowd-funding helps insure against the possibility of running out of cash before you deliver.

Albrecht: Can you give a short overview of your timeline - from idea, to running the kickstarter campaign, to delivering the final products?


Amanda: Our original idea evolved a lot over time. Around January-April 2012 we were working part-time on these LED solder kits, playing around with the idea of an electrical kit that we could build up into various different mechanical configurations. So we made a little solder kit of PCBs with a few through-hole components, as well a couple different laser-cut enclosure kits: one of which would let you build a soft ambient light, the other of which would let you build a little desklamp with an adjustible neck -- identical PCBs in both. We brought these kits to Maker Faire in the Bay Area and to a big "Maker Carnival" in Beijing, the first such event to be held in China. We were a bit surprised to see how much people were drawn to the attractive enclosure design we'd worked on, people who aren't usually that into solder kits. So we started considering how we might make these kits more approachable to a broader audience.

We submitted our idea to HAXLR8R, a hardware accelerator based in Shenzhen, and were accepted to the program. This meant that Bruno and I moved to Shenzhen in January 2013 to spend almost four months doing intensive product development. While we were there, we had access to fabrication techniques that we couldn't have afforded back home. We could cheaply CNC or vacuum cast really professional-looking prototypes, the kind of thing that you could imagine on a store shelf. We could also prototype more sophisticated electronics much faster. This enabled us to move away from solder kits (4 out of 5 people who wanted to buy our product at previous maker faires didn't know how to solder) to an Arduino-compatible board with auto-detectable sensor modules. We now had a product with a really gentle learning curve, allowing users to customize without any special tools at all, but still open enough for really deep hardware or software hacking. Also, we were able to make it look really cool!

We ran our Kickstarter campaign from May-June 2013 and made almost $150k, more than triple our goal. We thought we could deliver the product by Christmas, but because of our inexperience, we underestimated how much work was still required to design for manufacture, set up a test plan the factory could follow, finalize and purchase everything on the bill of materials, design supplementary materials like packaging and manuals, test for electromagnetic compatibility, and ship to 30 different countries. During this time we had to re-design our board because the microprocessor we were using suddenly shot up in price. We had to do more mold revisions than anticipated, and switch materials to a plastic that would look good when back lit by a bunch of really bright LEDs. Since we were using several different materials in our product -- injection-molded plastic, die-cut silicone, metal gooseneck tubing, off-the-shelf screws and nuts, and custom PCBs -- we had to work with a number of different, but interdependent suppliers. If one supplier has a delay, the others fall like dominoes. In hindsight, a lot of this stuff looks obvious, but our experience wasn't really atypical for first time product creators.

We shipped Clyde out to our backers and post-Kickstarter pre-orders in July of 2014. One typically thinks that shipping is the finish line, but the reality is, that's when you start seeing a lot of customer support work. It's a computational product, so of course, you have to answer questions about set-up, drivers (if anyone wants to plug it in to program from their computer), how the sensors work, how to assemble, etc. Sometimes things get held up in customs, sometimes packages go missing and need to be replaced. So that will take up a lot of your time for a few months, and customer support is never really an engineer's favorite task.

Albrecht: What was the minimum number of items that were required in order to make sense to start production and why? Is there an "Economy of scale" for Ubicomp products?

Amanda: There is ABSOLUTELY an economy of scale for Ubicomp products, though it depends a lot on your method of production. More and more manufacturers in China and North America are willing to do small runs, but it will inevitably cost more per piece.

When we were calculating our Kickstarter goal and reward levels, we calculated how much we would need for runs of 300, 500, and 1000. We ended up producing a run of 1000, plus 100 wooden special edition Clydes. (Note: I don't recommend Shenzhen for woodworking.) The cost of tooling for injection molding is high no matter what (we paid $10,000, and that was a remarkably good deal), but the more you make, the more that cost gets amortized across many units; and the unit cost itself also go down. If you've ever prototyped hardware and shopped for components somewhere like Digikey or even Sparkfun, you're probably familiar with the idea of price breaks for electronic components: each capacitor costs half as much if you buy 1000 instead of 10. The same logic applies to injection molded plastic parts, too. Every time you do a manufacturing run, a skilled technician has to set up the injection molding machine. They have to get the mold temperature, plastic temperature, injection speed, and release of air pressure calibrated exactly right for the size and shape of your product, and this takes a lot of trial and error. Once that's done, it's easy to spit out one unit after another; but you can see why manufacturers would prefer to do 10,000 units at once rather than 1,000 ten times. The calibration process also generates plastic waste that can't be recycled since it's often warped and burnt.

Method of production matters a lot. Injection molding, as described above, has a very high up-front cost and a low per-piece cost. However, if you happened to be making something using CNC milling, you'd have a fairly low set-up fee, and a relatively high per-piece cost. This really needs to be taken into account when you set up a crowdfunding campaign. Campaigns that go way over their funding goal are actually MORE likely to experience delays, and I suspect that a lot of pain could be avoided if creators thought ahead about whether their production methods scale well or not.


Albrecht: Ubicomp products typically include design, hardware and software (and often networking) and I guess you had the know-how for prototyping yourself / in your team. How did you transfer the expertise for prototyping to production?


Amanda: We learned the hard way. Bruno is extremely organized and detail-oriented, and it is absolutely crucial to have someone on your team like that. I turned out (to my own surprise) to be ruthless - kind of tactically evil, in fact - when it came to negotiating prices with suppliers; you probably also want someone like that on your team.

If you can hire a senior engineer with lots of manufacturing experience, that would be ideal. Most of us don't really have the budget for that, so we muddle through.

That said, we had great mentors. Bunnie Huang helped advise us on some manufacturing issues, and he's been a wonderful resource to us, other hardware startups, and even graduate students looking to manufacture creative hardware. Our own contract manufacturer (AQS), since they often work with startups, was willing to show us the ropes -- not everyone would have been so patient. It costs a bit more to work with a factory like that, but I'd say it was worth it. And we were also working in an environment where we had frequent contact with other teams who were doing similar work to us. So we could always talk to someone who was a year, six months, two months ahead of us in the process, and anticipate what might go wrong. And in turn, we helped teams that were a few months behind us.

Learning to manufacture is not easy, and it's not at all formalized. Most of us learn by forming professional networks and getting help from our friends. You have to be resourceful, and not shy about asking for help.

Albrecht: With crowdfunding you have customers for a product often already at the idea stage. How does this impact the product development and the final implementation?

Amanda: It's great! And it sucks! 

Most backers are really supportive. They back campaigns not just to acquire an end product, but to engage with the process of invention and design and production. So you can get great feedback from people regarding what features they want you to prioritize. We opened up our source code and saw people creating new modes of interaction for Clyde, and it was awesome. I'm eternally grateful to the 965 people who gave us a chance.

But it does add a lot of pressure. Even if people are nice, you feel the weight of your promise to give them what they want, and you feel pretty awful about every delay. I love learning new things, but it's more pleasurable without all the pressure!

Albrecht: How is crowdfunding changing how we make ubiquitous computing products? Are there new classes of products that become economically viable?


Amanda: Crowdfunding, along with a growing class of manufacturers that are willing to do small runs, allow us to actually bring more long-tail, niche devices into existence. Clyde's a pretty niche product. It's a quirky design. It's not meant to be one-size-fits all. 1100 was a pretty good number to produce. If we'd been required to do a minimum order quantity of 10,000, it just wouldn't have happened, but this way, about 1000 people get a neat little product that powerfully appeals to them. But I think also these small manufacturing projects have to be quite passion-driven, since the up front work to design a 1000-unit run is not much less than the work required to set up something much larger. You probably won't get filthy rich doing this stuff, but if you handle things right, you won't go broke, either.

This new set of capabilities makes the boundary between research and product-development a lot more porous. You could conceivably do a run of a hundred or so devices for a research project, and deploy them in the wild for validation. Universities and industrial research labs spin off research projects into startups sometimes; crowdfunding and small-run manufacturing can allow you to validate these projects before taking a big risk on them.

Albrecht: With crowdfunding you give your idea away (or at least you make it public) before you can ship. Were you afraid of others being faster in creating "your" product and having it on the market first? Did you take precautions to avoid competition?


Amanda: Protecting our IP wasn't a huge deal for us, but it can be for others. At $150K, we were below the threshold of interest for most copycats to try to reverse engineer our product -- if we'd raised more than half a million I'd have been a lot more worried. But anyway, we made it all open source. Preventing copying wasn't a huge priority for us. It is for others.

In the US you get a one year grace period between going public with your idea and filing a patent for it. This doesn't apply everywhere, so if you want to patent, submit it before you launch a crowdfunding campaign. However, patent protection is far from air-tight. Whether your patent protects you or not is really for the courts to decide, if you ever get into a lawsuit. Do you have the budget to hire a lawyer for this? A better lawyer than Xiaomi can afford? If you have a US or European patent, that won't count for anything in China. You can get a patent in Hong Kong if you're willing to translate everything, and the People's Republic of China will *ostensibly* honor it. But I will eat every ounce of our plastic waste if Chinese courts EVER rule in favor of a foreign company suing a Chinese company for patent infringement. In fact, I believe you have to set up a China-based subsidiary to even be allowed to sue.

So if patents are not that useful, what do you do to protect your product? You have a couple of options. 1) Move fast. Invent new things faster than people can copy your old things. But watch out, those shanzhai manufacturers are pretty quick. 2) Don't make incredibly simple pure-hardware products. Those are the easiest things to copy. They're right in the shanzhai manufacturer comfort zone. If you're doing something incredibly original in hardware, something that required lots of R&D to get right, that can help a lot. Or you can put a lot of the value in software and the creation of an awesome UX. If you're worried about how honest your manufacturer is, don't give them the source code -- just have them flash the binaries onto your microprocessors, or if you're really paranoid, do it yourself (we know someone who did that). The hardest thing for a competitor to steal is a fantastic user community.

That said, I really respect those shanzhai guys. Silvia Lindtner and Bunnie Huang have both written about what that work looks like on the ground. They are extremely clever about using their hardware ecosystem to reduce costs, and they create niche (or not-so-niche) products for markets that mainstream companies aren't touching, like a minimalist mobile phone that retails for 12 USD! That means the cost of materials, labor, and shipping have to add up to no more than 4 USD. That is pretty crazy.


Albrecht: How did you continue after "kick starting" you project / company?


Amanda: Manufacturing Clyde to fulfil our Kickstarter was a marvelous learning experience. Once we finished up that project, we realized it had given us a ton of ideas for tools that we wished we'd had during the manufacturing process. Effective collaborative tools for manufacturing just didn't seem to exist yet, at least not in any form usable to the increasing number of startups and small-scale creators that need them. We're working on an exciting new project now (up on fabule.com) for a hosted Bill of Materials management tool. The Bill of Materials is a keystone document that is an absolutely crucial point of communication between a creator and their manufacturer, at all stages of production, from prototyping, to sourcing, to assembly, testing, and subsequent manufacturing runs. Right now everyone is using Excel, and spending hours doing tedious and error-prone revisions, and maintaining multiple parallel copies for different purposes and different audiences. We've spoken to manufacturers who've had to spend hours coaching startups on how to provide them with the specific information they need to even be able to provide a quote. We know we can do better. At this point we're decent domain experts in hardware manufacturing, but we also have a really deep background in UX and software development, which means that we're really well-positioned to build a tool that can help guide first-timers to do the manufacturing collaboration correctly.

In the hardware ecosystem right now, we're seeing a revolution in prototyping technologies and fundraising techniques. The first two steps in creating a ubicomp product have gotten much, much easier, and it's opened the field up to a lot more people. However as soon as you face the problem of manufacturing, you find that that part is about as hard to navigate as it ever was. So now we're tackling that step, trying to find ways to standardize, educate, and create smoother collaborations between creators, manufacturers, and suppliers.


Albrecht: Further comments?


Amanda: When we make ubicomp products, we are often trying to make "normal" objects smarter. We stuff processors, and wifi or bluetooth, and batteries, and tiny circuit boards into everyday things like lamps, jewelry, cat toys, bicycle handlebars, cribs, etc. But the manufacturers who know how to make lamps, jewelry, cat toys, bicycle handlebars, and cribs don't necessarily know ANYTHING about manufacturing and testing computational hardware. And the manufacturers who know how to make and test PCBs don't necessarily know how to work with the materials that you'd need to make your thing. So when we try to make smarter everyday things, we often find ourselves in the position of having to educate our manufacturer, or at least we have to be a good bridge between manufacturers who have very different areas of expertise.


Short bio:

Amanda Williams is Co-Founder and CEO of Fabule Fabrications. She's in charge of creating beautiful interactions, beautiful hardware, and customer development. She has a Ph.D. in Information and Computer Sciences from UC Irvine and a B.S. in Symbolic Systems from Stanford University. Amanda has worked at Xerox PARC, Adobe, Intel Research, and Microsoft Research. Indecisively, she loves both qualitative user research and hardware design. She has been accused of eating like a trucker. 




Interview with Khai Truong 

Albrecht: You had a successful indiegogo project with a on-screen keyboard – can you shortly describe the product (perhaps you have one or two photos, too)? And who was on the team?


Khai: Minuum is an text input method which reduces a full size keyboard down to a single dimension (or row) of keys. For on-screen keyboards, this reduces the amount of space that would be taken up by the input method, giving more real estate to the rest of the application. The challenge introduced with enabling this is how to allow users to still type quickly as it becomes harder for them to precisely hit keys on this reduced sized keyboard. To this end, the backend of the product is a disambiguation engine that predicts what the user is typing without requiring the user to always hit the exact keys in the word that they are typing. By reducing text entry to being simply selection of keys placed on a single row, this same mode of typing can be carried over to a variety of other platforms and devices. 

The initial members of the team were Will Walmsley, Xavier Snellgrove and myself. Severin Smith joined the team later as a co-founder. Will, Xavier, and Severin remain a core member of the company. I've taken a step back as and I am acting as a scientific advisor to the company. The company, in the meantime, has grown to include more developers, designers, as well as marking, communications and business development people.


Albrecht: Why did you go with crowdfunding? What were the advantages for you over other funding approaches?


Khai: Of course, there is the financial benefits of crowdfunding. Because it's obvious, it probably does not need to be discussed. But there are several other reasons that might not be as clear, yet are important to consider.

One advantage with crowdfunding is that it is full of people who want to support new ideas. In a sense, these are people who are likely to be early adopters of the technology. They might be technology savvy. And they might be people who are open to the possibility that the product is still be refined.

A second advantage with crowdfunding is the buzz that it provides for the product. For Minuum, while the crowdfunding campaign occurred, the Youtube video about the product was watched by over a million people (there were two versions of the video because the audio in the initial version needed to be improved--the combined viewership of the two videos went over a million in a few weeks). This helped to advertise the product. The media also caught wind of the campaign and helped to promote awareness about the product because of the crowdfunding effort as well.

I think the final advantage is that it provides a way for gaining feedback about the product/idea from the potential users while the development of the product is still occurring. That can help to shape the product.


Albrecht: Can you give a short overview of your timeline … from idea, to running the indiegogo campaign, to delivering the final products?


Khai: The timeline actually started well before the campaign. For Minuum, the timeline might be somewhat unique as well. But the timeline went like this. 

I taught an HCI course that Will Walmsley took. For the course, students were asked to develop and evaluate an "eyes-free typing method." Will and his project team worked on a rotational gesture-based keyboard. The basic premise of the keyboard is that the user holds the phone in their hand. The user rotates their wrist along the forearm's axis to select letters (arranged alphabetically), and taps the screen to type that letter. As you can imagine, it's hard to imagine the user being able to easily and accurately selecting a letter in this way. He and his team designed and developed a rough prototype which demonstrated that with a disambiguation engine behind it, it was possible to handle the imprecisions (i.e., errors) involved with being able to correctly select letters using wrist rotations. 

The technique was interesting enough that Will and I continued to work on it as a research project. Over this period of time, we brought on another student in the lab (Xavier Snellgrove). Using an iterative design process over the course of a year, we continued to develop, evaluate and refine the prototype in numerous ways, including: dramatically improving the disambiguation algorithm, supporting more input gestures, providing auditory feedback and minimal visual feedback, and using two different alphabet layouts (a layout which adapted the familiar "QWERTY" layout to a single dimension and an expert/optimal "ENBUD" layout). The research was published in a TOCHI 2014 paper, but the interesting things that we learned were people could learn to use the method to perform eyes-free typing and that users were able to use the QWERTY layout to achieve comparable input rates to the optimal ENBUD layout (thus, the user's  familiarity with QWERTY could be leveraged rather than requiring the user to learn a completely new layout).

The point of explaining the above is to provide some context for what happens next.

Once we completed the Rotext prototype, we thought it was an interesting eyes-free typing method and thought about turning it into a product. Will was still a Master's student (and furthermore, he was not my Masters student) and needed to finish his Master's degree. I was also going to do my sabbatical leave at UC Irvine. So while we were interested in commercializing, we decided to wait until he finished his Master's before proceeding. However, when I started my sabbatical, I was contacted by the partnership office at University of Toronto. I was told that the university was starting a program to help incubate and commercialize early stage technology that summer. They were interested in supporting one of my projects. 

This lead me to have a conversation with Will about whether he would be interested in going forward with commercializing, what we would commercialize, and what our timeline would be like. While we thought eyes-free typing was interesting, we felt that it would be a hard interaction method for many people to be able to learn and adopt. We felt that the most interesting part of the work was the disambiguation engine's ability to support imprecise typing. Furthermore, we felt that the disambiguation engine could be used to support typing along any one dimensional axis. I had also attempted another startup a few years earlier on the 1Line Keyboard (a concept that we studied in a UIST 2009 paper). While that startup effort was not nearly as successful, I had stumbled into an interesting user problem: how to give the user more screenspace while typing. We targetted the tablet platform with the 1Line keyboard, which was only still growing at the time. So as a result, the 1Line company never picked up the momentum we had hoped for it. However, Will and I thought that the concept of using his disambiguation engine on a reduced size keyboard be really useful for mobile phones, which has a very small screen and so any added screen space we could give back to the applications in use would be really valuable.  We decided to call the product Minuum - because we were designing a mini sized keyboard with keys laid along a single continuum. We also felt that this keyboard could be the product that helps users become familiar to concept of imprecise typing along a single axis, and then they could adapt and transition that typing practice over to other devices/platforms/form factors (such as, typing on a small watch or gesture-based typing like the Rotext work).

We entered the UTEST program that summer to begin designing the Minuum keyboard.  Over the course of the summer, Will and I developed and refined our concepts for the Minuum keyboard and the SDK which would allow us and other developers to use the engine to support imprecise 1-dimensional typing on other devices/platforms/form factors. It was over the summer that we started to think about crowdfunding as the way to launch the product and bring awareness to the product and the company. Will and I started some high-level plans about what the crowdfunding campaign might involve, but it wasn't until we had the prototype that details of the crowdfunding effort was thought out more.

One of the reasons why we decided to go with crowdfunding was because the UTEST program gave us some initial funding to help us pay Will for the summer and fall. This meant that we could afford to ask for not a huge amount of money from the crowdfunding campaign to complete the product. So basically we were working in stealth mode the summer and fall of that year. We spent a significant amount of time on the keyboard design, the various features we were going to support. Will then started to port the engine so that it works on a number of platforms (including Android) and I developed the Android input method. By the end of the year we had a mostly demonstrable prototype.  It wasn't a finished product, but it was close enough and became the premise for what we showed in the crowdfuding video. When the next year rolled around, I had returned to Toronto. Xavier had joined the team and they worked on the launch.

We had to start to put together a website, develop the concept video, bring on people to help with marketing and communications (press releases, etc). I remember we had set the launch date to be early in the year, but we ended up delaying it because getting all these materials ready took a significant effort. Just to give you an example, the video wasn't finished until the early morning of the day of the launch. We still ended up needing to update the audio track in the video to make it easier to comprehend a day or two after the launch.  We ended up launching mid March (instead of earlier) and the campaign ran for a month.

With the launch came a lot of press and a number of people/companies contacting us. While Will and the team took all the press requests, feedback about the idea was also coming in. This really helped to provide an understanding of what people liked and wanted/asked for, etc.

What's involved in releasing a product is making the software/system run robustly. This is quite different from creating a research prototype. Coding and testing of the product, tracking of bugs, etc. is quite important and requires a lot of resources (including time).  So while it seemed like a lot of time often goes by before a product actually gets released after we hear about it initially, it's primarily because taking it from a concept/research prototype to a deliverable product still requires a significant amount of development/testing/debugging. For us, the beta version was release June of that year (or about 3 months after the launch).

The team has gone onto participating in the Y Combinator accelerator program and grown in size some (adding developers). They've developed an iPhone version of the keyboard.  They've developed smartwatch versions of the system demonstrated additional experimental uses of the SDK (such as Glass typing, or typing using a remote control, or a leap motion device, etc.). They've done a marvelous job of growing the company and the product in exciting ways. More information about all of these different efforts can be found: http://minuum.com/mediaroom/ .


Albrecht: With crowdfunding you have customers for a product often already at the idea stage. How does this impact the product development and the final implementation?


Khai: User feedback at any stage of development is always valuable. The most important one that crowdfunding provides is whether potential users find the overall concept appealing or not. Different from traditional product development, where we might have fully built the product, then try to put it on the market and see if people *might* buy the product, crowdfunding allows for companies to get insight into whether such customers exist already.

During the campaign, funders will discuss features that they are excited about and what they want and hope to have included in the product.  The funders also get early access to the product (the beta version).  This provides them with the opportunity to give us additional feedback before the first non-beta version is completed. All of this information helps us to understand user requirements and prioritize features. Obviously, not everything can be included in the initial version that gets released, but we can develop a list of features that gets added to subsequent versions.


Albrecht: You funded the development of software. In your research you created typical ubicomp systems – what challenges do you see in using crowd funding for ubicomp products that include hardware and software?


Khai: This is a really interesting question. Minuum was primarily a software product, which has very different costs to a hardware product. In particular, producing hardware in certain volume changes the costs involved. The same is not true with software. 

So in a sense, funding the development of a hardware product is more difficult. But what I think crowdfunding does for the funding of a product that includes a hardware component is that it mitigates some of the expense incurred for initially producing at smaller volumes. What makes it hard for a company, when hardware is involved, is that the manufacturing of a large amount of their product might not be wise early on. The challenge is then of course the pricing associated with the product, and what to ask from crowdfunders so that it seems reasonable. 
  
Albrecht: How is crowdfunding changing how we make ubiquitous computing products? Are there new classes of products that become economically viable?


Khai: I think crowdfunding allows for us to take concepts that we have done some basic research and development on, and turn into actual products when previously we would need to secure the funds to do so first. Even if we know that an idea can work and can be turned into a product, can we find people who believe in us enough to fund that development? Crowdfunding allows for enough people who believe in the idea to share some of that cost. 

Ultimately, I think this can benefit ubicomp products that have some hardware component. The cost to create that product is high. We can show people large bulky prototypes of the same concept, but would a large bulky prototype be enough to convince an investor to provide the significant funding needed for the development of that product? Maybe, if they could be convinced that there is a particularly large market for the finished product. And that's what I envision crowdfunding doing, it helps to incur some of that cost. It helps to demonstrate market size. And this helps the company grow and develop the products enough so that they can reach the final design, price point, experience etc. that would be otherwise hard to achieve for their product.


Albrecht: With crowdfunding you give your idea away (or at least you make it public) before you can deliver it. Were you afraid of others being faster in creating "your" product and having it on the market first? Did you take precautions to avoid competition?

Khai: We had patents filed already before the launch. 

We also didn't want to overpromise and not be able to deliver as well. So we had many of the capabilities and much of the backend for the product created already. They were not fully tested. They didn't do everything the released version supported, and they didn't do everything that is supported in subsequent versions either. But enough of it was completed that we knew a) we could do it, and b) we were "months" away from an actual release. That would make it hard for others to catch up.

Short bio:
Khai N. Truong, Ph.D. is a professor at the University of Toronto. His research lies at the intersection of Human-Computer Interaction (HCI) and Ubiquitous Computing (UbiComp), specifically examining the mutual impact of usability and technical constraints on the design of applications and interaction techniques for novel, off-the-desktop computing systems that may be commonplace in 5-10 years. He received his PhD in computer science from the Georgia Institute of Technology.
 

Friday 23 August 2013

Usable Privacy - did you install the seat belt in your car?

In a recent chat with the journalist Eva Wolfangel we discussed why digital security and privacy is so little usable and why many computer scientists seem not to understand the problem. Reading several articles in newspapers I got really annoyed by many of my CS colleagues who:
(1) blame the user for not taking enough care of the data and for making little effort in installing the encryption modules into their email programs and
(2) focusing on new technologies and better encryption and better algorithms to improve security and not considering the entire system including the human user.

Eva wrote an interesting and comprehensive article on usable security in Spectrum der Wissenschaft (it is German and the full version is online at her website). In the following I am sharing the some of the thougts..

@1: Mount the Seatbelts Yourself 
Technically I agree that encryption is not really complicated to install and that most people using computers could learn how to keep their data safe and how to communicate using encryption. From my experience in the real world I see that they chose not to learn it and I completely disagree that this is the user’s fault. Making the end user responsible for security and privacy is in my view entirely and utterly wrong.

Photo by Wikipedia/Michiel1972
Consider this (obviously fictional) example that applies “user responsibly for safety” to another widely used product and shows how strange the idea is:
When you get a new car there are already fixtures and wholes prepared where you can attach the seat belts. In order to get the seats belts which you can than mount in your car, you just have to fill in a post-card (you get with the car) and send it to the manufacturer of your favorite seat belts. You get then the safety belts mailed to you home – free of charge – together with a 2-page manual how to fix them in the car. The only thing you need is a screwdriver and a wrench. It is so easy that really everyone can make their car safe within 30 minutes.

It is very clear and little surprising to anyone that this is not how we do it with cars. We have agreed that the car company is responsible for the safety of the car. Economically the above example would make it cheaper for the manufacturer – probably not all people would claim their seatbelt and the company saves the effort in mounting it. Nevertheless car companies still have to provide you with a build in seat belt if they want to sell their car in Germany…

@2: Live in a Bunker 
Again from a technical perspective it is of great importance that the algorithms are secure and the encryption is strong. Nevertheless this is in my view not the key problem. Take the following example. What is better a 20 random character string password or a 4 digit PIN? From a technical perspective this is clear – however most people will be able to remember a 4 digit PIN (without writing it down) but not many will be able to remember a 20 random character string. Hence the overall system with the PIN – if well designed – may be “better” than the apparently save password based solution (as people will write it down or email it to themselves).

In the physical world we are used to complex (social) systems that allow us to live in a secure environment. In Germany people generally live in houses and flats where people who are determined can break in (e.g. using a sledge hammer on the door, a stone from the front yard on the window, or using more subtle methods). Even though people could fortify their house most people I know value their windows and easy access to their house and do not live in a bunker or add seven additional locks to their front doors – they balance risk and comfort. In traditional environments we rely on the whole system: we expect that neighbors will keep an open eye, forced entry will leave traces, police will try to find a burglar and that they will be punished, and that for most people the risk of committing a crime is not worth the potential benefit.

From a society perspective we similarly balance risk and freedom. If a purse is stolen in a small town the police will not seal off the area and check each person and search each house. Traditionally this is not possible due to the effort involved but also due to our understanding that the actions taken by law enforcement has to follow the proportionality principle. In Germany we do not consider imposing a curfew, even though one could imagine that this would even more reduce the crime rate.

I think we should take the physical and social world as example and inspiration to create usable and secure systems that offer privacy to the end user.

Overall I think security and privacy in digital systems is much more a human computer interaction problem than most people (especially from the security community) think! If you read German you may want to look at the article Eva Wolfangel wrote on the topic.

Friday 21 June 2013

Reading List: Developing Ubiquitous Computing Devices

 

Together with Thomas Kubitza I was teaching a class in the UBI summer school on Developing Ubiquitous Computing Devices. The summer school was held in Oulu and organized by Timo Ojala.

In total the summer school include the following 4 courses:

  • EXPERIENCE-DRIVEN DESIGN OF UBIQUITOUS INTERACTIONS IN URBAN SPACES Prof. Kaisa Väänänen-Vainio-Mattila, Tampere University of Technology, Finland & Dr. Jonna Häkkilä, University of Oulu, Finland
  • DESIGNING MOBILE AUGMENTED REALITY INTERFACES Prof. Mark Billinghurst, University of Canterbury, New Zealand 
  • DEVELOPING UBIQUITOUS COMPUTING DEVICES Prof. Albrecht Schmidt, University of Stuttgart, Germany 
  • URBAN RESOURCE NETWORKS Prof. Malcolm McCullough, University of Michigan, USA 
There was more than work... if you are curious have a look at flickr for photos and more photos.
 
As some people asked for the reading list for our course on Developing Ubiquitous Computing Devices, I thought I post it here.... The reading list is also available as PDF for download.

The reading list comprises 4 areas that are relevant to our course. We expect that you have come across the original paper by Marc Weiser, introducing the concept of ubiquitous computing [1].

In the first part we have included papers that provide an overview of interaction concepts that are relevant in the context of ubiquitous computing. In particular this is tangible interaction [2a] [2b], reality based interaction [3], embedded interaction [4]. The concept of informative art [5] is introduced as well as the notion of persuasive technologies [16].This part is concluded with an overview of interaction with computers in the 21st century [6].

In the second part we have included a paper on how to create smart devices [7], which gives an overview of sensors that may be useful for creating novel and reactive devices. In [8] sensing is extended to context and context-awareness. In the third part we introduce the .NET Gadgeteer platform [9] and show some trends in the development of ubiquitous computing devices: how can we create new products once we can fabricate things [10] and enclosures [10b] and how ubicomp technologies enable new devices and devices concepts [11].

The final part provides some ideas for application scenarios that we plan to assess during the course. In [12] a concept of how to change a bed into a communication media is presented and in [13] a social alarm clock is presented. A recent study [14] shows the impact of technology on communication and in [15] an overview of novel alarm clocks and sleep monitoring devices is given.

References
[1] Weiser, M. (1991). The computer for the 21st century. Scientific american,265(3), 94-104. http://wiki.daimi.au.dk/pca/_files/weiser-orig.pdf
[2a] Ishii, H., & Ullmer, B. (1997, March). Tangible bits: towards seamless interfaces between people, bits and atoms. In Proceedings of the ACM SIGCHI Conference on Human factors in computing systems (pp. 234-241). ACM. http://doi.acm.org/10.1145/258549.258715 http://labs.rightnow.com/colloquium/papers/tangiblebits.pdf
[2b] Ishii, H. (2008, February). Tangible bits: beyond pixels. In Proceedings of the 2nd international conference on Tangible and embedded interaction (pp. xv-xxv). ACM. http://doi.acm.org/10.1145/1347390.1347392
[3] Jacob, R. J., Girouard, A., Hirshfield, L. M., Horn, M. S., Shaer, O., Solovey, E. T., & Zigelbaum, J. (2008, April). Reality-based interaction: a framework for post-WIMP interfaces. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 201-210). ACM. http://doi.acm.org/10.1145/1357054.1357089 http://research.cs.queensu.ca/~audrey/papers/chi08.pdf
[4] Kranz, M., Holleis, P., & Schmidt, A. (2010). Embedded interaction: Interacting with the internet of things. Internet Computing, IEEE, 14(2), 46-53. http://dx.doi.org/10.1109/MIC.2009.141 http://pure.ltu.se/portal/files/39756776/FINAL_PRINT_w2iot_preprint.pdf
[5] Ferscha, A. (2007). Informative art display metaphors. In Universal Access in Human-Computer Interaction. Ambient Interaction (pp. 82-92). Springer Berlin Heidelberg. http://www.pervasive.jku.at/Research/Publications/_Documents/InformativeArtDisplayMetaphors-ferscha2007.pdf
[6] Schmidt, A., Pfleging, B., Alt, F., Sahami, A., & Fitzpatrick, G. (2012). Interacting with 21st-Century Computers. Pervasive Computing, IEEE, 11(1), 22-31. http://www.hcilab.org/wp-content/uploads/schmidt-ieeepc-21century.pdf http://dx.doi.org/10.1109/MPRV.2011.81
[7] Schmidt, A., & Van Laerhoven, K. (2001). How to build smart appliances?.Personal Communications, IEEE, 8(4), 66-71. http://www.comp.lancs.ac.uk/~albrecht/pubs/pdf/schmidt_ieee_pc_08-2001.pdf
[8] Schmidt, A. (2013). Context-Aware Computing: Context-Awareness, Context-Aware User Interfaces, and Implicit Interaction. The Encyclopedia of Human-Computer Interaction, 2nd Ed. http://www.interaction-design.org/encyclopedia/context-aware_computing.html
[9] Villar, N., Scott, J., Hodges, S., Hammil, K., & Miller, C. (2012). . NET gadgeteer: a platform for custom devices. In Pervasive Computing (pp. 216-233). Springer Berlin Heidelberg. http://research.microsoft.com/pubs/163162/Gadgeteer%20Pervasive%202012%20Proof.pdf
[10] Schmidt, A., Doring, T., & Sylvester, A. (2011). Changing How We Make and Deliver Smart Devices: When Can I Print Out My New Phone?. Pervasive Computing, IEEE, 10(4), 6-9. http://www.hci.simtech.uni-stuttgart.de/wp-content/uploads/schmidt2011changing.pdf http://dx.doi.org/10.1109/MPRV.2011.68
[10b] Weichel C., Lau M., Gellersen,H. (2013). Enclosed: A Component-Centric Interface for Designing Prototype Enclosures. Tangible, embedded, and embodied interaction conference (TEI 2013) http://doi.acm.org/10.1145/2460625.2460659 http://www.csweichel.de/papers/2013-enclosed.pdf
[11] Hodges, S., Villar, N., Scott, J., & Schmidt, A. (2012). A New Era for Ubicomp Development. Pervasive Computing, IEEE, 11(1), 5-9. http://dx.doi.org/10.1109/MPRV.2012.1 http://research.microsoft.com/pubs/163175/ANewEraForUbiCompDevelopment-IEEEPervasiveComputing.pdf
[12] Dodge, C. (1997, March). The bed: a medium for intimate communication. InCHI'97 extended abstracts on Human factors in computing systems: looking to the future (pp. 371-372). ACM. http://doi.acm.org/10.1145/1120212.1120439
[13] Schmidt, A., Shirazi, A. S., & van Laerhoven, K. (2012). Are You in Bed with Technology?. Pervasive Computing, IEEE, 11(4), 4-7. http://dx.doi.org/10.1109/MPRV.2012.63
[14] Schmidt, A. (2006). Network alarm clock (The 3AD International Design Competition). Personal and Ubiquitous Computing, 10(2-3), 191-192. http://dx.doi.org/10.1007/s00779-005-0022-y http://old.hcilab.org/documents/Schmidt_NetworkAlarmClock.pdf
[15] Shirazi, A. S., Clawson, J., Hassanpour, Y., Tourian, M. J., Schmidt, A., Chi, E. H., Borazio, M., & Van Laerhoven, K. (2013). Already Up? Using Mobile Phones to Track & Share Sleep Behavior. International Journal of Human-Computer Studies. http://www.sciencedirect.com/science/article/pii/S1071581913000244
[16] Fogg, B. J. (2009, April). A behavior model for persuasive design. In Proceedings of the 4th international conference on persuasive technology (p. 40). ACM. http://bjfogg.com/fbm_files/page4_1.pdf

Appendix: .NET Gadgeteer Links (optional)