Surely by now you've heard all about Twitter. I'm sure you have, so I'm not going through the awkward step of even describing it -- it's something so simple, and yet once you add the mix of people, of one-to-many, to easy and immediate communication the simple becomes so much more powerful and wondrous.


Well, if you've been reading around these parts for the last year or so, you'll also recognize Mologogo, which is a GPS-Phone based application for sending your location, viewing maps and friends and a bunch of other fun stuff.


To go back to the old commercial (no, not the "ancient Chinese secret" commercial -- the "you got peanut butter in my chocolate" commercial), using Twitter's fabulous API, we've mixed the two together and the result is even more powerful. Now, using Mologogo, you can automatically update Twitter with a description of your actual location. The message will say something like "Mologogo thinks I'm at 5th and 33rd street, Manhattan" -- and get distributed to your Twitter friends -- via SMS, IM and whatever other channels they have deployed.


So, if you've got friends or family using a phone (with SMS) or on some kind of IM client (AIM, for example), you can run Mologogo and let it send these descriptive updates automatically -- letting them know where you are, and letting them follow your motion through your trip, or even just through your daily travels. Fun stuff -- and probably more than just fun, too: an element of personal security ("I made it to Dallas"), publishing/participation ("Lookitme, I'm in the city!"), and so many other wondrous aspects to be discovered.


Open is great. API's make me 'appy. You can see where I've been, too...

GPS Chimes are wind chimes that are triggered by my proximity to home -- built with Mologogo and a Phidget Servo. Think of it as mile-wide radius around the wind chimes, where my networked presence and GPS location send a virtual breeze to announce my travel home.


More photos, instructions, background info, and source code available here.

#2) Tearing down the walled garden will enhance the mobile content experience and release value for the industry. The objective should be a free market for content and applications, based on open standards and accessible to all. We think the current fragmentation of formats and channels to market is holding back growth.

#9) The mobile experience is limited to voice and text by in-efficient search and discovery mechanisms. We think any service should be accessible from the standby screen and it should be as simple as dialling a number.

#8) Mobile devices are the natural choice for interacting with communities. Sharing experiences through your mobile device should be as simple as making a voice call. Wegravitymonkey thinks the success of user-generated content, social networking and community interaction through mobile devices will depend on enhancing developing innovative, mobile-specific paradigms of communication rather than replicating the desktop experience.

Stumbled on an interesting Slashdot post from Sprint about their developer program. I do believe the author is the guy behind Nextel's program -- hopefully Sprint will be able to adopt the openness of the Nextel position some time soon.

JSR 179 & OEM Location APIs: Location is a tricky one. The APIs themeselves don't require signatures, but getting the SDKs and tools with which to compile apps that use them on CDMA phones require additional approval. Nextel historically opened up the GPS APIs on the phone to anyone, and the only requirement was a phone-triggered privacy consent for location transmission; that's still the practice we're following for all Nextel phones. On CDMA phones, it's different--the location infrastructure that allows the GPS chip on the phone to get a location fix uses the data network more extensively than does the infrastructure on iDEN, and every location fix carries an actual monetary cost to Sprint. Our position determining equipment (PDE) servers on CDMA are sized based on certain usage assumptions, and a sudden spike in the frequency of location fixes that could result if that SDK were freely downloadable. We're working on changing all of that so that it's no longer a problem to distribute the SDKs, but it'll take some time.

...

I know that these things don't necessarily say what many would like to hear -- that it's all free, that all you have to do is get a cell phone and go for it, and that there's nothing standing between you and mobile glory. But there are options:

Try it on an iDEN phone....

Try it on a non-phone...

Drop us a line....

Link.

Steven Johnson's article in Slate "Geeks Without Borders" profiles an actual live (commercial) mobile game. In the U.S., no less:

San Francisco's North Beach has a long history of eccentric street culture, but if you find yourself in the neighborhood this Saturday, you are likely to witness a new twist: small groups of people clustering together to read text off of cell-phone screens, then embarking on some kind of oddball group activity—retrieving a suitcase that's been hidden atop a tree, persuading strangers to try on insane outfits—and then huddling together again to peer at their cell phones. This strange behavior is part of something called the Go Game, the creation of a company called Wink Back, Inc. (The next public game is scheduled for Feb. 22.) The game's creators scatter clues and tools across the city, and then wirelessly transmit a series of challenges to the teams as they prowl the streets.

...

It's urban Survivor with cell phones.

