Join Uncommon Projects this coming week at Etech, O’Reilly’s Emerging Technology conference. We’re thrilled to be participating this year. We’ll be presenting the ybike project Monday and Wednesday evening and we’re also bringing a special treat we made just for Etech–the Fortunebird. In highly technical emerging technology circles, it’s referred to as an… “automaton bird thingy” that tells fortunes and “tweets” them to a twitter feed. We hope you get to see it in action and receive one of its special readings of your fate.

Big thanks to the NYC pickup crew that helped make this thing a reality–Paul, Drew, Carlos and the Fangohr team for patiently tolerating our drilling, varnishing and hacking late into the night.

(20 Bikes get final touches before shipping)

So I’d like to put a bow on our little bike project and share some assets and ideas in one place. After last week’s post, a few of you wondered if we were serious. Despite our cheeky tone, the truth is that Yahoo has continued to support, promote, hire and trust us to handle some incredibly unique projects since the Ybox. The Purple Pedals project, a prime example of this, was a great chance for Uncommon Projects to explore new areas of research including location-based technologies, hardware fabrication and solar power–all on Yahoo’s generous dime.

Because our projects are often so different, the complimentary ingredients of curiosity and faith serve as the special sauce to successfully realizing a given project. It’s not unusual to start a project like Purple Pedals without knowing how we’re going to get to the finish line. So we ask a lot of questions, tap our network of talented friends and use our experience in Research and Development to create rapid prototypes along the path to figuring out what will actually work. Getting something out the door on time and on budget is its own artform. And we take pride in our ability to apply R&D to a realistic schedule and a well-honed product.

There’s another element that makes our work fun–being able to share the learning with a larger audience and seeing them run with it. Take, for example, the YBox. Presented as a proof of concept, and then an open-sourced kit, it was updated and improved by Darco and Ladyada resulting in the Ybox 2.0. The new version is cheaper, sleeker and has more functionality than the original. While we didn’t have time to support (let alone continue developing) the project, opening it up to the community allowed it to mature in ways we hadn’t ever foreseen. And who knows, maybe this even had something to do with Yahoo’s decision to move their widget engine onto the TV? I for one think having simple, networked text channels and developer access to them would be awesome. I’d love to see Yahoo get it right.

Everyone benefits from an open approach–Uncommon, Yahoo and the larger community of developers and users out there. From our end, we like playing with soldering irons, fabricating hardware and creating killer software. And we’d like to continue making a living doing what we love. So our perfect project is getting paid to use these skills to solve unique tech challenges. Plus, with each project we file the research back into our company quiver, growing our knowledge, experience and repertoire of services as we go. In this way, we’re getting paid to learn while our projects get tighter, stronger and faster. On Purple Pedals for example, we had the chance to explore the realms of metal fabrication, hardware and software integration, location-based services and the creation and storage of electrical power from solar and wheel generated electrical systems.

But how does Yahoo benefit from the project? Compared to traditional marketing it’s a hell of a lot cheaper. It’s also more novel–instead of talking about innovation it actually makes innovation, creating self-generating press along the way. Purple Pedals was dreamt up by Yahoo’s talented Buzz Marketing Team. I suspect part of their strategy is a response to the saturated advertising space in which ever more expensive commercials and media buys race to the bottom to grab our attention. As traditional advertising gets more bombastic it also gets less effective. Purple Pedals offers a fresh and interesting take on this state of affairs by questioning whether advertising really has to suck. Within this context, Purple Pedals makes sense–it’s cheaper than making Super Bowl ads, it’s novel and it’s even helpful in that it lets riders document and share their rides with everyone. Finally, it underscores a commitment to fun and innovation that dovetails nicely with the larger marketing message that Yahoo wants to communicate.

The mandate from Buzz from the beginning of the project was to open the code and share our research. In other words, to be as helpful and generous to the larger community of developers as possible. This is smart, Long Tail, thinking that will keep projects like Purple Pedals relevant far longer than the traditional blip of advertising. Why? Because over time, web devs and search spiders will continue to link back to the code and resources. In the end, and I think this ties back into the Buzz idea, this type of marketing–helpful, fun, useful, generous, novel–can create its own inertia. Instead of the PR department having to write press releases, bloggers, participants and fans will do it for them. They’ll also do it for free and do it for the right reasons–because they appreciate Yahoo’s effort and associate that generosity with the brand itself.

