HTC Wildfire Broken

As the mobile development landscape is so diverse there are a number of issues that still arise thanks to every mobile platform moving in their own direction with no solid standards being adhered to. Some mobiles have different browsers and different versions of browsers. Take the HTC Wildfire, which runs a custom webkit based browser. From a developers viewpoint this can cause a host of issues.

The problem we encountered was with a mobile specific website that uses the Meta Viewport tag, which isn’t implemented correctly across all devices:

Our Viewport Tag:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=0, minimum-scale=1.0, maximum-scale=1.0">

This works fine on the iPhone and most smartphones, but the HTC Wildfire rendered everything with increased zoom.

Fix the viewport on HTC Wildfire

This was a little more tricky as the device DPI is so low and there isn’t a great deal of documentation on-line about rendering websites in the HTC Wildfire. After a few hours of playing we came up with this:

@media screen and (-webkit-device-pixel-ratio: 0.75) {
/* CSS for low-density screens */
body { zoom:0.82; }
}

This fix appears to re-adjust the zoom to cater for the low density pixel ratio. It’s a good thing that media queries in CSS have been introduced or this would be impossible to fix.

The Finished Code:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=0, minimum-scale=1.0, maximum-scale=1.0">
<style type="text/css">
@media screen and (-webkit-device-pixel-ratio: 0.75) {
/* CSS for low-density screens */
body { zoom:0.82; }
}
</style>

HTC Wildfire Viewport Fixed

As you can see form the screen-shot to the left this worked a treat, you may want to tweak the zoom and font size in the CSS media queries to fit your design perfectly.

On the first screen shot you can see the text being cut off the right hand side of the browser, the images being cropped off the screen and the bottom navigation missing an item. Once the zoom is fixed it renders as expected.

If you’re a developer then hopefully we have just saved you some time and more importantly frustration!

I’m sure some people will already disagree, insisting that consistency is important irrespective of the scenario. We were recently involved with some development on a mobile optimised web-application that would need to allow end users to interact through smart phones. During the first round of testing we were happy with the outcome and sent the client a beta release.

The client then came back with an 8 or 9 page document of amends…these amends were regarding consistency of device rendering, which proved to be a bit of an issue, not only because there is very little beside browser sniffing to target the devices raised, but because changing the visual appearance to be consistent would be wrong.

Why?
The problem arised because the testing involved putting 5 devices next to each other and going through the site step by step and listing all of the inconsistencies. Our first question to the client was how often will an end user do this? Obviously the answer was never.

If the interactions and aesthetic look nice in isolation, it’s relativity irrelevant what it looks like in other browsers or devices. I appreciate this can be a hard debate to win but carry on reading and hopefully it will make more sense.

Users owning a device or using a specific browser are used to how it works, they know how a select box should look and how a check-box interacts. The problem comes when you start interfering with these native display mechanisms as users soon get confused and frustrated. The devices they have purchased and become familiar with allow them to easily browse the web and interact with sites. As soon as you move the goal posts of how to interact with a site, their experience quickly becomes less enjoyable.

Appleitis
On a few occasions we have come across sites where developers are trying to make everything look like an iPhone. My immediate response is if users wanted their web experience to be like that of an iPhone they probably would have purchased one. By forcing a display type on your users, you are almost insulting their concious choice of device / browser. Developers and designers should embrace the rendering of each device and respect their decision of device choice.

When to enforce consistency
Although browsers and devices will do their own thing, there are some consistencies that need to be enforced. The main one being the users interaction throughout the site end to end. As with any web based application, it’s key for a user journey to remain consistent. Therefore if we discover a browser bug on a certain page that affects the navigation placement we will fix it, its not acceptable to use the rendering differences as an excuse for the key calls to action and user journey to be compromised.

In summary
Try and look at the project you are working on in isolation, think about what your end user will be doing. If your end user is unlikely to view the site simultaneously on three different devices/browsers then it’s not a show stopper that they are not all 100% identical. Work towards a site that offers the end user a smooth and memorable experience hopefully resulting in them returning and telling people.

At the time my original post was written smart phones were starting to take a lead in the mobile market but as time goes on it wont be long before all mobile devices are smart phones with advanced browsers and rendering capabilities. This coupled with the evolution of CSS3 and HTML5 support means that devices are now more capable of displaying a standard website thus rending the mobile site almost useless.

