Tips for Using SVG in Mobile Websites

A few months ago I designed and helped build a mobile website. A goal of mine was to create a fast loading, resolution independent interface. SVG has been around for over 10 years, but using it is still quirky. For example, Google decided to save 1MB by excluding SVG support from Gingerbread, and that has proven to be a painful decision for mobile developers.

While there are more complicated workarounds, I tried to make things as simple as possible. Here’s a couple tips I learned that I didn’t find elsewhere.

Scale down background images. Although you can set a SVG image multiple ways, if you set it as a background image, the default android browser will not properly upscale the images. So make them large in your SVG file, and shrink them down in the UI. Fortunately, increasing the size of the image(s) does not increase the file size.

Some have suggested changing the SVG files internal dimensions from px to a realtive value such as ems. However, in my tests this doesn’t help with the default browser in Android, even in Jelly Bean. Continue reading

Building Websites for Mobile is Very Important – A response to: “Time to Stop Building Mobile Websites”

(The following is a response to a guest blog post on titled “Time to Stop Building Mobile Websites“)

When I first read the headline of the Forbes guest post, I was puzzled. It’s akin to someone writing an article titled “The Titanic Never Sank.” It’s an inaccurate, sensationalist headline. The article also contained a fair amount of false information. The core message is good, but unfortunately the author made some extremely inaccurate claims when trying to prove his point. I’m going to address those points – both their fallacies and core facts.

Step 1 in building your mobile website is to determine your target audience

Focusing on mobile as a separate channel is a distraction that turns the platform into an either/or proposition that hurts results.

First off, it completely depends on the goal of the website. Many successful founders will even suggest some companies focus on mobile first and not even bother with a desktop presence. Secondly, some websites have functionality and flows that simply do not translate well to mobile. Third, it’s simply not feasible for larger websites to quickly rebuild from the ground up to offer a mobile presence via a responsive site. In the short term, providing a specific mobile version is suitable while the main site is overhauled. Claiming that not building a responsive site “hurts results” is an extreme overgeneralization that should simply be ignored.

The most important aspect of building a mobile website

“Mobile” as a separate marketing channel existed for about six months – somewhere back in 2009. It had an extremely short lifecycle because technology and user behavior caught up, waved a cheery hello and then raced right by.

I’ve been building mobile sites since 2001. I have no clue where the 2009 date comes from, but it has nothing to do with mobile sites not previously existing as a “separate marketing channel”.

The mobile and traditional Web separated initially because of slower processors, slower connection speeds and lousy displays. That distinction is disappearing – fast. […] The only difference? Screen size. My phone still has a relatively small screen.

You need to think about form factor in your marketing, not mobile versus desktop.

That was true, back in 2001. As far as modern smartphones go, that hasn’t really been the case for years. There were methods to deal with slower processors, connections and screen sizes… all since at least 2001. In many cases, the displays on smartphones are higher quality than those on desktop computers (eg IPS vs TN panels.) Mobile devices clearly have smaller physical screens than most desktops or laptops.

However, the biggest distinction isn’t even touched on – usability. How a mobile device is used is vastly different than a desktop computer. The idea of “Think form factor, not mobility” is very misleading at best. Again, one has to look at the target for the site – will they be using the site on their smartphone while sitting at their desk? Most likely not. They will be using it as a mobile device. Their connection may not always be great, the lighting conditions may not be as controlled and the environment in which the site is used may be much more chaotic. Because of this, how data is passed and stored needs extra care. How much contrast you give a design is also important, as is font, graphic and button size to name a few. It’s not just about the size of the screen, it’s about how and where the site is used. Continue reading

Browser Testing: Internet Explorer 8 vs Internet Explorer 9 in IE8 Browser Mode – Don’t rely on it

Why not use Internet Explorer 9’s Developer Tools for testing IE8 & IE7? Here’s why.

Twice last week this issue has come up so I’m providing some examples and reasoning as to why you should not even bother using Internet Explorer 9 for testing websites for how they would look in Internet Explorer 8 and Internet Explorer 7.

IE has traditionally not been developer friendly out of the box. In IE9, that changed and Microsoft provided Compatibility Modes within Developer Tools (F12).

Months back, working with a couple devs, I was told this is how they test with IE8. I thought “wow, great that Microsoft is trying to help developers.” I never looked into this feature before, as I had always just used VMs for testing, long before IE9. So when IE9 came out, I continued that patter. (Microsoft provides free virtual machine images for testing.) However, my distrust for them overpowered me and I decided to run some tests.

The first test I ran was Acid3 Viewing the screenshots below, you will see the immediate differences I saw: A different score and slightly different rendering (eg “FAIL” in the corner.) Continue reading

CSS Rounded Corners Not Displaying In Firefox? The answer.

A few versions back, Firefox (Mozilla as a whole) dropped support for its original method of supporting CSS3 rounded corners (border radius). Previously it needed the -moz prefix – -moz-border-radius

Starting in Firefox version 13, Firefox no longer honors the -moz prefix in respect to border-radius.

One solution is simply to remove the -moz prefix. You can do this via find and replace – find: -moz-border-radius and replace it with: border-radius

This will cause older Mozilla browsers to not display border-radius anymore. So you could also add just border-radius as an additional rule.

Support for the prefix was removed in Gecko 13.0 (Firefox 13.0 / Thunderbird 13.0 / SeaMonkey 2.10).

WordPress Tip: You cannot move a blog with the Thesis theme enabled

Having moved WordPress blogs before, the process is not as easy as it should be but it’s also not very difficult. That is, however, unless you’re using the Thesis theme from DYIthemes.

Hopefully this will save you from much grief. If you’re using that theme, you have to disable it first, the move it. And even still, if you re-enable the theme, you must edit some files before you do so.

I experienced this issue both moving WP from one directory on a site to the root directory, and moving the site from one domain to another. No amount of scouring through the database to find the old blog URL and changing it would do the trick. I dug, and I dug and I dug – eradicating all instances of the old blog URL. All to no avail.

When moving the blog, step #4 is to change the WordPress address under Administration > Settings > General and step #5 is the same for the Blog address. If you use the Thesis them and make this change, you will watch as the change immediately reverts.

You can make the change in the database itself and after you load a page on the site, check the DB again and it too has reverted to the old URI(s).

The answer? Check your theme files. The Thesis theme files update when the theme is enabled, hardcoding the site’s URL into the theme code. Do a search for the old URL, and you will find it in the theme code. Change it to the URL of the new/updated site, or disable the theme altogether.