So we are including everything here for you–from our location based research, to our source code, our CAD files, electronics schematics and PCB design documents. We’re hoping that, like the YBox project, this will inspire developers out there (and Yahoo itself) to continue working on and improving the idea.

Assets

Resources
Front and Rear Cases (AutoCAD 2007 Format)
Fabrication Visualizations and Parts List
Source Code
Location-based Technology Research
PCB Files and Electronics Schematic
Master Electronics Parts List

Previous Posts
Josh Post (with Source Code)
Heather Post (Solar Power)
Ongoing Purple Pedals Blog

Collaborators
Mor Naaman (Location-based Technology Advice)
Michael Sharon (Location-based Technology Research)
Quill Hyde (Fabrication)
Heather Dewey-Hagborg (Engineering)
Lee Azzarello (Mr. Bicycle)

Photos
All ybikes output
Making-of Collection

Videos
An Uncommon Solution
What Are Purple Pedals
Ready for the Road
Not Just a Box
Electra’s Influence

Special Thanks
Jason, Brian, Sean, Brit, Lyniel, Havi, Jeanne and, of course, the ybike Riders!

Looks like yahoo finally got around to stealing the ybox idea we presented at the 2006 hackday:

The Yahoo! Widget Engine is based on the popular Konfabulator(R) widget platform for PC, which has been re-engineered specifically for consumer electronics devices.

Here’s what we wrote about the ybox in 2006:

It’s sort of like Konfabulator for your TV (where each widget is just another channel) and it’s sort of like a networked Atari 2600.

Okay, so maybe not the atari 2600 part, but its basically the same idea. Actually, we were hoping at the time that yahoo might take the idea and run with it. Besides, who are we kidding, the idea predates the ybox. Still, it would be nice if yahoo gave us a couple a’ mil, just to be nice.

At the time, we thought the best approach to bringing the “konfabulator” to a TV, would be to partner with Tivo or better yet, the cable companies. But since TV’s are finally coming around to having built-in internet connections, this seems like the right time and the right way to do it.

In terms of being a disruptive technology, I could see this becoming the next iPhone SDK/App store, but it all depends on execution. How widgets will be configured and distributed to your TV seems like an open question. It would be really smart if configuration and widget selection happened on your PC. So yahoo, if you’re listening, its ok — if you haven’t thought of this already, you can steal this idea too :)

UPDATE:

It’s been suggested that perhaps this post is serious about yahoo stealing our idea. So let me clarify: my big fat tongue is in my big fat cheek. We don’t seriously believe that yahoo aped our idea here; as far as we’re concerned this idea was some ripe fruit sitting on the vine that anybody could come along and grab.

In fact, yahoo has hired us three times, as a direct result of the ybox presentation, and has been instrumental in supporting Uncommon Projects.

1. Hack N95 charger

The first step was figuring out how the phone charged. Power can be a tricky business and the phones weren’t cheap so we didn’t want to accidentally fry one in testing. Luckily, this step turned out to be a lot easier than we expected. The factory charger was a regular 5V AC adapter which output about 7.2 volts DC at 880 milliamps. The next step was to figure out the minimum and the maximum power levels the N95 could take in at the charge port and still charge correctly. Our idea was to cut the tip off the power adapter, test the polarity of the wires inside, mate it to a variable power supply, and see what happened to the N95 as we cranked up and down the juice. The first challenge came when we went to strip the wires on our newly cut adapter wire. The N95 charger uses a flat cable to connect from the tip to the body, which means you can’t use regular wire strippers to get at the copper inside. We devised a technique of splitting the wire in half with an exacto knife to create two independent wires which were then possible to strip with regular tools.

We discovered that inside the flat cable are two conductors, one bare and one coated in red enamel. On the first hacked adapter the red wire was ground, but as we later found out it was completely random which wire color was mapped to which power source inside the charger. Once we got at the wire and got our polarity figured out we figured it would be easy enough to just clip onto the bench supply and start testing. Wrong. Even with the bench supply set at 7.5 volts and current limiting set to 880 milliamps the phone refused to make its little beep and display the charging animation. On a hunch we tried putting a resistor between the charger input and the bench output, and somehow, even though the bench supply was supposedly already current limiting, for some reason this worked. Hurray! We got the phone charging on anything from about 4.1 to 10.5 volts DC.

