Whenever I hear the term, “UX,” I immediately think of graphic designers, artists and folks who focus on making the UI of your application beautiful. Nine times out of ten, this is the appropriate connection to make. Great UX folks at Microsoft came together to make Windows Phone 7 the most visually-appealing smartphone on the market and that’s a good thing. Lucky for me, great UX folks come to my rescue all the time because while I can build functional and usable client applications that solve users problems, my stuff isn’t that pretty. Gotta love Expression Blend and the people who can use it to transform your app!
There’s lots of folks out there that think they don’t have an actual connection to the end user because they develop on-premise and cloud server APIs. You know who I’m talking about. Server developers who are building Web Services using WCF to expose functionality to be consumed by clients. Web developers that are creating dynamic ASP.NET web pages that make AJAX requests. Well, I’m one of those people too.
Just because you don’t build client UI’s that people can see and touch, doesn’t mean you don’t have an important impact on UX.
Once a user gets past the “skin-deep” beauty of the UI you typically think of, they’re often more concerned about accomplishing the task that the mobile app was designed for. If a user taps on a button and has to wait over a minute to retrieve and display the data they’re requesting, it’s fair to say that they just had a poor user experience.
In our new world where wirelessly-connected smartphones and tablets rule the day, a number of factors that you may not have thought of, come into play that impact user experience. After the user clicks the button, and before data is retrieved, quite a few steps are taken through a very long path:
- Your Request is transmitted from the device to the nearest cell tower while competing for bandwidth with hundreds or thousands of other nearby mobile devices all doing the same thing. Oh, and those 3G and psuedo-4G speeds you read about are only achieved in perfect conditions with a limited number of wireless devices connected at any given time.
- Your Request travels down the tower to the base station.
- Your Request travels from base station to the mobile operator’s backhaul network where it competes with millions of other requests for bandwidth across fiber and other types of circuits. Keep in mind that despite providing fast wireless speeds in perfect conditions, the amount of bandwidth in the various mobile operators backhaul networks varies widely.
- Your Request jumps on to the public Internet and starts hopping through routers.
- Your Request hits the outer firewall of the Domain you’re trying to reach.
- Your Request might hit a reverse proxy.
- Your Request might go through a back firewall as it leaves the DMZ to enter a corporate network.
- Your Request finally gets to the intended server, and depending on the amount of traffic it’s experiencing, it will wait in an invisible queue created by the server operating system until it gets processed.
- Your Response travels back through all those same hoops to get back to your wireless, mobile device.
Wow, I’m already tired just thinking about that!
So it should be clear that despite the great convenience provided by wireless data networks, there are a lot of hoops built into the system that work against you to diminish the user experience. Doctors take an oath to “do no harm,” and I think server developers should take that oath to heart. You have a lot of options to consider to make this wireless journey as fast as possible in order to put a smile on the user’s face. Besides fast servers, lots of processor cores, fast SANs, caching, queuing, scaling out, data sharding, using the best SQL query plan, using faster code algorithms and such, I want you to optimize the stuff that’s actually going over the wireless network. I want to make sure you “do no harm,” and that means not using fat, slow transports and wire protocols to move your data between devices and servers.
If you’ve been to my Tech Ed sessions or read past blog posts from me, you know that speed and efficiency mean a lot to me. In the past, I’ve demonstrated 4 different ways to return a list of 8 delivery drivers from SQL Azure. Depending on the choice the server developer made, the resulting user experience could be bad or good.
- Worst: Using OData with all it’s helpful metadata, the list of drivers used 8.54 kb of data.
- Not as bad: Using SOAP + DataSets, the list of drivers used 3 kb of data.
- Much better: Using REST + XML, the list shrank to 1.24 kb of data.
- Best: Using REST + JSON, the list dropped all the way down to 639 bytes.
Each one of the examples above returned the data my user was asking for, but they diverged in how much bandwidth they ate along the way. Guess what happens if you take advantage of the built-in gzip + deflate compression capabilities found in IIS 7? Through the use of the URL Rewrite Module, tweaks to your web.config file, and specifying an Accept-Encoding header like Nick Randolph figured out, you can shrink the 639 bytes to a fraction of that size. Now we’re talking great user experience here!
Now you’re on the right track with efficient, compressed, REST + JSON Web Services, so let’s move on to the mobile web.
Those giant, flashy websites you’ve been building since the 90’s aren’t going to cut it on mobile devices. It doesn’t matter that your iPhone or Windows Phone 7 browser can render the Wall Street Journal in all its glory. It’s not a good user experience. Have you ever heard the phrase, “just because you can do something, doesn’t mean you should do that thing?” Just because my mobile browser can flawlessly render the New York Times, doesn’t mean my user is interested in waiting till the next ice age of it to download and fully render. Oh, and then you have to pinch and zoom to actually find anything that your eyes can read. Do your users a favor and view my Tech Ed Europe session on the mobile web and download the mobile web best practices cards to build web sites for small screens and slow wireless networks with lots of latency.
Mobile web sites should be displayed in a single column, heavy on text, light on pictures and graphics, and weigh-in at under 20 kb in size. Yes, I just said under 20 kb. Just in case you’ve heard otherwise, the secret to a successful mobile web site is not HTML 5. Remember, the mobile web is all about reaching as many users as possible with your site or web application. I’ll have more to say about this in my forthcoming book on the subject.
So what’s the big takeaway here?
Cloud and on-premise server developers have a big role to play in UX even if you can’t always see what they’re doing!