As much as I hate to backtrack from a previous post, moving forwards I think designers and developers need to consider scalability within their sites, allowing for different resolutions right down to 320px by 480px. We are starting to see more cutting edge developers take this approach and I must admit it’s my preferred option when viewing sites on my iPhone.

A Compelling Argument:

• A recent research done by the IAB suggested that 61% consumers won’t revisit poor mobile sites
• The number of UK consumers who accessed a retail site using their mobile in the three months ending May 2011 increased by 163 per cent compared to the same period last year
• Around 27 per cent of adults and 47 per cent of teenagers in the UK now own a smartphone
• At least 37 per cent of adults and 60 per cent of teenagers claim to be ‘highly addicted’ to their smartphones, with 81 per cent of smartphone users leaving their phones on at all times.

Source: http://www.iabuk.net

It’s clear that the market place for mobile compatible sites is growing faster than predicted but the best way forwards to attract this new marketplace is something that needs more deliberation, simply creating a cut down site with limited functionality and a maximum screen width of 480px is not really going to allow you to stand out from the crowd.

A possible solution
The answer is “Responsive Design”, as mentioned earlier this technique uses CSS3, HTML5 and a bit of clever planning to design a site where the areas of key content can be easily rearranged to make the best use of the screen real estate regardless of the screen site, the design responds to the conditions and parameters it’s given.

Check out this example (resize your browser):
http://www.alistapart.com/d/responsive-web-design/ex/ex-site-larger.html

I won’t go into the technical detail about this specific technique as there are many sites offering this information. This blog post is intended to provoke thought in the way we approach tackling the smartphone user base and the methods we employ to offer a cutting edge and sophisticated browsing experience.

Hopefully more sites will take this approach moving forwards, I know the team here are already investigating this approach and will be putting our skills to good use over the next few months!

Some Nice Examples:
http://clearairchallenge.com/
http://naomiatkinson.com/
http://3200tigres.wwf.fr/
http://www.dynamit.us/

A wild west of tables, spacer GIFs and font tags

I used to have nightmares about HTML emails. You had to get into the IE5, y2k frame of mind, banish most semantic best practices and aims for elegant script. However, there are tools to make the task significantly easier.

The first stop has to be the Campaign Monitor Blog, a superb resource for the latest news in all things email. A particularly useful resource is their CSS support guide which outlines what you can and (crucially) cannot expect popular email clients to support. The view is dismal, there’s not even support for CSS background images in Outlook 2007 and 2010.

Building

Get yourself a good template from which to build your email. Check out the HTML Email Boilerplate for a nicely commented example. Don’t be afraid to nest tables. It’s often the only control you have over spacing and alignment.

Remember to build a separate text-based version of each email template, this can be a text file with URLs in the place of link text and some basic text spacing. Also remember to clearly mark content place-holders, for example, instead of putting in a dummy name, I prefer to use %%FIRST-NAME%% which is easier to spot in tests. Sending emails containing dummy content is hugely embarrassing!

Testing

You can’t rely on regular browser testing; even online email clients behave in different ways in each browser. The best start is to validate your HTML to iron out any incorrect table nesting, missing tags and absent alt attributes. This can avoid silly mistakes from turning into hour-long head-scratchers. The next tip isn’t free, but is completely worthwhile; unless you have the full suite of email clients available (Outlook 2003, 2007, 2010, Apple Mail, Android Gmail, etc) I’d stump up a month’s subscription to Litmus.

Sending

OK, you’ve built and tested a glorious email template that’s all ready to be sent. Unless you are really geared up for it, I’d recommend a third party service for sending your emails. Mailchimp offers a reasonably priced package along with spam filter testing and best practice guides. Also remember that response can vary depending on your subject line and the time you send your email. No-one notices an email added to their unread stack on Monday morning or when they’re leaving the office on a Friday afternoon.

It was of course out of the question to deliver all the markers at a given zoom level and map position to Google Maps and expect client-side clustering to be undertaken so we needed a way of clustering on the server-side to ensure excellent performance.