2. Get solar panels

Now that we knew the acceptable range for charging the phone we had to find some solar panels that would fall within this range, fall within our budget, and look cool on a bike. We decided on the “large solar cell” available from sparkfun.com (PRT-07840). For $35 it outputs over 8 volts and 300 milliamps in direct sunlight, beating all others that we found in its price class. To top it off they look cool and come all sealed and soldered up with long leads. Later water tests proved that they were water resistant which really “sealed” the deal for us.

3. Connect and test

We ordered one to try it out, expecting that we would have to build a circuit between the panel and the phone to actually get it to charge. With low expectations, we soldered the already hacked charger tip to the solar panel (double checking the polarity of course) and took a trip to the roof on a sunny day. We found, much to our surprise and delight, that the phone charged directly! Further tests showed that the solar panel would charge the phone in very low light conditions and even indoors under an incandescent bulb. This was very exciting.

4. Measurements

Now we wanted to know how long it would take a single solar panel to charge a depleted N95 on a sunny day. To figure this out we needed to know how much energy we were getting from the solar panels over an extended period of time. We found a neat little product called the “Watts up” which tracks current and voltage consumption and displays both instantaneous values as well as a summation of the total power used over time. Perfect. We hooked the Watts up in between the solar panel and the charge port on the phone and let it sit for an hour in full sunlight on the roof. We got 219 milliamps of current over the course of an hour with a 310 milliamp peak and a 1.2 Watt peak. Since the N95 battery is 1.2 Amps this means we would need 1.2A / .219Ah = 5.479 hours to fully charge a completely depleted phone in direct sunlight. Not bad.

5. Backup power

We could have stopped there, connected a solar panel directly to the phone and, as the phone ran, the panel could top off its charge. But we weren’t quite satisfied with that. For one thing, the phone might not run long enough if the weather was cloudy, or if the bike was parked in the shade, and we didn’t want to make our riders have to be constantly thinking about charging their bikes and parking or riding in the sun. We were also worried that after a few cloudy days in a row the phone might die, and when the sun came back it might not be strong enough to charge the battery up from a completely dead state. Another concern was that the phone and panel would get stuck in an infinite loop where the N95 would have just enough charge to turn on, start itself up, and then exhaust its small charge in that process and die again. In this scenario, even with the bike in full sunlight for hours, it might never completely start itself up! We decided we really needed a back up power system–a bigger battery that we could charge using a solar panel (or a few solar panels) that would in turn charge the N95 in small doses, as needed. This battery would be big enough that we were bound to get some sunny days before it ran out of juice, and if by some fluke we didn’t–we could include a simple charger and plug on the bike so that one overnight charge would last for a couple weeks rather than the couple days the N95 provided on its own. Easy right? Well, sort of.

As we found out, different types of batteries require different charging methods. Originally, we thought we could just buy a 10 amp hour lithium ion battery and use that to feed the N95, but as it turns out they are not only ridiculously expensive but also require specific charging circuitry which we couldn’t find for batteries large enough to suit our needs. Time was running out and we needed an elegant solution.

6. The final circuit

After extensive battery research, we decided on an old standby, friend of cars and boats alike, the trusty sealed lead acid battery. We picked a 6 volt, 12 Amp hour battery from batterymart.com for $17. Yes, they are big, and bulky, and heavy. Yes, they take a long time to charge. But they are a tenth of the price of lithium ion and they’re easy to charge. We could have hooked a single solar panel up straight to the battery with nothing but a diode indefinitely. But we wanted to do more, faster. We wanted three solar panels to give us triple the current and reduce our charging time by 2/3. However, three solar panels in direct sunlight could give us as much as 900 milliamps, more then the battery’s trickle charge rating. (A trickle charge rating is how much current you can supply the battery constantly without monitoring it or worrying about overcharging). This meant that we needed a simple current-limiting charging circuit that would sense when the battery was getting to capacity and gradually reduce the amount of current supplied. The circuit we used was based on an old classic, the LM317 adjustable voltage regulator. The design we needed was right in the datasheet, a “current limited 6V charger”. The circuit required just 4 resistors, a transistor and a capacitor in addition to the LM317 and it worked like a charm right off the breadboard. The circuit was originally designed for charging a lead acid battery from a power supply, and the only modification we made was to reduce the capacitor across Vin by an order of magnitude since we were coming from solar panels rather than a transformer and didn’t have any ripple to worry about.

