A good chunk of my day job is trying to get things working in the Nokia browsers. To be fair, it's better than Blackberry OS5's browser, but still a huge thorn in my side due to the sheer number of bugs/defects in how it renders web sites.

As such, I've been hoping the Windows 7 takeover of the Nokia devices would be a good thing. I think it is. Of course, I have yet to see Windows 7 in the wild. I know its out there. But I have yet to meat anyone that has actually bought a Windows 7 device.

But it looks like things might move forward...even if slightly. The first Nokia Windows 7 phone is coming out. The Seattle Times has a nice review of the Nokia 710.

My summary below.

The Good:

• Small, but a nice size
• Nice UI (compared to Android)
• It runs Windows 7

The Bad:

• limited on-device storage
• bad camera
• It runs Windows 7

Yep. Windows 7, one of its big pluses, yet one of its detriments. I can't say I entirely agree with that, as the alternative (whatever OS Nokia was working on in house) was likely going to be eye-gouging frustrating to use and look at. So, personally, I'm apt to keep the fact that it runs Windows 7 in the 'good' bucket.

Except for one thing.

One very frustrating thing if you are a mobile developer.

One confusing, head scratching, OMGWTF thing...

And I qoute: "Unfortunately, Windows Phone 7's Internet Explorer browser does a poor job of supporting HTML5 compared to the browsers in the iPhone and Android devices"

Aaaaaaaaaaarrrrrrrrrrrrrrrrrrgggggggggghhhhhhhhhhhhhhhhhhhhh.

Really, Microsoft? REALLY!?

A good 10 months ago I sat through an hour long presentation by a MS Windows 7 developer (and employee, I believe) at Best Buy Headquarters in MN at a mobile dev conference. He was excitably showing us how to build a 'hello world' Windows 7 app using whatever latest version of Visual Studio was out at the time. The few .net developers in the audience loved this. The rest of us...meh.

Granted, this was a conference where a good chunk of the attendees were there to see Phonegap and Titanium and jQuery and Sencha and...well, you get the point. We were a bunch of excited web folks liking the ideas of using our web skills on mobile. Which led us to the question at the end during Q&A: "so, how's the HTML 5 support?"

The answer was basically "We hope to have that working by end of year."

Well, so much for that. It's now a year later and I guess that didn't happen.

And so, as a developer, I can now look forward to spending less time fighting the Nokia browser and more time fighting the Windows 7 mobile browser. At least it will look nicer, I guess. Sigh.

A recent ZNET article doesn't seem to bode well for Windows in the mobile world either. The article talks about Windows 8 and questions its existence. Point 5 being it's "too little, too late for the smartphone/tablet market".

In the end, I'm bummed. While I can't say I've ever been a particular fan of MS, I really did want Windows 7 mobile to make a showing. MS clearly put effort into trying something different. And while I love the idea of Android, as I have to deal with individual devices, I'm realizing it's more of a great idea than it is a great product.

[Editor's note] Blogging has sadly fallen off my priority list and, for that, I apologize. Hopefully I (*cough* and the rest of this blog's team *cough*) will pick up the pace soon!

Over the past several years I've either been working in, or working directly with larger UX teams in a corporate setting. I've noticed that wireframes appear to be the primary product being produced these days. On a certain level, it makes some sense. It's a document (large organizations love documentation). It's something business stakeholders (at least claim) to understand. It's something that dev teams (usually in non-agile settings) often request. It's a paper trail (which fits in with the CYA school of business).

But wireframes don't work. They don't work because of all the things a wireframe is not. It's not a technical requirements document. It's not a user research document. It's not an interaction design document. It's not a content specification. It's not a testing document. It's not a visual design specification. It's not a component library.

In otherwords, it's NOT the product that the user experience is being crafted for.

What a wireframe is useful for is as an internal sketch for the UX team to help shape all of the aforementioned requirements that all the different parts of the corporate web/software development machine requires.

So to be clear--and perhaps a bit less provocative--I'm not against wireframes as a tool. Quite the contrary. They are an invaluable tool. What I am against is them being used as a document of record outside of the UX team. A wireframe simply can't communicate the full complexities of the solution to every individual team. Nor should it. But when it becomes the document of record, all of the sudden it's expected to live up to expectations it just can not meet. On top of that, the poor UX team now has to maintain this beast of a document, version it, distribute it, keep it in sync and basically become a slave to it.

Oh...the icons changed for the menu, can UX update the wireframe? That particular web service has a new API so the data retrieved is in an entirely different format. Please update the wireframes. Marketing came back to us and want to change the entire messaging on this section. We need new wireframes this afternoon! Dev just called and are confused. It looks like they have 7 versions of the wireframes. Which is the latest? The ID team pointed out that the flow we designed for the wizard is technically incorrect and can not be implemented as is. We need wireframe updates. Senior Management has some ideas to rearrange everything. They sent some sketches for you to update all the wireframes.

This is a reality of large software development projects. It's hell, but it's a reality. All that effort that should be put into crafting a better user experience is instead being pumped into pointless documentation that will never be up to date with the actual project.

