Mobile Web Development Constraints

Mobile is still, relatively, new so I'm not totally surprised to see so many mistakes made by app and web developers. But before launching anything people need to start actually considering the constraints.

There is no hard rule, that is why it's difficult for many new devs to figure this out before the headaches. So here are some pro tips.

For web development you must never use more than one animation per page, and never animate the background. This goes for both mobile and desktop though the mobile one requires you follow this constraint because of memory.

The main reason to limit the animations is that they will distract from the content, products become harder to locate and text becomes harder to read, which ultimately ruins the experience. For mobiles this will eat data and stress the memory, looking at Googles console shows that most phones in use are less than a gig in RAM.

A simple and small animation used multiple times can look classy if done well, but never animate the background, ever. Background animations require a complete refresh of the view, meaning every element must be redrawn for every frame of animation.

Such a stress will lag on all computers, and many mobile devices will result in the browser crashing. It also looks horrible, no matter how well the dev thinks it should look, to the user it's often a deal breaker.

Pages should also never be more than a screen and a half on the average resolution, some leeway is allowed for clearly bulleted lists. Too much will eat memory or result in a tl;dr user experience.

If the page takes too long to load you will not get new customers as fast as you lose them, so test on a slow device/connection before you launch. Now we enter the most common mistake I am seeing, too much JavaScript.

There is no golden ratio, because the amount of work the scripts do is the real deciding factor and variances in browsers make it difficult to gauge. So consider all script constraints at the same time, or you'll have a highly incompatible website.

Use long names, for variables and marker names you should make sure that one wrong character won't result in the script closing the browser unexpectedly. Mobile networks get a lot wrong during transmission, comparatively.

Usually at least one byte per web page will be wrong, it's because transmission over the air will always be affected by interference. A well developed web page will not be affected by one incorrect byte at any location, the unsung benefit of HTML.

Do not use repeating animation scripts and limit the use of response animation scripts. Due to the variations in mobile technology, an animation can often destroy the user experience, for best results use a single swipe animation for one menu, then leave it at that.

Also use CSS feedback instead of scripts for mobile sites, those are optimized for the individual device. This leads to the colors, the most annoying thing on many websites is usually color schemes.

Keep all tailored colors balanced with the global defaults, as in either use the same hues or use the same brightness, and always use the same contrast direction. Do not, ever, not even for one element, invert the contrast.

The color constraint is because not all browsers recognize all color attributes, you can break this if you do browser specific code foe every browser in existence. If possible, test the mobile site on the big three; FireFox, Chrome, and Apple's latest.

If you really want to increase your customer base, develop targeting the default Android browser, if it looks good and doesn't crash that browser it will likely attract more customer than the big three. Do not target IE, unless you want to target only a small subset of Windows users, IE uses nonstandard labels.

Final note on websites in general, keep it simple. Do not use elaborate security measures on account logins, avoid cascading menu systems with more than one layer, always allow the choice between mobile and standard, and make the customer want to visit a lot.

One great example of a website done well is dx.com, the one animation is used for ads, the menu is well done, and the account system is perfect. I wish J had more great examples like that but I can't stop going to them for moat of my online needs.

Special note for Android that site developers must consider, the apps on Android have strict limits on memory usage, when they are reached the app closes. Browsers cannot know exactly how much a page needs until it loads the whole thing, so it is possible to reach this limit while rendering.

I'll do mobile apps in the next post, but it will have a lot of Android specific advice.