[JR holds up the l2 pound lead acid battery used in the project]

[6v charger schematic]

This solar charging circuit makes up the majority of our final circuit. We added a switch so the user could choose between solar charging and wall charging, we added a couple diodes to keep the power flowing the right way, a fuse just in case, and a zener diode with a threshold of 4.1V connected to an LED to indicate when the battery is run down past the point where it will charge the N95.

And that’s it! the circuit is real simple once all the annoyances are out of the way, and hopefully will be of use to others who are interested in turning solar energy into cell energy. Next on the list is to see if the same circuit will charge my Samsung and build a general purpose “anything in” to “anything out” charging device to take wind, solar, a dynamo–you name it–and make it whatever I need for the device of the day…

[final schematic]

[The whole system]

We’ve just finished a project for Yahoo called purple pedals (a.k.a. the yBike). There’s a good explanation of the project on Yahoo’s corporate blog and on lifehacker. In a nutshell, it’s a bike that takes pictures and uploads them to flickr in real time. Yahoo also produced some great videos about the project, and there have been a number of blog posts describing the project. But we decided it was time for us to post some details of our own for those interested in how it works.

This will be the first in a series of posts detailing how we chose the technology, the various challenges we faced, and why this project is interesting for us as a company. The Uncommon Projects team included myself (Josh Rooke-Ley), Tarikh Korula and Heather Dewey-Hagborg. We’re also indebted to early research from Michael Sharon and fabrication by Quill Hyde. This post will focus on my perspective as the software lead on the project.

Choosing the platform

One of the first technology questions on the project was whether we were going to use an off-the-shelf device, build the hardware ourselves, or employ some combination of both. From a software perspective, the decision can be described as a question of software versus firmware. Firmware is code that can’t be turned off — it is inextricably linked to the hardware it runs on. Moreover, firmware and hardware are generally designed together with one very specific function in mind and together are called an embedded system.

After several rounds of prototypes we ended up using an off-the-shelf GPS enabled cell-phone, the Nokia N95. I had some misgivings in choosing the N95. For one, the application we were designing was a machine-to-machine system. In other words, there wouldn’t be user interaction (except riding the bike) and there wouldn’t be a screen to give a rider feedback about the state of the application. It seemed very risky to use the N95 or any other off-the-shelf cellphone fundamentally designed to require user input and give screen-based feedback.

While the Nokia ended up being a great platform to work with, we did hit the wall a few times with issues that had no clear fix. For example, the code we wrote worked great, but one in every three times the application would quit unexpectedly after 6 hours of running continuously. And, while the python interface ended up being essential to rapid prototyping, it did mean loosing some control over low-level operations. We also experienced some issues with the python implementation of the camera library on the N95. Not to mention the arcane process of signing Symbian applications.

However, because there is support for background processing, task management, and run on-startup, we could work around any major software issue we encountered. These elements allowed us to make our software act more like firmware–in other words, we do everything possible to make sure that the software can’t quit unexpectedly and that it recovers in the worst possible case. It may not be elegant, but it works ™.

The picture at the top of the page shows the interface for the final application we wrote running on an N95. While this interface was not seen by the end-user it ended up being essential for development, debugging and administrator support.

The networking

The networking component of the project was straight forward compared to the device issues. Yahoo hired New York based web design firm Your Majesty to build startwearingpurple.com which includes flash-based map views of each of the bike photo streams. The geo-tagged images themselves are stored on flickr. For support and maintenance reasons we decided that the photo uploads would first be sent to a server application which would match the imei of the phone to a flickr account. This way we could change the flickr accounts remotely and monitor the status of all of the bikes with a web-based control panel. Here is a crude picture of the network architecture, clouds and all:

click to enlarge

And here is a screen shot of the admin control panel, which allows us to monitor activity, status (like battery level), and associate bikes with flickr accounts.

click to enlarge

And finally, the source code

