Mike Rowehl: This is Mobility

One of my long standing pet peeves is that I can’t set tags when I send a photo from my phone. There were some postings a while ago about a MIDlet that posted to Flickr, but I couldn’t find it. And I haven’t written any MIDP code since early 2003. That’s a long time ago in Internet time. It translates on the Great Internet Timeline scale to somewhere around the Tiassic period. I really needed a quick refresher. So I fixed both problems by making a MIDlet that uploads images to Flickr using the POST based API. It’s ugly, it’s full of bugs, it doesn’t start up right the first time you try it, it can’t capture images unless there’s practicly nothing else running. But for me at least it works. So I’m going to invoke the “Release early, release often” mantra and just toss this one out there. If you want to give it a shot download here. Here are the basic steps for use:

1. Start the app and bring up the settings form. You might have to start and exit and start again the very first time in order to get it to work correctly. There’s probably a problem there with the values for the defaults… I would test it out and find the bug. But that means uninstalling it to clear the record store, reinstalling to test out a fix, uninstalling again to retest. You see the problem there? The whole thing smacks of effort.
2. Fill in your username (that’s your email) and your password. Fill in the defaults with new values if you want. Please keep the “fwing” tag as part of the tagset you use. You don’t have to, but consider this a kind request from the guy who released the project. I want to see how many people use this.
3. Go back to the main form and fill in the title, description, and tags you want to use. Remember to please keep the fwing tag, see above.
4. Select capture to go to a camera preview screen.
5. Once you have a picture you like framed select capture again to snapshot it. Pressing in on the joystick should capture an image as well. But look at that, it doesn’t! It used to do that in the original sample from Nokia, but that one only captured images at 160×120. I’m sure it could be added back in. That is, it is theoretically possible to add it back in. The theory does not account for my laziness however. I’ve found that to be a general issue with theories.
6. Select send if you want to send the image to the server, or back if you want to grab a different image. There should be a progress dialog there to let you know how far along it is. But the upload can take a long time, and I was sure people would get bored. So I included a little mini-game. It’s called “Guess How Long the Upload Takes”, and you play by staring at the screen until the info dialog comes up informing you of success or failure. You can even play multiplayer using a single handset!

You can keep looping and capturing and sending images with the same set of tags and description/title. That’s about all it’s good for, cause that’s what I normally do. You don’t like it? Think it should allow you to return to the top level and tweek description for each photo? Think there should be an option to pull images from the filesystem? Think it should spool images and upload in a batch? Think the bugs are too annoying to deal with? Good. This is the code for the initial version, download it and fix it yo’ damn sef. If you want to be really cool, send me patches or release your version and send me a note. License is GPL.

I’ve personally tried this out on the 6680 and the 6600, and it works on both. I’m assuming it should work with the 6620 and maybe a few other models. The image source is the back camera on the 6680. I have yet to find a way to capture from the front camera via Java. Images are captured at 640×480, try for any larger and the snapshot call consistently returns an exception. Not that I’m a Java programmer or anything, but there are some bits of code which may be of interest to some folks:

• I had heard that the image resolution for captured images on the 6600 had to be the same as the display resolution when you’re working in Java. Not true. If you initDisplayMode() on the VideoControl with USE_DIRECT_VIDEO then just about any parameters you pass to getSnapshot() either cause an exception or get ignored. But if you init with USE_GUI_PRIMITIVE then you can getSnapshot() in the size you want. Well, not quite the size you want. I can’t get a full rez 1.3 megapixel image from the rear camera on the 6680, and I REALLY WANT ONE! The code I started with came from a sample on the Nokia site.
• The 640×480 image is resized to 160×120 using a quick hack of an image downsampling routine I found online. Check out the scaleImage() routine in DisplayCanvas. It takes an immutable image and a width and height, and returns another image with the given size. J2ME doesn’t have an image resize available as far as I can tell, so that little routine might find it’s way into my standard toolkit.
• The submission to Flickr is done as a multipart form POST. There’s a horrifically simple cover called MultipartHttpConnection that covers HttpConnection. Create the class giving it the URL to use, then you can addParam() and addFile() as necessary, and send() it when you’re done. I tend to do a metric buttload of server interaction on just about every project, and if it’s not XML it’s multipart forms. So that one is probably another keeper.

There’s a panel on mobile gaming in Palo Alto next week. Mike Nelson, the moderator, spoke at the games focused Mobile Monday in March. Him and I met up before the event and talked some about mobile games as a whole and the tendency to port existing titles to mobile platforms. Him and I both agree that simply viewing the mobile device as a scaled down version of a standard console leaves a lot of value on the table with respect to mobile games. Not that there’s no room for a good port, there’s some great stuff out there. But I expect the real explosion in usage will come when games begin to recognize more that the mobile device is more than just a small computer, and the situated nature of the game experience and available network connection (and short range wireless) begin to have greater impact on game design. Fooling around with the PSP a bunch has made me realize the way that multiplayer portable gaming works out. It’s not really about having the game with me all the time so that I can fill up bits of time (I do that reading news), but the ability to bring the game to where my friends are. Unfortunately, the PSP is too big to carry around all the time. My phone is always in my pocket, and it’s in my hand when I’m wearing something without pockets. If that were the way I played games when I bump into my friends I don’t have to ask the “You have your PSP with you?” question.