After giving the problem some thought the approach taken was to notionally divide up the surface of the Earth into tiles at each zoom level of Google Maps. For our purposes we treated these tiles as squares (though this paradigm becomes less applicable as you approach the poles). It is then possible to give each tile at a given zoom level a unique numeric identifier. At the greatest zoom level of 21 we needed to notionally number these tiles from one to 247,390,116,249,600!

A central table in the database allows us to store the tile in which each item sits at each zoom level along with an average latitude and longitude for the items in a particular tile; this latter approach helps to stop the clustered markers appearing too regimented.

It is then simply an exercise in calculating the tile in which an item sits at each zoom level when it is added to the system. When items are added, edited or deleted from the system we take care to note that the tile in which they sit (and/or sat) needs its average latitude and longitude re-calculating.

With this structure in place we’re able to provide pre-clustered marker positions to Google Maps when given the zoom level and map position. The beauty of this is that we only need to concern ourselves with the tiles that will be present on the map when we query the database. If a tile contains more than one item we can show a marker at the stored average latitude and longitude along with an item count; if it contains a single item we can show a marker for that item at its own latitude and longitude. With some clever client-side code in place making AJAX calls to the server and dropping appropriate interactive markers into Google Maps we have our solution.

We’ve found this approach works really effectively and – despite the number-crunching that goes on behind the scenes maintaining the clusters – it provides a slick user experience.

I’d like to focus on one technique that often sets apart the high-performance sites we know and love from the more amateur sites that seem to be forever loading content. In most cases, functionality can be split into two or more user groups. Anonymous users see a cut-down version of the website, maybe some static content with basic functionality such as searching and registration. Once logged-in, a user will be presented with more complex functionality and expanded interfaces.

The practice of combining background images (spriting) and packaging assets such as JavaScript and CSS into single files to minimise server requests has become commonplace. The down-side is when a user visits any page on your site – a search results page, login page, home page – they will download the assets to your entire site, including areas they will probably never visit. Off-the-shelf CMS packages are among the worst offenders.

To minimise this impact, you can split assets into groups based on access level and load them when necessary. Scripts used to build complex functionality can be split into chunks only included when a user logs in. This technique can be applied to CSS, JavaScript and all static files. An example of grouping graphical button sprites can be seen on ipatter.com:

Non-registered users visiting the homepage will download this sprite (20kb)

Non-registered users visiting a listing page will download this larger sprite (30kb)

Registered users will download this largest sprite (60kb + the previous two)

This approach takes no more effort if adopted early-on and will help to ensure that different users will have an equally optimised experience.

One of my favourite tricks is the scalable background image, I’m sure you have already started to see this on a few sites and in time I think more and more people with look at adopting this approach. The below example is based on pure CSS, there are ways to include JavaScript to support older browsers but personally I think the idea of progressive enhancement is that a website should render better for users with capable browsers therefore encouraging users with older browsers to upgrade.

See Example »

What is a scalable background image?

We are looking to have an image set as the background and fill up the browser window irrespective of the window size. Although this may seem quite simple it’s important that we maintain the images original aspect ratio even when the browser window is resized by the user. Another thing we want to avoid is the window being too small for the image to render adequately.

All of this is done with a few select lines of CSS3 using the “background-size: cover;” declaration and some conditional statements relating to the screen resolution.

*Please note this technique only works with newer browsers, although some older browsers were ahead of the time and may support this, you will need to carefully review which browsers you intend to support.

The CSS:


body {
background: #fff url(/assets/images/bg-scalable.jpg) 0 0 fixed no-repeat;
margin:0;
padding: 0;
background-size: cover;
-moz-background-size: cover;
-webkit-background-size: cover;
}
@media only all and (max-width: 640px) and (max-height: 480px) {
body {
background-size: 640px 480px;
-moz-background-size: 640px 480px;
-webkit-background-size: 640px 480px;
}
}
@media only screen and (orientation: portrait) and (device-width: 320px), (device-width: 768px) {
body {
-webkit-background-size: auto 100%;
}
}
@media only screen and (orientation: landscape) and (device-width: 320px), (device-width: 768px) {
body {
-webkit-background-size: 100% auto;
}
}


Whats Going on?