Yahoo was kind enough to let us share the source code for the project. Note that this code was designed to run in a controlled developer environment, not to be distributed to end-users. We are sharing it more as a reference for those out there that may be trying to do something similar. The code is shared under the GNU Lesser General Public Licence, so feel free to cut and paste into your own projects.

There are two components to the project: the client-side written in Python for S60 and the server-side which uses PHP, MySQL, and YUI. There is some limited documentation provided in README files provided with the source.

ybike_source.tar.gz

Postscript: some useful tidbits for nokia developers

For anyone out there attempting to do something like this project, here are a few useful bits of information that may come in handy.

• If you want to understand the procedure for signing Symbian applications I recommend reading the guide from end-to-end. In fact, I had to read it several times before I understood it.
• If you want to have your application run on startup there are two very important signing requirements:
  • You will have to use at least the “open-signed offline” procedure for signing (see the guide). The “open-signed online” procedure will not work. The upshot is you will have to obtain a publish id which costs $250 and requires faxing some documents to Europe. It may require you to be incorporated (not sure on this).
  • When you sign your application make sure you DON’T turn on the AllFiles, TCB, or DRM (i.e. device manufacturer) capabilities. It just won’t work.
• The built in camera library that comes with Python for S60 v1.4.4 is broken, at least for N95’s. To fix the problem use the pycamera library which is distributed with Nokia’s open source computer vision library. Even with the pycamera library, you will have to force a delay of at least 2 seconds between initializing the camera and taking the picture to fix the over-exposure problem. See the take_photo function in the source code for an example.
• Re-installing SIS files on the N95 sometimes caused the application to foreground on start up. This was a problem for us because it meant the keypad never locked. The only way to consistently prevent this seemed to be to do a hard reset on the phone then re-installing the sis files.
• The European version of the N95 was required to get the application to work in Japan.

Behold the Pixelmusic 3000, the music visualizer on a microcontroller. The PM3K was created as a project and article for Make Magazine. This means the schematic, parts list, code and a photo/text walkthrough explaining the build are printed for anybody to make or modify as s/he wishes. The PM3K is intended both as an ode to a forgotten technology–in this case the Atari Video Music–and as an entree for folks interested in the wonderful world of microcontrollers, hardware and software prototyping.

In the last 30 years, the technologies that enabled the Atari Video Music have been lapped countless times on the circuit of home entertainment devices. The upside is that today those technologies are more accessible to hobbyists than ever before. The PM3K takes advantage of the fact that these technologies are smaller, cheaper and easier to implement than ever before as well. If that sounds like your cup of tea, I recommend checking out issue 14 of Make–not only is the PM3K in there, but there’s tons of other projects for the novice and expert alike to get his/her hands dirty with.

The Atari Video Music

So what is the Atari Video Music? The AVM was created In 1976 by Pong creator Bob Brown. It was released a year before the 2600, and it has the primitive/lovable graphics to prove it. The AVM was intended as a music visualizer that connected your stereo system to your TV set. In a nutshell, it made abstract, pixelated graphics that responded in real time to the music coming out of the stereo. When watching the unit in action today, one is (If I may quote my own snarky article) “taken back to another time, long before iTunes and Winamp visualizers–a time when vinyl, denim, Foghat, mood rings, limited color palettes and Radioshack’s business model all made sense.”

The AVM is a novel device, never having made it past 1976–sort of like a scratchy demo tape from a favorite band before they became famous. Despite its obscurity, it did have a couple sightings in pop culture–at least as an extra in the background. It can be spotted as a keyed layer in Devo’s video for “The Day My Baby Gave Me a Surprise”

and as a background prop in 1979 cult classic, “Over the Edge”.

I did some research and turned up a schematic for the AVM. This tantalizing low-res document was just clear enough to give me a sense of how the thing was made, but also indecipherable enough to have no idea what the actual part numbers were on anything.

What I could glean was that there was a simple processor (perhaps the same Mos 6507 used in the 2600?) some comparators and some amplification stages. What this told me was that, in all likelihood, the way the AVM worked was by using the comparators as simple analog to digital converters, and converting the left and right sound channel voltages into ones and zeros that the processor could use to generate shapes and colors.