I propose that all that effort, instead of going into Viso and Axure, go into actual working code. Yes, yes, that's Agile. I know. Of course, when Agile is implemented in the context of slow moving behemoth organizations, for some reason that key point is forgotten.

In summary, I encourage--nay, beg--corporate entrenched UX teams to get away from being wireframe maintainers and instead do what you do best: faciliate the process of finding the best UX possible and help craft the actual implementation of it. Do wireframes. LOTS Of them. But keep them on paper and the white boards. Don't commit them to electronic files as once you do, your role has shifted from being a UX designer into being the person in charge of the documentation that everyone else hates.

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.

I spent part of this weekend fighting some Xcode and Mobile Safari issues. In hopes of saving someone else one of these headaches, I thought I'd share them with you...complete with solutions!

Heads up, if you haven't upgraded to Xcode 4, it's not the prettiest upgrade path. You have to purchase Xcode 4 from the OSX App Store. The App Store is great for downloading small apps, but when your app exceeds the gigabyte size, as Xcode does, it's maybe not the best route to go. On top of that, Apple seemingly hasn't figured out how to use the app store upgrade incrementally. If you need to upgrade from 4.0.1 to 4.0.2 for instance, you need to download the entire multi-gig app again. Apple should be rather embarrassed about this. 

On the positive side, it looks like PhoneGap now mostly works in Xcode 4. You still need to do some manual tweaks to get the PhoneGap template to show up to create a new app, but otherwise, so far so good.

On to the headaches...

Can't deploy to actual device and do not get a detailed error

I was trying to run a build and deploy to my iPad but kept getting a build failed message, but no details to help diagnose the issue. I could build and deploy just fine to the simulator, but not to the device. After some digging on StackOverflow by way of Google, I found the answer.

Solution: It turns out you can not have underscores in your bundle identifier name. To fix: open your .plist file and replace any underscores in your bundle identifier with a dash.  

Xcode is not updating all files when building.

After spending several hours tweaking my CSS files, building, and running on the iPad, I switched gears and jumped into the JS files. After a few rounds of updating the JS and sending to the iPad, I began to get frustrated as nothing I was doing was changing the interaction. I then fell back on my usual crutch and started litering alerts throughout the JS. Build and run and...what's going on? None of my alerts are working!

It appears that while Xcode was more than happy to update the build process after every CSS tweak, it wasn't doing that to my JS file and was using some cached version of it.

Solution: As with the previous headache, the solution to the problem is within your .plist file. If Xcode starts caching one of your files when building, any update to the .plist file will jar Xcode back paying attention and will then grab the latest update of all files. You don't need to do this every time...just when it gets stuck on a file. An easy edit is to rename the icon file. 

Changing -webkit-opacity causes screen redraw issues elsewhere.

This was an odd one. After getting my IDE headaches out of the way, I was now running into a rendering problem in my app. I had a list of items that, when you click on one, would add a new class via jQuery.

Default CSS:

.example {-webkit-opacity: .25}

Class added via jQuery:

.selected {-webkit-opacity: 1}

This worked except that when the selected class got added, the parent div of this list would quickly redraw on the screen. You'd see the backround image shift quickly and then redraw. This happened on both the device and simulator and was clearly a code issue.

Solution: I'm not sure if there are other variables in play here, but I finally discovered that what was causing it was switching the opacity to 1. If I don't switch it to 1, but something close:

.selected  {-webkit-opacity: .99}

Then it works! No flicker! I'm chalking this up to a webkit bug for now. 

I hope these help someone wandering the inernet for a solution to these odd headaches!

I found out about several methods for debugging web code on an iOS device today courtesy of fellow mobile web people @melaniededon and @pine1000. I'm rather embarrassed that I wasn't aware of these until today.

Viewing Source on an iOS device

Mobile Safari has no built in view-source ability, but you can do it using a bookmarklet. There are several sites out there that step you through it. Mark Perkins has made a particularly impressive one that includes generated source called Snoopy. The process is 1) create a book mark 2) select the JavaScript shown on the page for the bookmark and COPY 3) Go to your bookmarks and click EDIT, then PASTE in the js. Since it's a bookmarklet, this can also be used on other webkit browsers.

Using Mobile Safari's JS Console

Yet another thing I'm embarrassed I wasn't aware of. Mobile Safari has a JS Console. Settings > Safari > Developer > DeBug Console. Once enabled you can do a swipe-down to expose the debug console at the top of your page in Safari.

iHTMLplus iPad app

iHTMLplus is a free iPad app that offers a view source view while still showing your page which can come in handy.

I'm still waiting for a mobile version of FireBug but until then, these tips should tide me over.

I'm sure you all enjoyed yesterday's WWDC Keynote by Mr. Jobs. Lots of new stuff. And yea, some of it's cool...I guess the cloud is nice, and Lion looks swell, and fixing alerts on iOS is long overdue, but what really got me excited seemed to have been omitted from the keynote itself: iOS NOW SUPPORTS A PROPER HTML5 DATE FIELD!

