Fred Trotter

I love QR codes.

I think the notion of simple graphical URLs is beautiful and elegant. If my wife were a graphical data object, I think she would be a 2D QR code.

Think of it, you can put links anywhere you want, in the real world!

You can put them on tshirts, coffee mugs, stickers, business cards… anything in the real world becomes a link to something in the virtual world. Awesome.

I have been playing with QR codes, with an eye towards gamification and behavior change for quite some time. I love the fact that with android and/or iphones you can rely on the GPS coordinates that webkit (the core of both browsers) will provide, makes a QR code a token that can do different things in different places. Think of the possibilities!

You could make geo-caching much much more interesting…

But how do you make durable (or intentionally not durable) QR code in a reproducible way? How do you manufacture large QR codes, that can be scanned accurately at a distance?

The first approach is simple to print the QR codes on either single sheets (A4 or US letter) and then clear paste them to some type of flat surface. You can use throw-away planks of wood from the hardware store to make durable QR code links. But what if you want to make a QR code on some permanent surface, like a wall or pavement. This basic idea can be taken pretty far, for instance you can paste the printed QR codes into ceramic tile or even bake it on, for a near permanent tag.

The simplest solution would be to use a stencil with black spray paint. QR code scanners vary greatly in their ability to pick up contrast, but the color black, and some other color, will almost always pick up. This has an advantage over gluing paper, because you can tag objects that are not entirely smooth. Moreover, with spray paint that does not damage the surface (more later) you can create images that can be placed out in public, non-destructively.

But what is the problem with a QR code stencil? In a word, islands. In order to make a stencil with, say, photo paper (which would otherwise be a great technique), you need a way to address bits that the stencil needs to block, that are not physically connected to the rest of the stencil. Its easier to show than explain. If you are spray painting black, for instance, and you want to make a stencil of the following QR code, you will have the following trouble spots:

See the issue, the two anything white, that does not connect to something else white (even by a corner) is going to be an issue. You might be able to make something clever for the places where this happens in most/all QR codes, but each QR code is going to have random “islands” that are often just one pixel big… and in different spots each time. These are the real headache. Making a traditional stencil simply will not work.

Also, making a stencil is very very slow. If you have to cut each pattern by hand.. ouch… way to much time. We need something faster too!