I looked at some youtube videos of the AVM in action, used tubesock to convert them to quicktimes, and went through them frame by frame.

What I came to conclude was that the AVM code wasn’t really too complex. There were some limited color palettes and limited shapes and a lot of randomization in picking them. The clearest relationship was between the volume of a given channel and the size of the shape, it looked to me like the rest–color, placement, actual shape were largely arbitrary. And I based my own code on this conclusion.

It was an interesting insight. It seems we humans are wired to draw conclusions between sound and image, even when there may not be much of a correlation. At first, I just assumed that the AVM must be doing some signal processing, pulling out frequencies and using them to drive hue and shape. But signal processing is just far too demanding a task for the simple processor in the AVM. So if you think about how film works–sequential, static images displayed one after the other to trick our senses into seeing motion–the AVM pulls off a similar trick, using color and shape changes to imply a more intelligent correlation between sound and image than may be there. Don’t get me wrong, far from seeing the AVM a cheat, I see it as a brilliant use of the technology available to the developers some 30 years ago.

Roots

While I didn’t have an AVM growing up, there was certainly plenty of mystery surrounding it’s cousin, the 2600. I was too young to know how something as complex as the 2600 worked, and to me the machine was a magical device. When I was 12, I took a screwdriver to the case, the joysticks and the cartridges in an attempt to get a better understanding of the thing. I even started placing masking tape over different pins on the game cartridges before inserting them to see how it affected the gameplay. But all that poking just increased the mystery and magic for me.

So the Pixelmusic 3000 was a return to my roots. But this time armed with a multimeter, a soldering iron, fake wood-grained contact paper and a bit more experience than my 12 year old self possessed. And the pleasure of the thing was, after so many years of mystery shrouding a childhood object, I now kinda-sorta get how the thing (the 2600) must have worked. And likewise I kinda-sorta got to make one (PM3K) myself. That’s a pretty cool feeling. It feels like watching the invisible walls between magic/reality, past/present, and consumer/producer come down pixel by multicolored pixel.

Entrepreneurs kiosks with C&G Partners for the Museum of American Finance 

So if you can forgive my awkward Bob Vila impersonation above,  I wanted to show off one of our recent projects.

We created 10 touchscreen Kiosks for the Museum of American Finance, housed in the former Bank of New York building on Wall Street. The museum was founded in 1988 and is an affiliate of the Smithsonian. The 19″ and 42″ kiosks are part of the new exhibition space designed by C&G partners. C&G hired us to consult on and create the hardware/software solution for the bank of 10 interactive HD video plasmas that serve interviews with a unique selection of 16 entrepreneurs. 

C&G is a design consultancy that specializes in this type of exhibition work and they were a real treat to work with–being both technically and creatively savvy.  Our shared goal was to create minimal, intuitive interactions that highlighted the subject instead of the technological frame around the subject. This can be a subtle point to appreciate because when it’s done well you don’t even notice it, and C&G did a wonderful job of designing an interface that melts away instead of getting in the way. 

We all felt the subject shouldn’t be the shiny technology, it should be the stories that the entrepreneurs share. From MoAF’s perspective it was very important to challenge the public’s traditional expectation of a business “suit”. The museum’s goal with the Entrepreneurs Kiosks was to help museum goers realize that entrepreneurs are just people like us who had an idea and made it a reality. Instead of real estate and software tycoons, the kiosks are filled with men and women of different stripes–everyone from restaurant owners (Drew Nieporent), maternity fashion designers (Liz Lange) to the creators of Zipcar (Robin Chase) and Jetblue (David Neeleman); there’s even a brewer (Steve Hindy)! The excellent interviews were produced and edited by David Tarnow and shot by Luke Geissbuhler. One of the ideas about working on the MoAF Entrepreneurs Kiosks that appealed to me was getting the opportunity to draw some advice and inspiration from people who know what it’s like to have an idea and navigate the difficult waters of small business to grow it and make it a success. 

The technical stuff

You know this wouldn’t be an Uncommon Project if there wasn’t a technical component and the Entrepreneurs Kiosks are no exception, they gave us a chance to refine our approach to creating software and hardware solutions in real locations and for public use.

