Swimming the Matrix

The Mobile Web and UI/UX

While some companies are already taking the plunge and creating mobile applications for the various platforms, still others are hesitant to enter that space. Whether they see it as a fad or something that’s not worth the effort, one of the best ways to take a step towards mobility is to create a mobile site to complement your desktop experience.

When mobile first became popular, this was hard to do, needing lots of custom CSS and thus having a high development cost, today mobile sites are very easy to make with the help of libraries such as jQuery Mobile. jQuery Mobile contains everything you would need to create a mobile site, and can be created with plain html (and maybe some CSS tweaking for theming). This solves the technical hurdle, but the real issue is that you need to recreate the entire user experience for mobility. The desktop experience and the mobile experience do share some commonalities, but there are special considerations, especially with regards to mobile websites.

Real Estate is Limited

This is the hardest part about mobility: there isn’t enough space for everything on your desktop site! The first priority might be to look at all your information, and see if you can either move it to other pages, or remove it all together. Designing a mobile site is not a matter of just taking everything you have and making it so that it fits on the screen and doesn’t scroll horizontally. Users do not want to scroll through tons of content to find what they need. In an ideal world, there is no scrolling at all, unless it is textual information.

Even on a form factor like a tablet, you shouldn’t have to scroll all around the page to find the information you need. It should be right there, or on another page. Jump lists are a great way to take a handful of links, and compress it down into one on-screen button. This saves you screen real estate, as well as giving users a uniform place to look for links to other pages (so make sure it stays in once place throughout the site!)

Links Are Buttons

Textual links are a great thing when you have an exact pointer like a mouse. Mice are precise and accurate. Fingers, on the other hand, are not.

We still need links though, and that is where buttons come into play. Buttons solve two issues: size and visibility. It’s easy for links to get lost in a wall of text if you’ve changed the default link color to something other than the bright blue of the default link color. They are also hard to click, especially if they are close together, and force your users to either zoom in to the site, or try multiple times to click the link that they want.

Buttons are large enough to be clicked easily, and should provide enough spacing between links for accuracy. And we don’t need to have large buttons. Looking at pictures of mobile applications should give you an idea or the size you need. You can also tell if the buttons are too small by trying the site out on your mobile device, and seeing if it is hard to click the correct button.

Fixed Anything Won’t Work for Mobile

Long time designers are familiar with the 960 pattern. It is a design pattern that breaks the web site into twelve or sixteen columns, for a total of 960 pixels in width. This is great for fixed-width sites, because even at a resolution of 1024×768 (the smallest resolution a full-screen website on a small monitor will typically support), you can still see all the content without horizonal scrolling.

The problem with mobility is that there are no fixed dimensions for the screen. There is no minimum you can assume to support, because the reduced screen real estate means you need to use every pixel. As such, designs must be reactive, and use all the available space. Some groups have already adapted the 960 grid system to support mobility, such that elements will compress or expand as the device is rotated or different devices are used. For instance, your desktop site will show in standard 960 pixel format. On a mobile phone, elements will compress down to a few columns so that everything will still be visible without scrolling, and you can hide or show certain elements depending on the resolution. These systems should become the new norm for website design, as mobility is fast becoming the preferred way for users to access information and interact with web sites.

If you are looking to evaluate these multi-form templates, you might try Boostrap by Twitter, which just launched support for multi-device scaling sites.

Flash? Silverlight?

Let’s be clear: if Adobe isn’t even supporting Flash on mobile devices, it’s time to admit that Flash is a dying technology. While many sites still utilize Flash, on a mobile site you are likely to either get poor Flash performance, or nothing at all, meaning users visiting your site will see nothing at all. That’s a quick way to lose a sale or a customer.

And Silverlight? Not supporting on anything but Windows Phone 7. If you are taking advantage of Silverlight, you’re in the same boat as Flash when it comes to mobile web sites.

If you still want some of the animations and other features of Flash and Silverlight, take at a look at HTML5, the new standard for HTML for both mobility and newer browsers. It adds a lot of missing features into HTML, including animations using the Canvas element. Companies such as Zynga are already writing full blown games in HTML5, so it should be more than capable of handling your site with great support on mobility as well as most newer desktop browsers (except Internet Explorer, which is lagging behind the pack in HTML5 adoption). This transition will help future-proof not only your mobile site but your desktop site as well.

Bonus: Take Advantage of Gestures

One thing you can’t do on a desktop is gestures. Swiping, pinching, and other multitouch gestures are not found on desktop browsers. You can utilize gestures to make your site feel more like a native application. If you have a picture carousel, for instance, you might turn that into a touch-friendly version on your mobile site, and allow your users to swipe to change pictures. This increases interaction with your site as well as bringing a sense of familiarity that a non-gesture-supporting site won’t be able to match.