Steven mentions other immersive games, too, including It's Alive (although it seems their site is down right now), which was mentioned in the Rheingold's Smart Mobs (it's amazing that Mobs was published in 2002, and many of the great ideas profiled there have still not appeared stateside, or are just getting traction).

It seems to me that the creators of the Go Game, Wink Back, have a smart approach -- it's not just a game on a phone, but a game that is tied closely to mobility and actual location. The game isn't forced to live within the phone -- the phone is a vehicle for game play, say like the little 2x3 cards on a gameboard. The game itself is the city, and it interacting with others, including (it seems to me) hired ringers who facilitate the activity and fun in the real world. Hopefully I can find out more about this -- simple idea, but brilliant execution.

Linda Tischler's "The Beauty of Simplicity", from the November 2005 issue of Fast Company has a few nice stories and thoughts about technology and the battle between complexity and usability:

Here is how (Marissa) Mayer (Google's director of consumer Web products) thinks about the tension between complexity of function and simplicity of design: "Google has the functionality of a really complicated Swiss Army knife, but the home page is our way of approaching it closed. It's simple, it's elegant, you can slip it in your pocket, but it's got the great doodad when you need it. A lot of our competitors are like a Swiss Army knife open--and that can be intimidating and occasionally harmful."

And a great observation attributed to MIT's John Maeda:

On one level, he says, the problem is simply one of scale. Before computer technology, small things were simple; big things were more likely complex. But the microchip changed that. Now small things can be complex, too. But small objects have less room for instruction--so we get cell phones with tip calculators buried deep in submenus and user manuals the size of the Oxford English Dictionary to help us figure it all out.

Think of all the complexity in a airplane cockpit squeezed into your phone, and perhaps we have an image for all the power and features and complexity that could be brought to bear on the modern mobile. And with apps like Mologogo we've struggled with coming up with a feature rich, yet simple interface -- no small feat. Trying to develop along the paradigm of the modern desktop (the Windows/Mac UI + mouse + menus) for the phone seems like a foolish pursuit, no matter how well you do it will always feel small, cramped and crippled.

This may be an effective thought excerise regarding application features and any resulting UI: think about how you would build the same features in the era of tubes and hardware -- just how much of a monolith would it be? Replace each UI button with a real button, each mouse click with a toggle switch. How much heat would it generate, how much solder would you need, how many steel panels, how many sides? And how imposing would it be to use? Those dinosaurs, like the glorious old RCA Mark II that was housed up at Prentis Hall at the Columbia/Princeton electronic music center, are amazingly quaint to see today. Like some kind of Totoro-like benevolent form of monstrous wildlife.

Perhaps people don't typically treat a phone as something that we interact with so much as simply talk to. We're not looking for a conversation or interaction with a phone, or installed phone applications -- and what I mean by that isn't that the phone shouldn't or doesn't enable us to communicate: we're most apt to use the phone to "transport" us to another place to be (in conversation) with another human being. I could care less that it's a phone or a block of wood or a silver amulet.

Ubiquitous computing doesn't arrive until the computer -- or perhaps an object imbued with the sense of "technology" as the new and not-yet-commonplace -- disapears from view.

Thanks to Kottke for the link, and digging out the money quote.

Whether or not you agree with Bill Joy (cofounder of Sun and currently with Kleiner Perkins), he is undeniably a fascinating guy. I'm drawn to his writings and interviews, for his sense of humour and sometimes bewildering brilliance.

In this interview available on AlwaysOn, Joy describes different "types of webs", as related to the modality of the user experience. We've certainly heard the concepts about "lean-forward"/"near-web" or "lean-back"/"far-web" (which Steven Johnson attributes to Jobs in his most excellent book "Everything Bad is Good For You"). Joy describes these, and a few more:

"Then there is the far experience, which is that you are leaning back in more of an entertainment mode. It is a different way of experiencing the information. The near experience today is the web through your favorite browser, and the far experience, the passive one, is watching television but the active and interactive one is really video games. We were thinking about the near and the far user interface and really the near web and the far web—because the kind of content you have, the way you interact, your whole body position, your energy, what you want in those two different environments are very different."

...

"...we really liked what Wayne had said and [thought] there is more: There is also the here web, and the here web is the web to your mobile device because it's here, always with you. "

...

"Near, far, and here. The modality of the near web is mouse and bitmap display and menus, and that is the way we've done that. The modality of the far web tends to be joysticks and maybe gestures more generally or some interaction of pushing buttons—whatever we do in when we're playing games or interacting with entertainment. The modality of the here web is still evolving. Mostly it is a touch screen like on my Treo or cursor buttons up and down. It's voice intensive, and it's very personalized, and the screen format is very small. So the kind of information you have on these three webs is very different, and the style you use to interact with them is very different. To us, these seemed to be three very different modalities, three different markets. And then there is clearly a fourth."

Link to read more about the "Weird Web" and the rest of the article.

So, you wanna develop in Java for your Nextel camera phone? Let's say it's something simple like a simple snapshot program, much like Jonathan Knudsen's early tutorial: Taking Pictures with MMAPI. There are a bunch of particulars of the current crop of Nextel iDEN phones to consider, and the best source for that info is currently available at the iDEN developer site, in the form of the "Developer Guide 2005".

There's a lot of sample code out there, even in the examples above, to get you started. Although the i830 emulator claims to be able to use a webcam to provide functionality in the emulator, I have never been able to get it to work, nor find any information about how to get it to work.

However, I wanted to document just one aspect: how to get the app on the phone to test it. First of all, just to test the app on your phone, you'll need to sign it. Why? Because by default the phone will require explicit user permission to access the getSnapshot method -- thus if you don't sign the MIDlet, it will pause the MIDlet to ask permission, then restart, making for an awful lot of coding specific to handling the pause to get to see your app to work. Luckily most of the iDEN emulators and the iDEN J2ME 2.0 SDK include a tool to temporarily sign your MIDlet for 48 hours.

Here's how you do it:

1) Go to the bin directory in your iDEN SDK directory. For me, this was C:\program files\motorola\iDen SDK for J2ME (MIDP 2_0)\bin\.

2) In this directory you'll find a batch file named util.bat. Run it! If it doesn't run, that's probably because the keytool accessory isn't in your PATH. Typically this tool is in the bin directory of your JDK or JRE install. Add this to your path (i.e. To set the system path under Windows NT, 2000, XP, right click on My Computer and go to properties. Click advanced, then environment variables. From here, go to the system variables window and click path, and then add the full path to your JDK or JRE bin directory. Notice that the directories are separated by semi colons).

3) Once you run utils you'll see a little application that can do a few things for you. All I care about now is the "Sign Midlet Suite" button. Hit that.

4) Use domain "OPA". Enter the IMEI from your phone -- I found that the full IMEI from my phone was one number longer than the numbers the app would accept, but I found that removing the last number in my IMEI (which was a 0) was enough to make it work.

