Ripping mobility from the clutches of telecom
Archive for January, 2008
m.youtube.com from ATT/Cingular
Jan 31st
While putting together the YouTube linking support on Mowser I noticed something odd. If I bring up a video from m.youtube.com while using the cellular connection in my N95 the flash player errors out before the video starts up, but if I connect over wifi the video plays through no problem. I don’t want this to turn into yet another carrier behavior rant, so I’m just going to ask if anyone knows why that would be and what I need to do to get that fixed.
February 2008 Silicon Valley MoMo
Jan 29th
I just posted the details for the February 2008 Silicon Valley Mobile Monday. Lots of predictions are pegging 2008 as a major year for the web on mobile devices, but folks working in the environment already are debating what exactly this “mobile web” will be. Devices are gaining capabilities and developers are tired of having to support multiple distinct forms of their website. But designers and service providers continue to advocate respecting and taking advantage of the unique restrictions and capabilities of handheld mobile devices.
How this plays out is going to be determined in large part by the browsers that users have access to. Recent releases have really shifted the field with respect to device screen size and the expected level of support for “full web” standards. How long will it be before the average mobile user will be able to get convenient and automatic access to the full web version of the sites? How does the practice of “designing for mobile devices” change with these new browsers, and what should developers plan to support? How will the unique capabilities of mobile phones be exposed to web applications? And where does the line between web application and native application get drawn if you need access to device information?
I’ve been having conversations of the sort with friends and colleagues since last year, and the pace has been picking up over the last few weeks in particular. I was considering holding off the topic for a while, but the time seems to be right for a larger discussion.
CSS Handling Updates at Mowser
Jan 29th
Russ put up some CSS handling updates on Mowser meant to improve the presentation of sites when being adapted. It’s still pretty experimental, and we might have to add some different defaults in and expose additional controls to publishers. However it’s looking pretty good already. Here are a few sites that show off how it works:
We’re trying to pull what information we can from the desktop version to make the mobile version look similar where possible. Every site uses CSS differently though, and the rules so far are based on trial and error and human inspection. If there are particular rules or transformations we should be paying attention to join us in the forum and let us know.
Skyfire Launch – Proper Mobile Browser Behavior
Jan 28th
For the last few weeks I’ve been helping out the folks at Skyfire with some bits and pieces of projects they needed some backup on. They have a new browser for mobile devices, initial release is for Windows Mobile devices, but they plan to add additional platforms before too long. See their blog for the official story. As Rafe reports the browser is proxy based with most of the logic living on the server side. The result is that the browser is as standards compliant as the base it’s built on (which is Mozilla), so all the normal settling time about corner cases of CSS support and Javascript pretty much go away. Hopefully folks won’t have to deal with the “how will my page render on this additional platform” question as web property owners.
However there are some questions from the mobile side they would like to answer but haven’t sufficiently worked through yet. For instance what information do you send up to the server to make sure you get back “the right page” for a user. We’ve gone through these kinds of discussions before around belligerent or hostile proxy activity.
But say you have the ability to render a desktop page on a mobile device in a way that was never possible before, and to do it across platforms. Do you identify yourself as a desktop browser and display the full version? Or do you mix in some info about the device and possibly get the mobile version instead? Sometimes content or downloads meant for your device are based on reading out the user agent associated with your device. If we send that along the original phone user agent (using something like the unfortunately named X-OperaMini-Phone-UA header) then site owners have to pick up an additional header to act on. And at times it’s hard to pick up the original user agent unless you can sniff it out during an over the air download.
In the proxy world the accepted proper behavior is to pick up the handheld version header and redirect directly to that. One possibility is to provide some UI elements that indicate there’s a handheld version available and give the user the option to switch to that.
It would be great if there was a way to pull together some of this different stuff (pickup up additional headers from proxies and browsers and proxy based browsers) so that developers don’t have to add new logic every time a new browser or service comes out. Until the overall questions are settled it’s hard to standardize, but then again code speaks pretty loud. I wonder if just making a set of rules and an implementation would be the best way to handle the proliferation of techniques. The specs and standards don’t really seem to address the root issue here. For instance the content transformation landscape doc from the W3C is aimed at a much different level – once you have some content how do you handle it. Where this is more of an identification issue, how do you properly represent what you are so that you can get the “right” content?
How Many Engineers Does it Take to Write a Weblog?
Jan 24th
As suggested by Ewan we’ve now setup a Mowser Weblog specifically for our Mowser related ramblings. Which isn’t to say that I won’t also post stuff here, just that we’ll make sure any “Mowser info” will get posted over there. So that people who want to follow just Mowser stuff without all the random noise that Russ and I end up posting about have a way to do so.
Testing out Maemo WordPy 0.6
Jan 24th
I saw the post on Maemo Apps about the WordPy update. I just installed it and used it to upload an image to Flickr, now I’m posting from it. The image I uploaded is my Serial Experiments Lain inspired N810 background:
Swapped Keyboard Mapping Techniques on the N810
Jan 23rd
In the comments to my previous post about remapping keys on the keyboard of my N810 there was a mention of editing the X server keyboard mapping file at /usr/share/X11/xkb/symbols/nokia_vndr/rx-44, which I assumed was a pretty nasty hack. But Daniel Stone, who does the X server development for Maemo, said that it wasn’t a hack at all. xmodmap is the hack.
Yesterday I was starting to get annoyed at having to manually load the mapping at every reboot (cause I have to reboot frequently to get GPS working again, groan), so I swapped techniques. The format of the file is pretty easy to understand, use “bar” where you want to put the pipe symbol and “Tab” where you want to put tab. And while I was in there digging at it I changed my mappings to, I made Fn-space the tab key instead of using semicolon. Just seems like a more intuitive setup.
Mowser => Mowser Inc.
Jan 22nd
I just got the paperwork back from our lawyers making it official that Mowser is now Mowser Inc.! Russ and I have been hacking away on the site adding new features, fixing bugs, and getting publishers integrated. But we’ve also been batting around a few Big Ideas that extend out beyond content adaption and into the rest of the web. Russ and I have known each other forever (in Internet Time at least). I would have been happy to just run the site informally splitting up the revenue that it throws off. However for some of the other ideas a higher degree of formality was required, so we decided to make everything official.
It’s been a while since I’ve done this, and last time I was involved in the process but not driving it. Much different from this side of the fence. And yet another reason that I’m happy I’ve landed in Silicon Valley and been involved with the people I’ve had a chance to work with. There were literally dozens of people I was able to tap for advice and guidance. All of whom offered some of their time to share insights, explain stuff I didn’t understand, and correct me where I was wrong. Thanks for all the help and encouragement everyone! I’m really looking forward to sharing the progress over the next few months.
Total Mobile Access – Excellent Example of Difficulties
Jan 20th
I went to the Pizza Hut site to see if the new store just around the corner from my house opened up and was greeted with a little flash animation informing me of “Total Mobile Access!!” for pizzahut.com. “How cool is that!!” I say to myself (I often speak to myself when using the web). I simply must try this out. Turns out they have two options, order via SMS or order via mobile web. Now that’s what I’m talking about! Although I think SMS services are spectacular for some things, for ordering a pizza I want an interface.
I decided to write up the experience not to poke fun at PizzaHut, but to give a concrete example of some of the challenges that you have to face when making a mobile site. I think it’s kick ass that PizzaHut has decided to do something it would call Total Mobile Access. I’m just afraid that they might not get the results they would like to see out of the effort. And it’s our responsibility (those of us trying to work to expand the mobile ecosystem) to figure out how to make these things work better.
The website says I need to create an account on the web before I can order from the mobile site. Oops. That mobile site is going to be really useful when my Google map search that tells me there’s a PizzaHut right around the corner allows me to place an order right then. I’m sure that would be easy for them to fix. But how was the decision made not to allow signup or ordering from the mobile web site? There might have been some technical reasons not to do it, but I’m pretty sure any rational look at expected user behavior would point out that the technical cost is worth paying in this case. More about this later.
Once I setup an account on the desktop side I went and visited the www.pizzahut.com site from the browser on my N95. I waited while it loaded and loaded, it looked the same as the version I saw on the desktop. Turns out they’re doing device detection to redirect the user to the proper version. My device isn’t something they pick up as mobile. And the normal desktop version isn’t something that I can interact with through the Nokia browser either, so no help there.
No problem! I’ll just do it through Opera Mini instead, I’m sure they’ll pick that up as a mobile browser. Indeed they do! However OperaMini can’t parse it right away. It can display the page. I just get an error when I load pages telling me the page has problems, should it be “reparsed as HTML?” (an error which should probably never appear to a user by the way). And even after clicking on that I get a page with fields, but no buttons to do things like login. And the page looked messy, repeated graphics all over. Something was yanking at the back of my mind. It looks like something I can almost remember…..
WAP! It looks like what happens when you parse a WML page as HTML. So I spoofed the headers in my Firefox install to pull up the page, sure enough that’s what it is. The lowest common denominator definitely was WML, but I’m not sure I would use it for anything at this point. It’s kinda seeped out of my mind that it ever existed. Apparently the OperaMini folks, who are no slouches when it comes to mobile prowess in general, seem to think the same way. Just goes to show all the strange errors that creep up when some twist of fate ends you up with forked markup languages. Lets hope nothing like that ever happens again. W3C, I’m looking at you.
I was going to see if I could get the confirmation message for a delivery done via the mobile web delivered via SMS instead of email, but I can’t test that right now cause the store is currently closed and I can’t even go through part of the ordering process. Actually, looking at these pages I might only be able to place an order online for delivery. (Sidenote: my address does not exist in the mind of the database that PizzaHut owns, which is odd cause literally
two blocks away) Maybe I’m doing things a bit weird, but it’s not uncommon for me to include “getting dinner” in a laundry list of other things to do while I’m leaving the house. Get paper towels, drop off the mail, maybe drop in on Fry’s for a bit, and get dinner. The confirmation email about my order, kinda useless. However, letting me know if I can linger in Fry’s for a while longer or if my pizza is currently getting cold, that would actually provide unique mobile value not available before.
Then I started wondering how long PizzaHut have been running this service. Turns out it might have just started a few days ago. (Another sidenote: check out the “press coverage” for this, page after page after page of cut/paste press release with a few people who have cut graphics off the PC website. I wonder if I’m the first non PizzaHut employee to try this thing out). I would really love to see the services evolve. Apparently the decisions behind the mobile website are based on some studies of user behavior, but if you read a few of those news articles it becomes pretty obvious that the marketing department had a heavy hand in what happened to the application. Take this bit for example:
“We’ve designed our ordering system to be user-friendly with just a couple of steps, as opposed to the overly complicated, multiple-step system our competition devised,” Niccol said.
Great idea! Poor execution. If I were PizzaHut this is what I would do:
- XHTML as well as WML, going in that direction is dirt simple.
- You say you’re going for the tech savvy core of folks, but the app itself seems to be designed for the phones the average user would have in their pocket. Excellent to be thinking ahead like that. But in the meantime keep an eye on the devices that are hitting the site and make sure you understand what your users are doing. Closely related to ordering from a handset is ordering from a PSP or DS, anyone tried that? How about from a Wii?
- Allow signups from the mobile, or even better order without signup.
- Send confirmations via SMS when ordering mobile, and if you can provide some extra info like when the pizzas are ready that would be just peachy as well.
- Try doing other things from your mobile and making sure that they do what they should. For example, try a Google Mobile search for ‘pizzahut’ and clicking on the pizzahut.com link that shows up. Right now I’m going to the transcoded version of pizzahut.com instead of to the mobile version cause there’s no header indicating that a mobile version exists.
I think this is a pretty good example of some of the odd pitfalls that exist when doing mobile development for the web. Most people who have never tried it think it just means writing simpler HTML. Most people who have tried it run screaming and are later unable to articulate what exactly it was that made it so difficult. It makes for a pretty impenetrable fog around the whole area, even if there is more overall attention being paid to going mobile. And it doesn’t help that “coverage of mobile” in the media seems to consist almost entirely of cutting and pasting press releases, with the occasional dash of regurgitating the party line spit to you by some exec about their own product (complete with competition bashing).
Resize Offscreen Window in OS X
Jan 19th
I use OS X on my laptop and I’ve been moving around a lot and working from different places. I attach and detach a few different screens as I move around, so I always end up with the problem of windows with controls offscreen. For many apps there are tips and tricks to use menu options to get them back. I had an Eclipse window that was offscreen this morning though and I couldn’t get it back, so I was looking for a more generic solution. I found this tip about using a bit of Applescript and a Quicksilver trigger to do it which worked perfect for me (actual script is in the comments).