Published by meatshield, on February 25th, 2012 at 8:43 pm. Filled under: Uncategorized Tags: , , , , , No Comments

How I Choose a Language for a Project

I’m apparantly a freak. Well, say those who know me, duh! But in this sense I’m talking specifically about programming. Most people program in one, maybe two languages. I program in a half dozen fluently, and a full dozen if you count languages I would need a refresher on.

So this is fairly unusual from what I’ve seen, but it has some distinct advantages. For one, getting a paying job is pretty easy when you know most major programming languages. Second, and most important as it relates to this post, you have the flexibility to choose the right language for the job.

Programming languages all have pro’s and con’s, and specific cases where they may be better than another. Part of knowing how to program in a language should be the best times to use it. Because while C++ gives you great speed with your code, you’re going to have a really hard time programming a web site in that.

So here’s a quick breakdown of the pro’s and con’s of the languages I use regularly, in the order I most use them (outside of work, or it’d be C# at the top even when it’s not my language of choice)


PHP is my go-to language of choice. It’s quick, flexible, well-documented, and the syntax is easy to understand if you’ve done basic programming. PHP is a language that gets out of your way and lets you get down to coding without worry about imports and DLLs. Many a programmer has been converted to PHP when forced to use it because the code is easy to read and easy to run functions. None of this System.out.println stuff, you just say echo; It also has a massive community of developers, who more than likely have already solved the problem you are tackling, so googling becomes very useful.

On the negative side, PHP is no good at going long-running tasks (the default max time for a PHP call is 300 seconds, though you can extend this) and it’s really bad at desktop programming (since it doesn’t support desktop GUIs, though I have used it for some Cron tasks). It really only works well on the web, as a backend language sitting behind HTML, Javascript, and CSS, so to do a really nice site you will be expected to know 4 languages to get it done. not that the CHJ stack isn’t used in all web languages, it’s just that some languages abstract some of it away. PHP is fairly low level when it comes to the web.


Ruby has jumped a few spots in the last few months as I’ve revisted Rails, by far Ruby’s killer application. Rails is a MVC framework for Ruby that adds a lot of structure to Ruby, and makes it very powerful as a web language. Rails created “scaffolding” or being able to type in a console command to create your components as their most basic levels. It’s extremely powerful and useful for things like Models. Ruby also has the ability to be added on to with “gems” or pre-built community code that you can install with a command. They are extremely powerful. I built a full registration and login system in a half hour using a gem and a tutorial. And unlike PHP Ruby does not have an execution timeout set.

On the downside, Ruby’s syntax makes me want to cry. It’s painful, mainly because it takes a little of this and a little of that approach to syntax. It’s got some C style in it (Java, C#, PHP all follow C style) but when it comes to brackets, they are gone for words. There are around 4 ways to do anything in Ruby, so unless you comment your code someone will have no idea what you did (and I’ve worked with enough programmers to know we never comment as much as we should!). But overall it’s a solid language, albeit with a bit of a steep learning curve.


Despite being primarily Windows-only, C# is the only way to do a Windows application. And since Windows is still the OS with the largest market share, it makes sense to develop a nice GUI for it. C# is a nice language, there’s no way around it. It built upon what was nice about C++ without going the Java route and making everything so complex you’ll never be able to figure it all out. And it has so many features that are just inspired, primarily LINQ, which lets you search arrays just like you search a database (oh, and you can search those with the same syntax!). And everyone can agree Visual Studio is the best IDE around, with just about every bell and whistle a developer could ask for in it.

C#’s biggest problem is primarily the documetation. As in it’s buried in so many places and so imcomplete it’s very difficult to find what you are looking for unless you know where to look for it. Which brings us to point number two: It’s extremely complex. C# has so many “add-ons” that you need to know to really “know” the language that I doubt anyone really knows it all. There is WCF, WPF, .NET, Sharepoint, and let’s not even mention legacy things it has to support like older ways to do GUIs. So it has a bit of what I call “inherent complexity” in that to do something simple, it takes a lot of either typing or work.


Like it or leave it, Java is a huge force in the world. From desktop to Android, it runs just about everywhere (except your non-Android phones mostly). Unlike C#, this includes OSX and Linux as well as Windows. So it’s ideal if you need to do a cross-platform desktop application, and it’s alone in that regard.

But past that, Java is pretty horrible, and I don’t know anyone who will admit to actually liking it. It’s horribly slow (and the cause for why Android is so slow), very complex to use, has spotty documentation, and tends to give some of the most cryptic errors I have ever seen in a programming language. If you can avoid it, never use Java. The fact that they still teach introductory programming classes in it is probably the reason most kids transfer out of computer science. It scares them away!

So we’ve got the pros and cons out of the way, and I mentioned a little about what each language is good for, but how do you go about picking when some of them overlap? I’ve propared a flow chart to aid in your quest. The main idea is to limit language fragmentation where you code different parts of your software in different languages, hence some of the odd answers. Also I don’t take into account languages I don’t know or use often, so there may be something better out there. Also this is very simplified, choosing a language is actually a pretty big part of starting a new project since you’ll be stuck with it for as long as the product exists!

Published by meatshield, on January 9th, 2012 at 9:07 pm. Filled under: Uncategorized Tags: , , , , , , No Comments

An Introduction to Using HTML5 for Mobile Development

I’ll just out and say it: I’m extremely lazy efficient when it comes to programming. I want to do it the quickest, easiest way and be done with it. I’ve had a few opportunities come up to work on mobile applications. I love the idea of mobile applications, but hate the idea of coding 3 or 4 instances of what is basically the same application in C, Java, C#, etc. Luckily, HTML5 makes mobile development a lot easier than juggling languages and platforms and APIs.

HTML5, in the broadest sense, was created to fill in some of the gaps the HTML standard had. For instance, HTML4 does not support video. Or audio. Or animations. Or geolocation. Or local storage beyond cookies. So you see we have a bunch of limitations that HTML5 gets us around.

To use HTML5, you don’t have to get your users to upgrade anything. Unless they are still on Internet Explorer 8 or lower, they likely are already capable of using HTML5 sites. Then it’s just a matter of adding some new tags and some new parameters and you are off and away.

For mobile development, this gets really useful because all mobile browsers for smartphones are HTML5 compatible, at least in the most common areas such as video. So if we wanted to have an application to say find us the closest pizza place, you could use the Geolocation feature in HTML5 to get the user’s location in order to find the closest pizzeria.

Of course, there are some limitations to this approach. Despite getting access to some hardware, such as the GPS, we’re still unable to use other hardware features, such as the accelerometer or the camera. That’s where something like PhoneGap comes in.

In a nutshell, PhoneGap provides a Javascript interface via a device-specific native module that runs in the background, allowing you to write an app using HTML5, CSS3, and Javascript, and access the camera and other hardware features. This further negates the need for a full mobile app.

There are some caveats to this approach though. While it will vastly speed up your development time, don’t get caught thinking you’ll be able to write once and instantly deploy to all platforms PhoneGap supports. For one, not all features are supported by all phone operating systems, either due to lack of development effort, or maybe some security system in the device’s OS. Android and iOS, being the most popular, naturally support everything, so if those are your two platforms for development, carry on. The second rub is that there are some quirks that have to be accounted for with each device, such as needing certain options set a certain way to get it to function. Luckily PhoneGap allows you to know what device you are running on and plan accordingly, so you can just put in an if statement or two to compensate.

The last issue, and if you’re just using PhoneGap and HTML5 you might have difficulty getting around, is that everyone will know you’re not making a native app, but a mobile app. This is because the way PhoneGap renders your site is to create a “Web View” (it has a different name on every platform, but a web browser window) and display your content like it’s a website. Thus any links that you have will have a lovely border placed around them when clicked. I refer you to Bank of America’s original mobile apps, which were all a web site, and all very poorly done (hence why they now have native apps). However, through the power of the mobile ninjas, you too can fool your users into thinking your app is a native(-ish) app!

The secret lies in cheating. Rather than going to all the trouble of finding out which CSS styles need to be set to what to make that go away, you can just use something like jQuery Mobile. Yes, that Javascript framework even Microsoft has to love has a mobile version. On top of the usual jQuery you’re used to you also get an UI system that is pretty rich and gives a nice look and feel to your site with absolutely no effort. I threw an example for a talk I’m giving in a few days together in about a day and a half of work, most of which was figuring out why something wasn’t working how it was supposed to (hint: I messed it up!)

Overall, if you’re knowledgeable about front-end web development and don’t need to draw fancy graphics for games or use some unsupported hardware, a HTML5 application could be a nice way to get to market quickly, getting a consistent look and feel across all platforms, and make your updates easier and faster.

If you’re interested, I gave a talk on this subject the other night, and you can watch it in IE if you so choose(it was recorded using LiveMeeting, and Microsoft wants you using IE, not me!). The slides didn’t get translated to the video, but the parts where I shared my desktop did, so you can download my slides if you want to follow along.

Published by meatshield, on August 5th, 2011 at 8:19 pm. Filled under: Uncategorized Tags: , , , , No Comments