Okay, so that'll do you enough to build and debug a camera app on your Nextel phone. Lovely. It would be nice if the emulator worked, but this is better than nothing, right? Now that you've got it working well, the next step is certifying the code then distributing. Well, those are two decidedly non-trivial steps.

To have your MIDlet code certified you'll have to get a code-signing certificate from someone like Thawte or Verisign. And they require:

A. Valid Business License or Business Registration document

B. Articles of Incorporation or Certificate of Incorporation

C. Articles of Organization or Formation

D. DBA (Doing Business As), Fictitious Business Name, Trade Name, or Assumed Name registration

F. Charter Documentation (For Banks, Universities and Government Agencies)

Uhh, crap. None of the above match up for me, some little individual developer without a commercial entity to support. Besides, it's about a $400 cost to get the little digital ID, so that's a bit much for a guy who's mostly interested in giving applications away.

Anyway, there's always the hurdle that even if I get a DBA from the state of New Jersey, buy the certificate from Verisign, I would still need to get approved by Nextel as a certified partner in order to be allowed to access camera features without having to ask for permission (perhaps at all, perhaps every time...I'm not sure). Even getting that kind of buy-in from Nextel is not a given -- as the stuff I want to build with the camera are mostly software features that I don't want to charge for. That kind of flies in the face of any credible business model, including the need at Nextel to profit off of any software delivered through their networks.

So, there you have it. Some concrete advice to get a camera app on your phone, but still some hurdles left to overcome -- not technical, but perhaps all the more daunting. Let me know if you have any feedback on issues like the MMAPI emulator or the whole code-signing/certification process.

From C-Net News.com, an article about homebrewed cellphones:

Surj Patel is building his own cell phone, bit by soldered bit.

...

Patel says he has lost patience with even the slimmest Motorolas and most advanced Nokias. He has been trying to build new features for cell phones for years, and he--like a growing number of other impatient developers--has concluded that phones have to be as flexible as ordinary computers if he's going to make progress.

"I want the phone to be much more open," Patel said. "The world's best research and development lab is all the hackers out there. Enable them, and they'll do it."

...

Patel is helping organize an Emerging Telephony Conference with tech publisher O'Reilly Media in January, where he hopes to show off as many grassroots development projects as he can find.

Man, do I need to comment? How about a simple -- "Hooray!". Go get 'em Surj.

From Smart Mobs, an article in the New Scientist that describes a new concept from Sony Ericsson for a phone that essentially can turn into a remote listening device, by way of automatically picking up and using the speakerphone.

The new device provides a simple solution. Software on the handset checks the number of each incoming call against an address list, to see if the caller has been previously flagged. If they have, the phone rings in the usual way but switches to auto-answer after a predetermined number of rings. So the called phone becomes a live microphone listening to whatever is happening nearby.

The device can also be remotely switched to speakerphone so that the caller can shout “are you OK?” down the line and into the vicinity of the phone. If the phone has been set to voicemail, the caller can key in a code to override the diversion and force the phone into auto-answer mode.

It makes that sweethearting idea of Kottke's seem so innocent.

If you're using Phapper, you should really move on over to Mologogo (MObile LOcation). Not only did I finally address the North America only issue (which means this one has satellite maps), I'm working with a brilliant partner who's taken care of all the server-side issues and provided a ton of great ideas. You can now view friend's locations, follow a friend, annotate locations, etc. etc. Phapper is officially unsupported -- Mologogo is now the way to gogo.

Did I say "free"? Yup. Go sign up now!

From "Joy: Future of the Web is mobile devices", Mike Ricciuti, CNET.

"Personally, I'm very frustrated by voice. If you leave me a voice mail, it's not likely I'll get around to answering it. But there is a warmth to voice. It's a media that has been difficult to integrate with the Web experience. I have a friend who holds his notebook up to his head to use Skype. We need new formats."

updated 8/29: fixed library problem with both versions, so if you experienced any problems installing (verifying) phapper so far, please try again!

A new app from the labs at Gravity Monkey: Phapper. By now you may have figured out that one of the only reasons I like building stuff is so I can name it. Like, for example, the "liver". Who the hell named that? 'Cuz you need it to 'live'? Pretty literal, but nevertheless, must've been fun coming up with that one.



Back to the topic, and not just of rather literal names -- this new app I've got here is a PHone mAPPER. I thought about naming it "Elizabeth's View" after this classic (that is, a view from the heavens), but it got the "I dunno about that..." response from the missus.