Christian Lindholm tells a story about a presentation he gave where he asked how many people had iPods. It was at a tech conference, so almost everyone raised their hand. Then he asked how many people had it with them, and very few people raised their hands. He says that’s why he doesn’t consider the iPod a mobile platform. That’s a fantastic point: “portable” does not mean “mobile”. Even if it does fit in your pocket and you can operate it with one hand. Just because you CAN bring it with you, that’s not impressive. The impressive part is that you DO bring it with you, all the time and everywhere. When people like Russ and Christian and Anita and Jason and I talk about mobility we’re thinking about a device that’s with you all the time. It’s your connection to your friends and family. It’s your lifeline for work. It’s your calendar and your contact list. It’s a mindset that’s removed from the physical and technical specs of the device itself, and centers around the way that device fits into your life. For a lot of people games and play are the natural points of contact with their friends, and I think some well designed games and game-like services could go a long way toward making people understand the role that the technology can be serving in their lives.

Russ and I went over to the BayCHI event this evening, which included a presentation about running a usability study for mobile services. Here are the five distilled best practices that came out of the data Scott has been collecting:

• Use familiar names as labels for the options. Call the options “Ringtones” or “Downloads”. Using names like “T-Zones” or “Get It Now” just causes confustion.
• Allow purchase from the media list. When the users sees a list of wallpapers they have, there should be an option right there to fine more.
• Link to the download from the web site. People launch the browser to go looking for stuff to download, they should see the option right there. Example given was Verizon, there is no link to the Verizon store from the VZW website.
• Always start the browser on the same page. It seems like people might switch away from the browser and return to their task, but in reality this causes confusion for most users.
• Include previews. Of course people want to see what the image will look like and hear part of the ringtone before they purchase.

The July Mobile Monday was a huge success. Some of the presenters complained about having to compress their demos down to 10 minutes, but everyone (and I mean, literally, EVERYONE) in the audience really like a the pace of the event and that we kept it rolling. Mobile Monday is a more community focused event than many others, so we always go for quick and compact doses of information that will get people thinking and hopefully interacting. Last night was a stunning success I think. There was one particular aspect that I wanted to put down, cause I think it’ll be of interest to anyone looking to demo mobile services. All the demos were great, but I think the ones that had the greatest impact were the demos that attendees could participate in.

Three of the demos had components that actively allowed attendees to participate. The demos by Sixth Sense and fotochatter were seeded with messages to the discussion group getting people to sign up for the service so that they could participate in the live demo. I think this worked out fantastic! With a standard demo going on all the energy is up on the stage, and people are sitting listening to what’s going on. But once the cell phones start going off in the audience people feel more immediately involved. They laugh and show off their phones and start interacting with the information. It didn’t cause loss of control of the demos either. The presenters at the front had no problem getting attention back to continue onto their next point, and the audience seemed even more engaged and attentive afterward. The one thing I would have added was a nice quick sign up and app download. It would be great to have people be able to sign up and get going right then at the demo. I know all the reasons why people keep the registration process mostly on the PC, but I still think it’s wrong. Let sign up for your service be as much of an impulse event as possible. Let one user recommend it to a friend and start using it right there at the gathering they’re having, without needing to go back to a PC to sign up and then use at some future point. If I’m at a concert and someone tells me about photo sharing software they’re using, you bet I want to start using it right then. Delaying that event will cause a lot of loss in terms of users. When I sign up later at my PC there’s nothing for me to do, I’ll probably forget about the app pretty quick. The positive use I could have had at the event where I heard about the software is a powerfully marketing tool, use it by enabling it. You need to be able to capture that event if you’re working on a mobile social application. The software and service are situated and realtime, the sign up and start of use should be as well.

Then there was the demo by ipsh!, who were talking about how they run advertising campaigns that include service like messaging notifications, wallpapers, ringtones, and some specialized point of sale equipment. It would seem like this kind of stuff would be old hat to a bunch of mobile enthusiasts. NOT AT ALL!!!! When asked how many people had bought a ringtone, almost no one in the audience had. Even though the ringtone market is big, and people pay a lot of attention to it, the purchasers of ringtones are not always the folks who are building mobile services. The demographics just don’t match up. So when Dale told everyone they could message their birthday (in mmddyy format) to shortcode VODKA (86352) and get a free ringtone and wallpaper everyone pulled out their cell phone to give it a try. It grabbed their attention, it involved them, and even though it was a simple use case in terms of technology it was novel for the group. Cell phone beeps went off all over, little jingles started playing, it was fantastic. This was an excellent example of what happens when you lower the barrier for participation. Even in a group of people where many are aware not just of what the ringtone and wallpaper markets are, but how big they are and who the major players are, allowing people to try out a service right then when it grabbed their attention still dominated their actions. Even though the ringtone and wallpaper were effectively a marketing message from Absolut, it was engaging and interesting and people enjoyed it. The fact that a wallpaper and ringtone download created so much stir with the group is just further proof in my mind that there’s a ton of potential in mobile that people are overlooking because they don’t really respect the personal, realtime, and situated interactions that mobile services allow.