While we’ve developed software for both Mac and PC, given Josh’s familiarity with the Quicktime libraries, the multimedia stuff is always more appealing to us on the Mac side. Plus the developer tools are cool, and in this particular case we were able to exploit some of the new Core Animation routines included with Leopard. We’ve been creating custom applications for public consumption in one form or another for years and we certainly have our fair share of Flash and Director projects in our past. But that just makes it all the more satisfying to develop applications that can take advantage of system level resources not available in those frameworks.

For example, the videos were all shot on HD and the client didn’t want to have to transcode the interviews, so that made developing in XCode/Cocoa a no-brainer because any other solution would have required sketchy plugins or a loss of video resolution. Additionally, the animations, fades, transitions and general responsiveness are so much tighter when you’re developing desktop applications. The applications are small, single-purposed and fast. And that means we were able to run the whole show on an off-the-shelf Mac Mini with no extra RAM (or even a decent video card for that matter). There’s a case to be made for viewing Minis as mature embedded development boards–they’re small, have tons of connectors, a fast processor and great included dev tools. There’s a ton of freebies too–we created a custom boot process that starts a machine as soon as it gets power and circumvents the Finder, booting itself directly into the kiosk app. This allows any museum staff person to easily manage the kiosks by just flicking a switch on a power strip instead of pulling out a keyboard and mouse at the beginning and end of a day. Finally, we created an admin app and a simple backup/restore solution for C&G in case anything ever goes awry.

These recent kiosks are in a tradition that we started a few years ago for Panasonic/Renegade when we toured interactive HD video kiosks used by thousands of people in 6 locations across the country. The difference is that those kiosks required a large dual G5 tower, an expensive video card, a keyboard and mouse to administer and we had to travel with them to monitor them and fix any unforeseen bugs. None of that was as hard as it sounds, but with the MoAF Entrepreneurs Kiosks it really feels like we’ve refined our work–they’re smaller, lighter, simple to use, virtually admin-less, simple to maintain and stable as heck–running 5 days a week for months now without a single bug report. And who knows, hopefully we even gleaned a thing or two from all those entrepreneurs about how to keep Uncommon Projects on the right track!

Making Things Talk

OK, it’s been a while since I’ve checked in. We here at Uncommon have been a little swamped (more on those projects in another post). Anyway, we’re pleased to announce that the ybox (picture p.114-woot!) has made it into a book written by Tom Igoe and released by O’Reilly. We’re even more pleased to announce the book rocks! Wow, if a book like that existed 10 years ago… Tom’s done an incredible job of helping this fledgling idea we call Physical Computing grow. Tom has tirelessly writen books, taught classes and maintained the world’s most helpful site on the topic. If any of you are interested in getting your hands dirty with this stuff, Making Things Talk is the most clear and most accessible way to do it. It tells you what tools you’ll need, what suppliers to use, it gives you code snippets and explains abstract concepts like communications protocols while keeping the focus on the actual making of stuff. Really cool, and such an thrill for the ybox to be referenced in it!

ybox2

This would also be a good opportunity to give a shout out to another friend of the ybox, one Mssr. D’arco. Darco was one of our classmates from the Maker Faire last year and decided that while he liked the ybox, there were some changes he wanted to see made. And so he made them: Behold the ybox2! How cool is that thing!? I have to say I thought the ybox was a real pregnant idea–thin, cheap (ish), open, TV-enabled client. And I wish we had had more time to explore it and develop it. So it just makes me feel like a giddy grandpa to see the idea continue to grow. One of my favorite improvements is he managed to cut the materials cost in half. Way to go Darco, keep us posted on your progress :)

Near Death iPhoto Export Plugin

An iPhoto plugin that approximates the proverbial Near Death Experience. Exports all or part of your library as a quicktime movie. Each photo in your library becomes a frame, about twelve hundred per minute.

Here’s 2004-2007 of my iphoto library (about 3000 photos in 2 1/2 minutes):

Download OS X Installer

iPhoto ‘08 is untested, it should probably work though.

To use it ,after installing select all or part of your library in iPhoto and select from the menu Share->Export (or apple-shift-e). Select the “Near Death Export” tab, select your size and hit “Export”.

Source Code/Xcode Project