Basically, with Phapper and your Nextel GPS enabled phone, you can see Google Maps on your phone [not in all it's AJAX'y scrolling goodness, but as a map, OK?]. Or, if you don't have a Nextel GPS enabled phone, you'll have to type in your address -- or whatever address you want, really. The phone figures out what zoom level and what tiles match up with your position, then grabs a composite image made up of Google Maps' tiles from the server (so you'll need internet access from your phone). Your current position is plotted with a little flag, and older points (if you're using GPS) show up with red squares. As the plots get older, they get lighter -- so you'll leave a trail of ever-lightening GPS spots about the map as you move around.

But, here's the trick. It's free, of course. Because it should be, and because I wouldn't want to step on Google's rights. Hopefully this falls within the sense of "fair use", and "Don't be evil". The other trick to it is that it's based on the tile scheme from the initial rollout of Google maps, before the integration of the Keyhole satellite imagery, which means there are some important caveats:

In an article entitled "'Write Once, run anywhere' not working for phones", C|Net writer Ben Charny identifies platform fragmentation as the primary source of difficulty for Java cellphone developers. Indeed, I've been asked by journalists about this, and failings of J2ME/MIDP seems to be the strongest meme circulating about why Java-based cellphone games and applications haven't taken over the world, as foretold by numerous analysts. Heck, we're all dissapointed that we haven't hit the hockey stick growth for mobile apps and games in the US, but I think we're getting off track. It's surely a collective malady that includes technical issues of platform fragmentation, but in my opinion it's hardly the primary reason for a lack of (expected) growth and true innovation.

Since it's all the rage to be closely reviewing and scrutizing journalists, I thought I would take a fine-tooth comb to the article:

But writing a program that can run on any handset still isn't possible.

Wow. Nice to start off with such a vague overstatement. Let's knock out the obvious contextual issues first. J2ME isn't necessarily on "any handset" as it must be licensed, developed, and supported by the phone manufacturers.

Let's assume "any handset" means "any java-enabled handset" (which is the majority of phones on the market for the past two years). An app that relies solely on J2ME 1.0 (and not 2.0 or other extensions, such as the Media API), that stays within the more restrictive limits of filesize (below 64k) for older phones, and doesn't use phone-specific classes -- the app could certainly be run on "any java-enabled handset".

Let's be generous and assume Ben meant something along the line of "writing a *useful* program that can run on any handset still isn't possible". J2ME 1.0 has it's limits, I'm certainly aware of that. But it's not crippling, and certainly not fatal -- you've got enough graphic and key-handling from the Canvas, and you've got a rich set of generic classes for network access, and enough of the core language to handle many other critical tasks (Threads, for example). Is that enough to build a *useful* program? Answering that is a bit subjective, of course, as myriad crappy games and crappy apps out there surely prove otherwise, but I would argue that you can get a useful app when limited to J2ME, and even to the 1.0 spec.

Instead, Nokia, Motorola and other handset makers have built devices using their own fixes for MIDP.

Fixes? I would agree with this statement if it read "using their own features to extend MIDP". And each phone manufacturer has their own extensions -- some great ones, some really necessary ones, some silly ones. But these extensions don't devalue Java, these extensions do exactly what they were intended to do: to add value to their phones, attracting developers to build for their devices. But these aren't fixes, per se, that address something that's broken. Instead these extend MIDP to do something specific and unique for their line of handsets.

"Fragmentation is the one major roadblock..." Allen Lau, CTO, Tira Wireless.

While I agree that fragmenation is an issue when trying rollout an app for the widest range of handsets, in my mind the *one major roadblock* to developers in the US is that the app distribution process is not consumer friendly, nor developer friendly. Application deployment is still strenous, although it's gotten signifcantly better.

Why is it hard to get and use Java apps on your phone in the US? It seems to me the carriers are still focused on calling rate plans, and pushing camera phones. Understandably so, as both can generate revenue in a proven manner. But data services, with all it's promise, continues to get either ignored or, worse, blocked. Perhaps it's a slippery slope the carriers would prefer to avoid -- from metered access, with pay-by-the-byte download charges to an inevitable consumer-friendly model of unlimited access (which the ISP world had to make in the mid-90s).

I can't take Ben to task for Allen Lau's quote, of course, although it provides the impetous for the tenor of the entire piece. I would guess Tira needs to protect it's relationships -- but as an independant developer with little power or influence, I see the carriers as a bigger logjam than the technology: I can solve bugs, implementation quirks, and handset differences with testing, good user feedback and by writing smart code that is well designed. I can't change carrier policies that forbid OTA (Over The Air) access, nor can I improve network speeds.

"We need to simplify the standard, and use open, fair and predictable licensing terms for the technology" -- Nokia CTO Pertti Korhonen.

Simplify the standard? That one I don't get at all. Why would you want to simply something that already serves as essentially a baseline? Is it too complex for Nokia to implement? Not at all, they've got a great, solid implementation of MIDP 2.0. Does Pertti want to strip features out of MIDP? I doubt it, as Nokia keeps adding on new features as extensions. The more telling part of his statement, in my mind, is the "use of open, fair and predictable licensing terms". Could all this rumblings about fragmenation and issues with Java, and more particularly with Java's slogan of "Write Once, Run Everywhere" actually be tied to a pushback from the handset manufacturers about licensing costs? This I know nothing about. Is Java playing hardball, now that they've got a wide user base with the manufacturers, and a growing economy of developers and companies?

Meanwhile, hardware makers were busy producing cell phones that were like snowflakes: No two were alike. Some had huge screens and tiny dial pads, others just the opposite. Application makers have had to account for the nuances or risk severely limiting the reach of their products.

First to the "cellphones that were like snowflakes" -- a great phrase. Naturally it's still a growing industry, and with the push to combine the phone and the PDA, we see a lot of great experimentation going on from the phone manufacturers. Developing for a nascent platform -- the cellphone -- certainly has its risks, but there is certainly a moonshot aspect of being the first one to play in a new industry. Developing on a changing spec on a nascent platform -- Java -- is an equally risky proposition. And while the hype and PR around J2ME might overstate it's role, Java has become the platform that will work across almost all carriers -- the alternative would be having each phone manufacturer with their own distinct and proprietary API, or being stuck with a higher degree of abstraction, such as WML.

And, yes, the phones are all different sizes, shapes and colors, with different capabilities. It's not a new problem, nor is it unique to Java or cellphones. If you build a 3D first person multiplayer shooter for the X-Box, you're not bemoaning the fact that you can't deploy it for the Game Boy. If you build a phone app that uses Motorola 3D, you make that as a business and design decision early in the process -- you don't stand around at release with your hands on your hips wondering how you'll port it to the Blackberry.
For me, it feels a bit like the browser wars of the mid-90s. We were all building websites as quickly as we could, trying to take advantage of the next great Netscape feature. And yet, you were stuck with a userbase that were trapped behind slow modems or older browsers, on tiny monitors or slow computers. Developing for cutting-edge features or new devices has it's risks and it's rewards. As a developer you weigh those risks, everyday, every step of the way. Should you make two or three logos for the splash screen, so it will fit on a tiny 85 pixel screen, and the 180 pixel screen? Or draw it and make it scale using simple math? The answer is, as usual, "it depends".

"It can take up to nine months to deploy an entertainment application," said Craig Hayman, vice president of carrier marketing at IBM. "But that's the duration of a cell phone in this market."

What? Really? I think there's exageration on both sides of this statement. Nine months to deploy an entertainment application? It's what, 150k as a finished application? That's like an output of 1024 bytes a day. But seriously, while any project can drag on, even for a multimedia packed game, J2ME provides developers and designers with a limited palatte, both as a platform and with limitations of filesize and performance. It would seem like you need to employ a project development model more befitting developing a console or PC game.

And if you are developing for phones that people only use for nine months, then that's a consideration you make up front. Again, developing for the bleeding edge has it's risks and rewards -- but that's a development decision, not an inherant issue with Java, or platform fragmentation. In my experience, the device topology out there is way more varied that I ever expected, with many new devices in use, and lots of users with phones that they love that are 1 year, 2 years, or 3 years old.

"It's amazing what you can do now, thanks to Java, with a $99 handset. But write once, run anywhere isn't close." Jason Guesman, VP at Seven.

While Sun seems to stand behind the concept (it's nowhere as prominent as it once was in their corporate messaging), remember it's nevertheless a marketing slogan -- interpret literally at your own risk. In my mind it is close, and amazing that I can build an app, on my laptop, and upload it to users around the globe on numerous phones with different hardware and software, and countless carriers -- and have it work. Perfectly? Of course not, but nothing is. Not even if a marketing slogan promises so.

Ben's a good journalist -- I've long enjoyed his work covering the industry. There's no bias against Sun or Java, Charny penned a similarly alarmist "Has Qualcomm's BREW gone flat?" for Ziff Davis in 2002. In fact, the overstatement in the title and summary of this article smells of editorial zeal.

Once again the TMobile Sidekick (the insecure, but still agonizing slow-to-open-to-java-developers, platform by Danger...oh, that's a corporate name you gotta regret right now. Wait, "Thinner, better, easier to use", is that in reference to the device, or Ms. Hilton?) has been "hacked" and important data released to the general public. No, not as bad as hacking the secret service guy's sidekick, but didn't everyone want Victoria Gotti's phone number?

Dang, what a shame. Nice device, great idea, and seemingly solid execution. Slow, dumbass, totally mishandled rollout of their API. But that's not enough bad karma for me to even wish them this mess. Who's gonna take the fall for this PR nightmare -- T-Mobile, the web systems that let you hack into the backend, or the device itself? Or perhaps they were slow to release the API because of architectural security holes? Probably a post-mortem for a business school kid in a year or two.

[EDIT: Check that. People are sheep. Sales are soaring....which proves being cool is much more important than some obscure abstract sense of security. The only security people need is to be part of the in-crowd.]

The ever intelligent Mike Masnick makes a great point in an post called "Why Mobile TV?" on TechDirt Wireless about the Mobile TV hype in places like Gizmodo, or here, or here.

Again, it always seems to come back to a single issue: mobile devices are primarily communications devices, not broadcast devices -- and most of the mobile TV efforts seem heavily focused on simply moving the TV broadcast experience to the phone -- which just doesn't seem that compelling.

This does raise two possible questions to contemplate:
1) short of true "video phones", a'la Dick Tracy, can video be used in a manner more befitting the true idiomatic use of the mobile phone? Video on a phone that's more like true communication, less just watching old news clips?
2) the discussion of "broadcast versus communication" or a "one-to-many versus one-to-one" is a very valuable way to frame the discussion of the merits of any mobile application. It's clear that simply transposing a successful broadcast framework to the mobile (like TV, or even the web, for that matter) might be useful -- sometimes-- it fails to truly address, or perhaps adapt, to the way in which the content itself is being accessed and consumed, and the context in which it is most valuable.

[btw, title quote from Orson Welles]

In the best interest of both reminding myself of stupid mistakes, and getting a googled answer out there for the world to also avoid said mistakes, here are two stupid errors I've encountered in developing with the RIM Java Development Environment and the Blackberry Simulator:

1) If you're using the Blackberry simulator and connecting to the internet, turn on the MDS Simulator. This seems straightforward, once you realize the issue, but if you're getting your feet wet with using a connected Blackberry by developing for it, you may not realize the need for a Mobile Data Server, nor the need for running the MDS simulator when running the device simulator.

