A One-Size-Fits-All Approach to Cross-Platform Development

1Feb by moarcodeplz

Participate in the experiment!!!

If I asked you what the best way to distribute an application across mobile devices, tablets, and laptops/desktops was, what would you answer? There are quite a few ways to do it, such as Unity, but all of them come with their own compatibility issues. Unity, for instance, requires a proprietary Unity plugin to be installed if someone wants to play a Unity-made game in a browser. Flash may have decent penetration for traditional devices, but it’s role as a cross-platform distribution method is quickly dying out due to a number of factors (Apple’s crusade against them falling under this category). Then there’s the more traditional approach; develop it once for every platform, meaning you would have it developed once for iOS, develop it again for Android, develop it once more for Windows Phone, and develop it again for traditional devices. None of these choices are particularly appealing.

For those of you that keep your ears to the proverbial internet ground, another alternative may have initially jumped to mind; HTML5. Until recently, developers that were targeting multiple platforms with their applications didn’t have the best options to work with in terms of ‘one-size-fits-all’ approaches, and HTML5 changes that. While not every browser supports WebGL yet and WebSockets are a long way from being ubiquitously implemented, the canvas element has been universally implemented. With the canvas element developers are able to work with rich graphical environments across every device that carries a browser, and because HTML5 is an industry standard, browsers don’t have much of a choice as to whether or not they want to implement this functionality (unless they don’t care about staying competitive). Additionally, developing applications with HTML5 can circumvent the app markets of various devices, meaning the 30% that would be taken from developers’ revenues would instead remain in the developers’ pockets.

The canvas element is far from perfect, however, and the tools being built for it are still in their respective childhoods. With a ‘one-size-fits-all’ tool like HTML5 and the canvas element there are a number of questions that must be answered, and I’m writing this in an attempt to answer one of them. In the process of working on a game based in HTML5 and being developed for all browser-bearing platforms I came to the realization that I would have to serve different material based on the device I was serving it to. Customers would not be very happy if we sent them HTML which was designed for a mobile device when they were viewing it on their laptop, and vice versa.

And so this experiment was born, the end goal of which is to determine an acceptable aspect ratio for delivering HTML to mobile devices, to tablets, and to traditional devices (three aspect ratios total). With this information, developers would be able to develop a single application for distribution across all types of devices, with the only platform-specific efforts going towards paltform-specific HTML and CSS. If you would like to participate in the experiment, please click here. The experiment requires no registration and only takes thirty seconds of your time. The idea is simple; open the page, adjust the browser you are viewing the page in to the size and layout you prefer when leisurely perusing the interwebz, and click the submit button. That’s it! Those of you that are TRULY dedicated are more than welcome to participate once on every device you own (ie: cell phone, tablet, and laptop)!

At the time of writing this I have had 166 entries, and I am not looking to draw conclusions from the data until I have at least 1,000 entries. Should I reach my goal, I will develop an infographic that aggregates the data in to an easily understandable set of metrics so that all developers may benefit. Additionally, I will have a URL that prints all of the gathered data as a JSON object so that others may do what they please with it.

So, if you have a few minutes of free time and wouldn’t mind helping me out, your time and effort would be greatly appreciated!

Participate in the experiment!!!

This entry was posted in Experiments and tagged , , , , , , . Bookmark the permalink.
  • http://www.zachstronaut.com Zachary Johnson

    Hi Christopher,

    I’ve been collecting default browser dimension data via Google Analytics custom events for awhile now. I record width/height at page load and then new width/height if people resize their window. People are somewhat used to resizing their browser to fit content *particularly* in the horizontal direction. Also, my current window width may very well be a reflection of the last site I viewed more than anything else.

    Given your experiment page with the relatively small content area, I’m very unlikely to have a browser window that is too narrow to view that content, and I’m very unlikely to resize my window to be smaller. I’m more interested in consuming your content (especially if it is a game) than how much white space is around it in my browser window.

    There are also techniques to quickly resize the canvas element to attempt to fill the browser window while maintaining aspect ratio. Canvas elements can be hardware scaled, see: https://gist.github.com/1184900

    Finally… there is more to JavaScript/Web-based video games than Canvas and WebGL. Many games are made with the DOM instead. E.g. you can make sprites out of div tags and animate them around the screen. It depends on the game, but sometimes that can be a much better approach than Canvas. I wouldn’t say the 2D mode for Canvas is in its childhood anymore since all major browsers support it now, and it has hardware acceleration. Also, the DOM method of making games mostly involves decade old HTML/CSS/JS techniques formerly known as DHTML… but now enjoys impressive speed and code uniformity across browsers.

    HTML5 games can be packaged up as a native mobile application and put in the app store. However, an HTML5 game in a desktop browser exposes all of its client-side source code, which concerns some game studios. This may be a reason why Unity or Google’s Native Client SDK may have firm traction. I think Flash is a bit of an unknown sum because while they have abandoned their plans for Flash plugins in mobile browsers, they at the same time are bringing HTML5 to their Flash IDE.

  • Pingback: Aspect ratio for Web applications « Computing Education Blog

  • http://mobimorphic.com Tony Hursh

    I just ran it from my desktop Mac using Google Chrome, my iPad, my iPhone 4S, and a cheap Android phone I bought for testing code (really low-end — it only cost about a hundred bucks). Looking forward to your results!