Ok lets step through this section by section, the first decoration sets the body background image of “bg-scalable.jpg”. This is what all of the older browsers see, this in my opinion is a good enough fall-back for less able browsers. Once the background is set we then use the new “background-size” statement with the value of “cover”.

According to the CSS3 Specification the background-size specifies the size of the background images. When using the cover attribute the browser should “Scale the image, while preserving its intrinsic aspect ratio (if any), to the smallest size such that both its width and height can completely cover the background positioning area.” see : http://www.w3.org/TR/css3-background/#the-background-size

In theory we could end there as this will deal with the scaling of the background, as mentioned before we want to put in some limitations to prevent the background being condensed to much. This is where the conditional statements come in e.g. @media only all and (max-width: 640px) and (max-height: 480px) {.

@media only all and (max-width: 640px) and (max-height: 480px)
Here we are stating that the window should not get any smaller than 640px by 480px. If the browser window matches this or is smaller then apply the styles within, in this case the styles within are over-writing the “background-size: cover” with a fixed size of 640 x 480. These sizes can be changed to whatever you want your minimum background size to be, it’s worth making sure your conditional statement sizes and CSS background image size match.

@media only screen and (orientation: portrait) and (device-width: 320px), (device-width: 768px) { and @media only screen and (orientation: landscape) and (device-width: 320px), (device-width: 768px) {
These conditional statements are used for iOS devices as the native support of background-size cover does not exist, In this case we use the orientation and have separate CSS statements to stretch the image ensuring it fills the screen.

And we’re done
That’s about it, in its purest form you could just include the background-size: cover; attribute in your body and let the able browsers deal with it, personally I prefer a more rounded approach.

Feel free to Send us examples of this in use for us to reference!
Download the Example Zip to get you started

I was recently asked by a fellow developer if there was a way to detect if a HTML object contains a certain element and alter the CSS styles depending on the element it contains.

The Scenario:
“You want to target all anchor elements containing a link to a pdf BUT if the link to the pdf contains an image you don’t want the same styling to apply:”

As CSS is cascading, it’s difficult to go back up the DOM tree; after some thought and playing around I discovered a workaround.

You would normally reference element like “A > IMG” to target an element but would rarely have to do “A > IMG <” so a little thinking outside the box was required.

Here’s the code:

HTML
<p><a href=”some.pdf”>text link</a></p>
<p><a href=”some.pdf”><img src=”img-link.png” width=”200″ height=”20″ /></a></p>

CSS
a[href$=".pdf"] {
background: red;
border:20px solid green;
}

a[href$=".pdf"]:first-child:not([src]) {
background: blue;
border:20px solid orange;
}

Explanation
OK so the first CSS statement tells the browser to apply the style to any link where the HREF attribute contains a .pdf. This means both links have this applied (including the one with the image)

As mentioned we want to target the links differently, so we now have a second style which applies only to links with NO image inside. Note that we are not targeting the link with an image but links with no image so the standard style is inherited for the image only. The CSS here is first detecting all links with a href attribute containing “.pdf” where the first child element in the anchor tag has NOT got an attribute of “src” (therefore not an image).

Summary
Admitted its a bit complex but seems to work OK. Obviously IE 8- will struggle with this but it was required on an Admin area where the standard browser used is Firefox4. We will conduct some browser tests and look to include some known browser support moving forwards.

Feel free to follow me @cssguy http://twitter.com/cssguy

Users are becoming used to the convenience of having their digital essentials on one device. Mobile phones have been capable of browsing the web for a few years now, but as more people browse on the go, a slick mobile site has become a must-have within digital marketing. A reported 61.6 million smart-phones were sold according to Q2 2010 figures and The Coda Research Consultancy predicts global smartphone sales of some 2.5 billion over the 2010-2015 period, suggesting that mobile internet use via smartphones will increase fifty-fold by the end of this period.

Previously as with all trends at the beginning it makes little difference if you follow the trend as some of them never seem to take off, such as Google Wave that didn’t really “change the web” as so many people predicted. But knowing which trends to implement can make a huge difference as a business.

Just like in the early 1990s when the internet was in its infancy the business who did not adopt the “website” trend soon started to struggle as their competitors began to dominate the digital market. Today, the internet is so widely adopted that if you don’t have an online presence for many businesses this means customers will not find you, especially if your target demographic is a younger audience.

Something similar could happen with mobile versions of sites. Let’s say you have a website and your digital marketing is superb meaning users can find you, if when they arrive at your site on a smart-phone and certain elements are not supported or it takes too long to load, users can soon get frustrated and leave, possibly finding a competitor who has taken the time to produce a mobile specific version of the site with these users in mind. Please bear in mind that Morgan Stanley Research estimates sales of smartphones will exceed those of PCs in 2012.

Although phones like the Galaxy S and iPhone 4 have sophisticated browsers capable of rendering a full website in miniature as you would see it on a standard computer this does not mean you should not consider streamlining your approach for mobile devices, often the page weight of a standard website is pushing the limits of the smart-phone and may lead to slower than expected loading times, there are also a number of features that are not supported on smart-phones. For example Flash is not currently supported on the iPhone 4 meaning unless you have a good alternative your users will not get a rich brand experience.

Another feature that is unknowingly not supported on most mobile browsers is the ability to hover over an item. An example of this being problematic is a website where the navigation requires the user to hover their cursor over the item to see sub-navigation options. For this reason if you know your users are using hand held devices why not streamline your content and information to make it even easier for them to navigate increasing traffic conversion rates.

In summary, Mobile browsing is moving forwards at an extraordinary rate and it won’t be long before users expect to see mobile versions of their favourite website. It’s a trend that has been successful and will only grow. If you decide not to create mobile alternatives you need to be prepared for user frustration and the possibility that they may go elsewhere.

Please note that, obviously, none of this should be taken as any sort of legal advice and I would recommend you refer to and abide by the Terms of Use of the specific brand in all cases. Any mistakes in the descriptions given here are my own. (Great, that’s my backside covered, let’s go!)

Facebook

As you might expect from a company with such a shady history of privacy abuse, Facebook have locked down the use of their logo pretty tightly. In fact to use the actual full word logo, you need Facebook’s express permission. What you can download is a square ‘f’ logo, the ‘Connect with Us’ rectangle and the ‘Like’ button, each with guidelines around their usage. Interestingly the usage terms suggest that changing the design or colour is a breach and therefore not allowed.

Terms of use and downloads

Twitter

Twitter, an arguably more laid back application with, until recently, an emphasis on open-source development, offers an array of logos and buttons (very nice buttons at that) as well as comprehensive guidelines on how to use it. They also encourage users to share screenshots of the Twitter site, with the caveat that you do not imply association with Twitter itself.

Guidelines for use

Downloads

LinkedIn

The most popular social media site for business users gives pretty good guidance on usage of its logo in both on and offline communications. However I was unable to find versions of their logo specifically for download direct from their site, although I’m sure any resourceful interneteer would quickly be able to find one.

Brand guidelines

YouTube

Being part of Google seems to have led to some confusion over the rights for using YouTube’s logo, after much searching I found a press-only downloads page which, to be fair, offers pretty good guidance (and strict limitations) on the logo’s usage. YouTube is different from other social media sites in that it’s content is generally embedded directly into other web pages rather than linked through an icon or text-link.

Press only downloads and Terms of use

Bonus site: Ecademy

Not the most common social media site, but it came up during my Googling so I thought I’d take a closer look. Ecademy is a networking site, similar to LinkedIn, but with more emphasis on sharing knowledge and learning. They’ve recently re-branded and added downloads for a decent range of logos and buttons to promote your profile are available for use, but it took me a little while to find them since the site search doesn’t return results until you sign up. However once you’ve got the URL, anyone can find them.

Logo downloads

Extra Bonus: ipatter

The recently launched ipatter.com, a site offering a new way for business and consumers to connect with each other, also encourages users to use the brand for promoting both their profile (for business users) and the site as a whole. There is also a range of buttons and link styles available for Broadcasters once you have registered.

Brand downloads

(DISCLOSURE: ipatter was designed and developed by Soak)

It’s easy, in the still-pretty-wild-west-of-the-web, to get away with abusing brand guidelines and simply pasting a Google-sourced image onto your webpage. And this is fine for bloggers and casual users. But web professionals should be setting a standard of respect and accountability (just imagine if someone ripped off your own site brand) and this means following the terms set out by the intellectual property owner.