2) VerifyError: If you call a primitive that is not a part of the MIDP package (such as double or float), the app will compile fine in the development environment, but it won't verify and won't run in the simulator. Basically, if you run into verify errors with your Blackberry app, check to see that you're in compliance with any libraries or primitives you may be using. In my case, I was running into a problem with a graph that was looking funky because of overzealous int rounding, so I changed 100 to 100.0. Duh! After a lot of fuss trying to find the problem, including cleaning up my project and workspace, etc., I figured it out through a post on the Blackberry developers message boards (not google-able).

Dan Terdiman of Wired News reports on NOAA providing their local weather forecasts via a SOAP interface. A sample page is available here -- with a source input of lat/long.

The article focuses mainly on the role of companies such as Accuweather in lobbying to avoid such general and open access. Sure seems like a simple thing to build to have a direct contact from a GPS position direct to the NOAA server...

An interesting article about the NFL and their anticipated growth of mobile/wireless features, with potential profits in a few years projected at $30M. Of course the NFL has a pile of dynamic content to distribute to millions of rabid fans -- the NFL Network is a great example. The rinky-dink combination of current mobile offerings (WML -- which is not updated quickly enough or accurately enough, Palm apps, ringtones, voting for Pro Bowl players or MVP, etc.) seem to be hard-pressed to total the kind of revenue hinted at in this article, but the ever-expected onslaught of 3G speeds may provide highlights or live video coverage to phones.