My first approach to solving this problem was to try and find a programmatic solution. For a given URL, there are many different ways to encode into a QR code. It might be possible to use an algorithm that detects this type of “island status” to find a QR code solution that did not happen to have any islands. You could make an application smarter by posting meaningless GET variables at the end of a URL until you found a version of the URL that would work (of course, I am focused on using URL shorteners like bit.ly to ensure that you have a simple-as-possible QR-code. The more character in the URL, and the more complex the QR code is and the harder it is to make a stencil. The shortener ensures that the QR code is manageable.

I gave up on this technique after noting that there were islands in all of my test runs for various URLs, but the idea is sound.

Soon, I will be making an announcement about some work that I have been doing with the Facebook places API.

For now, I want to give a little tutorial on how to create a new place, in Facebook places, using your iphone Facebook app.

First, you have to download the facebook application from iTunes, or get someone to help you do this. This tutorial assumes that you have the facebook application already installed… if you really need help with this, go to the Mac store and talk to someone there… should be pretty simple…

The first step is pretty important:

Go to where you want to create the place!

So click on the facebook application to start…

Click the facebook application

This will pull up the home screen…

This is where you typically start

You can also get to the checkin menu from the main facebook menu in two steps:

This is the main menu, places is right in the middle

After clicking there you will see the main Facebook places interface where you can see your friends recent checkins..

This is the central places interface on the iphone, but it is not the checkin interface

Now you should have gotten to the check-ins interface… one way or another…

The check-in interface looks like this!!

This is the checkins interface, you are almost to the point where you can create a new place

So now you could choose a place where you would want to checkin… but that is not what this tutorial is about. You want to create a *new* place that will show up on this list and allow other people to check-in. To do that you need to hit the little red button at the top right of the screen, which should bring you to the “new place” interface:

Make sure that the little blue dot is exactly where on the map that it should be!!

The iphone facebook app Add a Place interface

Now you will be able to check-in to your new place…

The iphone check-in interface

Now you should go ahead and check-in to your new location. By doing this you will start to “legitimize” the place in Facebooks eyes. You also need to get your friends to start using the place when they check-in.

I hope this helps someone. I could not find a current how-to on making a new place in Facebook places. It is pretty simple. If you ‘own’ a place (like a business or non-profit) then you should also read about the process to claim a facebook place.

HTH,

-FT

As many of you know, the CHIP/Indivo/Harvard guys (who I guess I should call the ITdotHealth guys) wrote an article in the NEJM saying that we needed something like the Iphone app store in Healthcare IT.

I wrote a rebuttal saying that, among other platforms, the Google android platform was a better fit. Frankly, I thought that would be the end of it. Most of the time I write a blog post, I get some hits, and maybe a comment if I am lucky. But mentioning the iphone is great for getting attention. Apparently, just saying the word iphone brought the readers out of the wood work. iphone iphone iphone <- (just to be sure…).

More than just getting some good comments I have just realized that Ben Adida (check out my blog roll) wrote a Knol that touched on my criticisms and argues convincingly that there needs to be some balance between openness and safety.

Though it is clear that Apple’s regulation of the iPhone apps market has gone far beyond malware prevention, the goalof malware prevention is certainly reasonable.

I think he is right on, and I look forward to talking about it with him in person tomorrow. I think now, the night before the conference, it might be a good time to drop my thoughts about what platform analogy would really be the best to reference as we move forward. I also take a moment towards the end of the post to concede some of the things that Apple really got right, since I do try to be fair.

If I had to pick one thing that best embodies the 10 principles that are being targeted here, I would pick yum. Yum is the update manager for Red Hat based operating systems. Here’s why:

1. Like the iphone app store, it is ”substitutable (first of the ten points). You can download like 10 different web browsers on the current Fedora.
2.  It built its own protocol. RPM was a lower-level standard, and yum was born as a meta-tool on that standard.
3. Yum allows for multiple platforms. It forms the basis for the software packaging for just about every Red Hat/Fedora based operating systems, of which there are several.
4. The API for yum is open, which is what lets things like yumex happen.
5. The programs installed by yum never have direct control over yum (unless that is the point of the program, and that is what the user wants to do).
6. Application install is as pointy-clicky and as user friendly as it gets BUT you do not lose the power of command line script-ability. Talk about walking the fine line!!
7. Separation between the copyright/patent/trademark of applications and the platform is totally there! You can point your yum to a proprietary repository, for instance to download Adobe flash… no problem.
8. Unfortunately it does not make any sense to say that you can remove everything from yum and still have a platform. So I guess it strikes out on that one. Of course, I am not sure why the platform itself should -not- be considered a package on the platform… Ill have to ask about that tomorrow…
9. Yum is really really efficient. You can update applications very quickly, and you can even install a special yum module that will find the fastest download servers, ensuring the best experience for downloads.
10. The certification is as minimal as can be. The packages -can- (not required to be) signed by the people who set up a repository, and you simply do or do no trust that signature.

Someone will point out, someday, in comments that apt-get is just as good and does all the same things. To that future commenter I fully admit that you are 100% correct. I am a long time Red Hat guy and I am letting my colors show, for the record I am trying Ubuntu on my desktop for now….

Now let me point out a couple of cool things about yum that are not on the “big ten” but that I think are worth emulating:

1. Yum is actually an upgrade to a previous platform, Yup. Yup was good, but users forked it and made it much better… then the original yup developers adopted yum. That’s the virtuous cycle of Open Source in action if I have ever seen it.
2. Yum handles “trust” in the system, by getting out of the way. A “default” repository is trusted to get the system off the ground. But you can “trust” other repositories to get upgrade versions of the software you are currently using, to get substitutionsfor the programs you were currently using, or to get new software that is found nowhere else. It automatically find the balance betwen openness and security. Users make the decision about how to trust, and the system does not auto-branch beyond those decisions.
3. Although yum violates principle 8,  you get the benefits of being able to use the platform to upgrade the platform. You can upgrade a late-generation yum operating system while it is running.
4. The yum platform was central making a larger community effort. Remember when Red Hat stopped doing Red Hat Linux, instead creating the Fedora project and RHEL? Fedora existed before that, as a high-quality repository of Red Hat packages! yum was an important new feature of Fedora Core 1. The yum platform helped move the whole community forward.

So I think the yum project and the way that Red Hat made into a software distribution network is a pretty good model to follow.

Even I, however, get why they original authors chose to use the iphone as an analogy. Not assuming that these points are original, I want to point out some things that Apple did right, that other systems have failed at.

1. Apple enforced simplicity. They refused to allow programs to run in the background. They refused to allow many other things that a developer for Windows CE might have expected. They made the core interface as simple as possible. They even excluded cut and paste initially to make the system simpler. Apple put these restraints in place because by making the applications simpler, they made the user experience vastly more intuitive.  I have used countless “modular” or “substitutable” platforms that miss this.  It is the platforms responsibility to protect the overall user experience, -not- the application developers. That means knowing when to say no. Ignore this one at your peril.
2. Apple built a meritocracy at the level of the end user. When you see an application on the iphone that has been used by 5000 users, and they have all rated it 5 stars, you can be pretty sure it is good. That rating stands front and center in the platform, and more importantly, the platform itself constantly promotes and rewards its star performers. On other modular systems, I usually spend a lot of time trying to sort out what modules are reliable. The Firefox module system has also done a good job of this.
3. Despite its habit of blessing particular development groups with special privileges, Apple also made it easy for the individual developer to become a super star on the platform. It did that by giving people pretty substantial development tools and a robust development environment.  If you want to get rock star developers you have to give them their version of the red carpet. That means awesome documentation, video tutorials and lots and lots of working examples.

I figured I would jot down these thoughts before the conference, so that I can have the most fun while there. Apparently, some of these people are actually reading this… so its a very efficient way of making points as opposed to taking the whole conference to dinner with a Fred-monologue.

-FT