Ok, yea, maybe that's not the most exciting feature for most people, but if you are a mobile UXer, I'm sure you've banged your head on the desk more than once wondering why Apple, who has had what appears to be the most forward thinking mobile UX of anyone, had seemingly forgotten the new HTML5 input properties. Maybe they were too busy polishing up all the webkit CSS transformations.

Having spent a chunk of the past month dealing with trying to get datepickers working across devices, I've had to reluctantly give BlackBerry some credit as even they had figured out the HTML5 date input. We finally managed to get a JS version of Apple's native datepicker (mostly) working but am still quite relieved to see Apple finally truly made it native.

David Calhoun has a great write-up of all the new Mobile Safari features we'll be seeing in iOS5. Give it a read.

At this years IA Summit I was lucky enough to see a presentation by Belén Barros Pena and Bernard Tyers on a do-it-yourself usability testing rig for mobile devices. They were able to charm the whole audiance and really sell their concept by building a testing rig from scratch and preforming a user test all in the span of 45 minutes. The sence that useful mobile testing was priced out of reach for the average UX professional was totally destroyed. Anyone with a few key materials, some free software and a cheap webcam can now get meaningful data from virtually any handheld device. 

If testing mobile on the device and recording those sessions is important to you take a moment to watch the youtube video and go over the slideshare deck. They were able to price out their rig for under $200.00 and a weight of less than 5 oz. I believe that these numbers can go down if enough people iterate on this design. 

It's Friday. Time to kick back and watch some YouTube. It's OK. It's work related. Log it as continuing education.

Today's theme is web app vs. native app. Two recent videos passed through my in box that address various aspects of this.

The first is from the local Twin Cities firm The Nerdery. Jacob (UX) and Jon (Developer) share their thoughts on mobile apps. Mobile UX - A nerdery Interactive Primer

Mobile UX - A Nerdery Interactive Primer from The Nerdery on Vimeo.

The second is from the recent Google I/O conference. Reto Meier and Michael Mahemoff have a lighthearted debate about native Android development vs. HTML5 web app development. Google I/O 2011: HTML5 versus Android: Apps or Web for Mobile Development?

With all the grief BlackBerry OS gives me I really don't want to like their new PlayBook tablet, but I have to admit, it does look nice. Aside from the very odd omission of an email client, the device appears to be near the top of the pack in terms of UI and performance. One feature also stood out as something new: a touch sensitive bezel. Tested.com has a review up on their site that highlights this new feature (fast forward to 2:20 to see the touch bezel in action):  

It looks like Apple is also thinking of the same based on this patent TUAW looked into.

One of the projects I'm working on is migrating as many of our images on a mobile web site into sprite images to reduce the network requests (as well as make maintaining said images a lot easier on the back end). So far, so good. One 'gotcha', however is that a lot of mobile browsers have files size limitations as to what they decide to cache. Since client-side caching is ideal for our users that will be frequenting our site often, this is an issue.

Thanks to StackOverflow user bacchus--who's Google-fu is superior to mine--I managed to find some statistics on this courtesy of Yahoo and Tested.com:

• Mobile Browser Cache Limits: Android, iOS, and webOS
• Mobile Browser Cache Limits, Revisited
• How Mobile Browser Cache Affects Browsing on iOS, Android, and More

In summary: Umm...I'm still confused.

The second Yahoo article is the key one to read. That, along with the first one seems to indicate:

• iOS 3.x will only cache HTML pages under 25k (not a huge deal for us as our site pretty much requires a new server round trip to retrieve updated data)
• Android, WebOS and iOS seem to support caching individual elements into the gigabyte sizes--though the articles don't seem to address images specifically.

The O'Reilly book Programming The Mobile Web mentions a 25k limit on images in passing, but doesn't seem to have specific hard data to support that suggestion.I'm also still searching for BlackBerry and Nokia data (and Win7, for that matter)

So, I'm not sure, yet. If anyone has data to add, please share!

Let me start off by saying that I'm a huge fan of what the people behind the jQueryMobile Framework are doing and hoping to accomplish. Bringing both a visual and programmatic consistency to web based mobile apps is something that is desperately needed. I'm afraid, however, that at least in this one case, they may be designing an user experience consistency wrong. Let me explain.

A couple days ago I was prototyping out an iPhone app using jQueryMobile. This particular app has a slightly larger configuration section than other apps I've built and while playing around with it, I was using the jQueryMobile provided "Back" button to navigate around. I feel that in most cases in the mobile experience users expect the Back button to function more like a breadcrumb trail than a literal history of the pages I've visited, but unfortunately that exactly what jQueryMobile does. For example, if I were to have a config screen that can take me too two separate options, Sound and Music, each with their own configurations screen, going to one first, using the back button and then going to the other, would now entail me using the back button 4 times to get to the original home screen.

That in my opinion is horrible user experience. In the end I simply ended up adding a Home button to the bottom navigation to fix the problem for the prototype, but I'm thinking that some type of page layout array may be needed for a more permanent solution. If anyone has seen something like this, let me know. If not I'll probably be building it. Check back.