More likely revenue generators? In the near term the "Gamecenter" would make a perfect and easy port to a Midlet, and up-to-the-minute Fantasy Tools would also generate significant revenue -- who could've anticipated that having control over active/inactive lists at 1PM would be worth so much money?

The NFL's cellphone ventures are growing so rapidly that by the 2006 or 2007 season, some league officials think, wireless could generate as much profit as conventional services delivered through league Web pages and the associated advertising.

...

Pro football's ventures into wireless are "in many ways just the beginning," said Chris Russo, the NFL's senior vice president for new media. "We expect continued growth over the next two or three years, and wireless has the potential to equal or exceed what we're doing on the Internet."

Russo declined to offer specifics, but people familiar with the NFL's online operations estimate they currently gross about $140 million, yielding annual profits of $35 million to $40 million.

The full article is here.

And, hey, if we're talking about what fans would pay money for -- how about selling the coaches film footage? Maybe not each week -- even if just the last season. It's nice having that funky floating Madden-esque camera behind the LOS, but I'd love to see the secondary through the whole play.

The W3C is considering a W3C Mobile Web Initiative that will seek to ease Web access from mobile devices. Computer World has an little bit about it, with a link to numerous "position papers" from notable vendors, large and small, about infrastructure, best practices, considerations, etc.

As a guy who doesn't read the paper any more, but instead relies solely on a rather arduous morning ritual of wading through pages of worthless navigation content to get at the guts of stories from non-local favorites (such as the WaPo or ProJo), it's interesting to see what different companies see as the issues and the hurdles to moving forward. In the case of the Blackberry, the RIM power point PDF on the site, focuses solely on what they currently have, and the alphabet soup of protocols and languages they support -- seemingly suggesting that the status quo, of accessing exisiting web content from the device is sufficient -- hint, hint -- it's not. But there is also a very nice piece by the bright guys at Opera, including:

Use cases for the mobile Web

There is no separate mobile Web, any more than there is an office Web, a home Web, a leisure Web, or an airport Web. The ways in which the the Web is accessed, depend on cost, technology, usability, and situation. Initially the cost and technology constrained Web use to data look-up or download and as infotainment while travelling or in similar situations. As phone browsing becomes more fun, the Web use becomes more diverse.

How the mobile user experience differs from the fixed user experience

The differences can be summed up as adding constraints and freedom. With a phone you need to do more with less, and the constraints are most obvious to the user. It is slower, has smaller displays, is more expensive, and has lower usability. In many ways the mobile user experience is burdened with the same accessibility issues as people with disabilities. It also offers freedom. With the mobile Web you bring your computer with you. This gives the mobile Web an immediacy the desktop Web experience does not have; it is more social, and it can adapt to where you are.

Brilliant! Timo Bruns and Ove Ranheim, kudos to you. There is a successful Symbian Opera browser -- I wonder if there's any hope for a Java one as well? Hopefully I can take the time to read more of the documents. But, damn it, I'm gonna read it from my mobile. So much for your powerpoint PDF, RIM.

Somedays, in my most self-pitying mood, I wonder why the world hasn't moved faster to embracing mobile technology, and GPS cellphones and the like. Surely I understand the Big Brother fears, surely I see the reticence from carriers from moving too quickly into uncharted territory.

And then, the worst fears realized, as Mark Frauenfelder and the RFID in Japan blog discovered the news -- a girl abducted and killed in Japan, while her family received tormenting messages from the captors via her tracking GPS cellphone.

While the GPS system didn't necessarily contribute to the crime -- she was seemingly stalked and abducted without benefits of GPS tracking (unlike this case a few months ago) -- the technology, in the end, couldn't save her either. As Mark makes the case in his links, tracking is not a substitute for good parenting and trust. At the end of the day, as so much new technology is embraced first for evil (or illegal) instead of good (witness the "pager = drug dealer" sentiment of the 80s), it certainly gives me pause to think of any innovations I can create, and potential misuse.

red | blue is now available in three flavors -- the original Nextel GPS version, a version for Blackberry, and a quasi-generic version for any Java/Internet enabled cellphone -- just in time for the stretch run to the election.

With inspiration and data from Mike Frumin and FundRace.org, red|blue transposes the experience of looking up individual campaign contributions onto a Java-enabled phone. With a GPS-enabled phone, the application will take your current location and figure out if you're in a Democratic area or Republican area. The app will also take this information and plot it around you -- in a compass -- to show which direction the money comes from. It's fun to walk or ride about the city, and see how the money changes -- and see how that's reflected in nature of the neighborhood or your surroundings.

For the many without GPS capability, you can enter in your current address, or your current zipcode to get the same data, if you use either the Blackberry or generic-java-cellphone version. These versions aren't quite tweaked out to optimize for the device, it's more of a general J2ME version that will be subject to the whims of your handset's implementation. You get the idea, tho'. It would seem silly to do something like this without a Blackberry version, right?


You can find out more, and download files for installation. The apps are also available on Handango, which will give you more support and structure to manage the install process -- which is varied by phone and carrier. Use the Free Trial Version -- it's fully functional, no need pay any money (I need to offer a version for $$ so that they will list it). If you install it and run into any problems, or can share any phone or carrier specific tips -- lemme know!