Email is an asynchronous medium and, as such, I’d like to add a touch more ‘asynchronicity’ to the mix. I’ve waited a good decade for this feature, and since it still hasn’t emerged I’ve decided to photoshop it into the blogosphere in the hopes that the powers that be (hello Google, Yahoo, Microsoft) or an enterprising server engineer might just steal it and make it.

I would like to be able to schedule emails that I write now to be sent in the future. Sometimes 10 minutes, sometimes 7 days. So, for example, you send me an email, I respond, hit the SchEmail button and choose the time delay or a date I want it sent from a dialog box. SchEmail would work as a server software layer between your mail client and your mail server. You can schedule your mail, hit send, close your laptop and SchEmail will send your mail at the prearranged time, regardless of whether you’re online or even awake. Sounds simple, right? Wouldn’t it be cool to be able to:

• Throttle demanding clients
• Respond and move on to the next task
• Without looking like a caffeinated meth addict
• Respond to stuff at 3am but send it at the start of the next business day
• Send yourself future reminders (e.g. tasks or todos)
• Communicate with your ex with safety and peace of mind by using ApprovalGard ™

Throttle demanding clients

Have you ever had that client, you know the one, where no matter what you do they always want more? Responding to their emails immediately gives them a sense that you are always available, and they come to expect immediate responses and freak out when they don’t get them. You have two choices with SchEmail. Always put a two or three hour delay on any response. Or, put off the responses until a scheduled time–perhaps the end of the day or the beginning of the next day. Heck maybe it’s late Friday afternoon, SchEmail that mail for Monday morning and save your weekend, my friend.

Respond and move on to the next task

Sometimes the best thing to do is to do the thing right in front of you. This can really become a problem with email, because it’s a never ending dynamic stream. The more of it you send the more you get. But it’s really hard for us humans to schedule things for ourselves in the future–even a couple hours in the future. We’re good at immediate stuff in our face, but not at remembering two hours from now (when we have new immediate stuff in our face stuff) what was immediate and in our face two hours ago. What happens to me is I use my inbox like a reminder list. But God forbid that an email I need to respond to slips below the screen–If I have to scroll to see it I completely forget to respond to it. So instead with SchEmail you can respond immediately, get it taken care of and out of the way, but throttle it a bit so you don’t create more work and communications for yourself by sending it right that second. Just SchEmail it a couple hours from now.

Without looking like a caffeinated meth addict (which you probably are)

Let’s face it, there’s something else at work here. You also don’t want to look like a desperate, crank snorting, working-from-home-in-your-underwear-with-nothing-better-to-do-loser. All of which (and more) is silently implied when your recipient receives a 2000 word reply 3 minutes after they emailed you.

Respond to stuff at 3am but send it at the start of the next business day

In the modern metropolitan world we live life during business hours. Or maybe we do business in our life hours. Or better-put it’s just all swirled together like that peanut-butter-and-jelly-in-the-same-jar when we were little kids. But we need to conform to the business structure of the world too, otherwise our non-work lives would disappear even more than they already have. Maybe putting a little structure around your email correspondence will save a few more minutes for your non-business life.

Send yourself future reminders (e.g. tasks or todos)

Here’s another novel idea–send yourself notes in the future. So you get an email from a client you were trying to follow up with and she tells you she’s going to be in France for the next two weeks. Send yourself an email for two weeks from now reminding yourself to follow up with her, maybe even remind yourself to ask her how she liked Paris. You never have to leave your email app or mess with some crappy calendaring software. Think of it as an email snooze button.

Communicate with your ex with safety and peace of mind by using ApprovalGard ™

Look, we’ve all been there–that sinking feeling after hitting ’send’. The even worse feeling the next day when you haven’t received a response and you know you screwed up. Maybe you were too angry, maybe too hurt. Whatever it was, you probably needed a little time to cool down and think for a minute before you sent it. Let’s face it, calling someone ‘watermelon head’ is just not conducive to mature correspondence. Why not schedule that response to your ex for a week from now? You’ll have a whole week to think it over and take it back. Better yet, add ApprovalGard and sleep easy. Not only does ApprovalGard wait to send your message, it also sends you an email request at your predetermined delay with all the body text for you to review now that the moment has passed. Like what you wrote? just hit reply and it automatically gets sent. Wanna rewrite? No problem, you can even put another ApprovalGard and time delay on it. Your ex will thank you. You will thank you.