Boing-Boing covers a news story about a guy in L.A. who was stalking his girlfriend with the aid of a Nextel GPS device. Not sure which device actually fits this description:

"Gabrielyan had purchased a Nextel phone device that has a motion switch on it that turns itself on when it moves. As long as the device is on, it transmits a signal every minute to the GPS satellite, which in turn sends the location information to a computer."

I wouldn't mind finding out more about it, as I can think of legal ways to leverage that as a data-gathering device (GPS or not).

My first reaction, truly, is a slow, dissapointed sigh -- not in the nature of this man's inability to deal with his own shit instead of terrorizing someone else with the aid of modern technology -- but in that the takeaway from this, for the press and in the general public, is that GPS for consumer applications is inherently dangerous, ridden with privacy issues, and only useful for nasty-ass big brother applications. I've built a few tracking/GPS cellphone apps, and I've scaled back planning and prototyping way back to avoid the inevitable sense that it has some evil use at it's core. While I certainly feel that perception needn't be that way, I'm not naive enough to think that advanced tracking and location wouldn't be used for breaking the law.

I'd love to build a killer app for GPS on the phone. Just not literally.

In a unique attempt to appeal to new audiences, the Royal Opera House will perform a new opera in an undisclosed location via flashmob.

It's a great idea to get some publicity and get more people exposed to the genre. Hard to imagine how that would go over, for example, here in New York. I think most people would be pissed there was crap in their way. Still, bringing an opera via a new and hip method of meeting (the flashmob), seems like a promising idea, especially with a new piece that focuses on a contemporary story line.

I've been thinking a lot of the role of "high art" (for lack of a better term) and the role modern art plays in a commercial society. Peter Bagge's incredibly funny, and incredibly spot-on indictment of modern art and it's institutions has had me pondering a lot about the relationship of life - my life, I guess -- and some of the more esoteric and abstract aspects of contemporary art that I love. Having been outside that world for almost a decade now gives me a good bit of perspective. In the end, I feel, it's not the language of modern art that has failed (except, as Bagge points out, the end-in-and-of-itself of pure performance-arty shockvalue). On the contrary, the language of the modern (or, perhaps early/mid 20th century abstractionism, both in music and art) has a solid place in daily contemporary life -- but the medium itself has withered away at it's core: concert music, galleries, museums, record companies, and especially the supporting infrastructure of academia, blue-hair arrogance, non-funded non-profits, and the deification of old(er) commercial art and music (i.e. Gentrification-via-Marsalisification).

What the hell am I saying? I'm not sure exactly. But read Bagge's comic, it's funny and smart. And note that in all the publicity that this flashmob opera is getting, not a single one of the articles mentions who wrote this new opera -- neither music nor libretto.

From boingboing: word of a Hong-Kong company making a mobile game not unlike the tamagotchi, but instead a cute blob, you've got a virtual girlfriend. Her primary motivation? Getting you to spend money on her. No need for me to comment -- Xeni's got it covered.

Not sure what the interface is like, but the screens are of rich rendered images. They are awaiting the coming of 3G. The BBC has details. The press release about this product, following shortly on the heels of a earnings release devoid of earnings, is available on their site.

From the San Jose Business Journal:

"Mobile gaming is catching fire, thanks to the explosion of color phones and the desire by carriers to charge for services other than voice. Although mobile gaming is more prevalent in Asia and Europe, several U.S. startups are making a serious play to become the Electronic Arts Inc. of the mobile world. And VCs want in."

Good news all around -- not just for the fact that companies like Jamdat and Digital Chocolate are going to have enough staying power to be a true force, and to hopefully forge into some innovative land (hopefully dragging the carriers and their antiquated distribution with them), but also the fact that the VCs see a valid business to be made of killing time on the phone.

Now, if only I could be happy enough with my stuff to finish up another game...

Here's a nice solution to aggregating photos and GPS data, which I found as a link at Elastic Space: Tokyo Picturesque, which maps images onto a satellite image of the city, and lets you browse through them.

Never quite figured out what to do with the gathered images from whereabouts over there -- but this does prove a simple and elegant interface can provide a compelling way to go. But I sure ain't there yet -- perhaps if I continue to pile up the pictures, I'll get enough source to want to dig back in.

The Complete Guide to Isometric Pixel Art provides a nice tutorial about the basics of creating images from an isometric perspective -- perfect fodder for game development with J2ME and the MIDP 2 game API. Also with links to the crazycool eBoy -- with works that look like someone just started off adding buildings to SimCity 2000, and never stopped.

New York City plans to build a public safety wireless network, including the capacity to provide tens of thousands of cops and city workers with the ability to send and receive data while traveling at speeds of up to 70 mph citywide.

Okay, cool enough. How about using the system to helping the residents -- like find parking spots, avoid congestion, and issue location-based calls for help?

Found a reference from a fine blog about Java by Matt Croydon for a J2ME RSS reader (with source). I'll have to try it out -- not so much for the techie-ness of it, but to see if the experience of reading blog feeds (which are so often only relevant and important vis-a-vis the content they link to) is worth the effort.

Away on vacation, visiting family (as you can see by my last location on the right, and the lack of activity recently). I've tweaked and polished red | blue for release, available here.

By taking your current GPS location, and finding the nearest individual donors of campaign funds from the publicaly available data from the Federal Elections Commission, red | blue is able to provide you an accurate reading of the political leanings of your surroundings -- red for Republican or blue for Democrat.

It really works well -- I'm pretty impressed with what it can do, and the speed of development. The magic, of course, if there is any, is the power of democracy, and the fact that this data is not only available but can be used to provide a curious, possibly powerful window into the flow of money (thus, influence) into the political machine.

A big thanks to Mike Frumin at Fund Race for the geocoded FEC data.

Gizmodo covered an app for the i730: it's a status light java app, which amazingly isn't part of the default UI. The author, Michael Blake, related a total horror story via email about distribution, hassles with existing Nextel publishers, and nasty, lying pirates who have preyed on him and his app. Without OTA download, he's left with cobbling together his own DRM and security scheme, and stuck with putting in *way* too much effort to release what is fundamentally a simple solution for a simple problem.

Add this to the Christmas wish list -- Charmed Labs is selling a kit to extend the Game Boy Advance. Covered in the typical dry fashion over at Dr. Dobbs this month, it seems like a wonderful playground for low-cost, mini or embedded applications.

The GBA does has a bit of a following of developers working on homebrew projects with "limited" budgets.

From the Fierce Wireless newsletter,
Symbian's David Wood paints a wonderful picture of a mobile phone open standards movement.


This first bit doesn't sound unlike the old standy "Write Once, Run Everywhere":

"The real power of open phones arises when the third party experimentation that is carried out for add-on services on one phone can be re-used for add-on services on other phones. This allows an enormous third party development ecosystem to form. These third parties are no longer tied to the fortunes of any one phone, or any one phone manufacturer. Moreover, applications that start their lives as add-ons for one phone, can be incorporated at time of manufacture in subsequent phones, including phones by other manufacturers. "

"The degree of success of an open phone platform is closely linked to the degree to which the functionality of all lower levels of the software and hardware stacks in a phone can be accessed, modified, and augmented by add-on software and hardware. Java makes a good start. MIDP v1 allows modest access by add-on MIDlets to phone functionality, and MIDP v2 takes the situation further. However, for the foreseeable future, a native programming language such as C++ will remain the best way to access many of the lower level or deeper aspects of the on-board functionality. Native programming interfaces greatly multiply the overall opportunity." (emphasis added)

And here is where the rubber meets the road.

Symbian is undoubtedly the best OS for the phone. All others are either too dumb and simplistic -- like an overzealous LED display -- or overblown (MS Phone). Features, ease of use, years of experience in the field, have got Symbian years ahead of the competition in terms of pure quality, stability and ease of use.


Symbian should take page from their foe in Microsoft -- and work very aggressively to make Symbian the defacto OS on phones. Indeed, this is the implicit message in Wood's article. Remember when your computer was either an Apple or a IBM PC compatible? It's not an IBM PC compatible anymore -- it's either a Dell or Gateway or Compaq -- or more often referred to by OS, simple "XP" or "Windows 2000". Give the licenses away for free to handset manufacturers, but brand the phone with an "Symbian Inside" strategy...make sure that consumers realize that it's not Nokia that makes the phones great (although there are many aspects of their hardware that are great), but the OS itself. When a consumer buys a PC, they check to see what OS comes installed. When you buy a phone, you're really just guessing -- figure that you'll have to suffer through a night of reading the tiny manual to figure out how to get your phonebook to work again.


Oh, and the other strategy from Microsoft that Symbian needs to look at? The famous Ballmer scream: "Developers, developers, developers". Wood says "...for the foreseeable future, a native programming language such as C++ will remain the best way..." This makes me cringe. What forseeable future? Does this signal a unwavering stance on C++ as the Symbian development environ? No commitment to an abstraction layer, java or otherwise, that could more easily enable the open standards noted earlier? Or towards anything -- like VB, Hypercard, whatever -- that would allow a widening of the developer base?


Symbian IDEs and compilers that will work for C++ will still require upfront investment, both in terms of buying software and a Symbian specific learning curve. Legions of geeks and developers with more time between classes and late night Playstation sessions are going to get energized by toolsets and emulators they can download and use for free, not by slogging through a horrible Borland IDE.


Of course, I'm biased. I think that the open standard is here -- J2ME and PJava. Symbian does play ball with Java, but as a VM it lives on top of their OS, and lives quite nicely upon other OS's as well. Symbian is heads-and-shoulders above the rest -- and throwing their entire weight behind a full, robust java support and access to onboard functionality wouldn't strengthen rivals as much as continue to propel Symbian to the center of the ecosystem of openness he describes.

I can't stand Jakob Nielsen. I'll have to go into why some other day. But he did write a good article on his site covering a study about why listening to people talk on their cellphones is so annoying, mistitled "Why Cell Phones are Annoying". Not to sound too much like the NRA, but cellphones aren't annoying, it's the people that use them.

 Most of the results are pretty obvious, including "people pay more attention when they hear only half a conversation" and "It's apparently easier to tune out the continuous drone of a complete conversation." But, in typical Nielsen Listen To Me fashion, he says "If mobile-phone vendors want to avoid a backlash against their products, they're well advised to heed these findings and launch a major effort to make mobile phones less irritating to bystanders." By what? Selling them to mute chimps? By rolling out that brain-wave reader feature? People talk on cellphones, doofus.

The New Scientist is reporting (and the blogosphere is resonating) about software that scans an existing database of images to define your location. Claims are made about it's superiority to define orientation and a level of detail that surpasses GPS. Man, if you need to launch an app to talk to a huge database to figure out if you're facing left or right or north or south, instead of being able to read a map, then....well...you're probably too dumb to figure out how to use the freakin' tool. Or a robot.

Mark from Boing Boing has a new article on The Feature about Trip Hawkins' new mobile game company, Digital Chocolate. Details are light, but I do like the idea of a working metronome on your cellphone. But, geez, with that much financing, can't the develop a tiny DSP chip that will turn your cellphone into a guitar tuner, too? Time will tell.
 It's a good thing, of course, to see more energy in the mobile space for games and applications. Hawkins' considerable industry presence will only help everyone.