Web Design and Graphics

Choose a Great Domain Name

As you build the mobile version of your site, you’ll need to decide upon the domain by which users will access it, and work out how to advertise the fact that it exists. There are several options for choosing a mobile domain. Let’s explore each of them.

1. Use a separate domain altogether (e.g. www.example-mobile.com).

Creating a separate domain has never been necessary for any of the sites I’ve worked on. A separate domain name can hurt your site’s overall branding and can confuse users — how many people will actually remember both the URL for your traditional web site and your mobile version? And which site should you promote in your advertising? Such an approach can end up being a hassle, and is therefore not recommended.

Use a subdomain (e.g. m.example.com).

Creating a subdomain is probably the most popular option. Using a subdomain (such as mobile, or just m to keep it short) keeps your mobile site part of your brand without creating confusion. Obviously, if it suits your customers, you might want to localize the term ‘mobile’. And if adding ‘m’ to the start of your domain name spells something horrible, you might consider placing the mobile element at the end of your URL (e.g.http://example.com/mobile/).

Either way, you should assume that people will get the address of your mobile site wrong. Anticipate this eventuality by setting up several different common subdomains — m, mobile and others — and redirecting them all to a single mobile site, just as you should redirect typos like ww and wwww for your traditional web site to www.

Use a .mobi top level domain (e.g. example.mobi).

The question of registering a .mobi TLD has been the cause of heated debate among web developers ever since the availability of .mobi domains was announced. Personally, I’ve never used a .mobi domain for any of the projects I’ve worked on, but this decision may come down to a personal preference. If you have a few hours to kill, a quick search will provide you with plenty of information about the pros and cons of using a .mobi domain.

Do nothing, and let the server send the best page based on the user agent.

Performing user agent detection is perhaps the most interesting option from a developer’s point of view. It’s also the most elegant from a user’s point of view, but unfortunately it’s the approach that’s most prone to issues.

Here’s how it works: when a user visits the site example.com, the server looks at the visitor’s user agent and tries to detect if the visitor’s using a mobile device or a desktop browser. Given that information, the server will send the most appropriate page for that user agent. The beauty of this approach is that it allows you to use a single URL, which anyone can use with any device. Whether they’re on computers or mobile devices, all users will magically view the version of the site that is best optimized for them. When it’s done well, this can be great solution. But when it’s done poorly, it can be a disaster.

The second option that we discussed (using a subdomain) has one other advantage: a user browsing with a high-end device might first visit the mobile site, then realize that this site doesn’t contain the information he or she wants. The user then has the option of navigating the traditional web site to locate the information. The user experience might not be optimized, but the user should still be able to find the desired information.

With user agent detection, however, there’s only one URL, and therefore only one version of the site that can be returned to that device. The customer can’t choose the version to view — even if he or she is capable of viewing the site. If you plan on performing user agent detection, you’ll need to allow for exceptions so that devices can override the detection process in order to view a specific version of the site. As you can see, if you head down this road, things can get very messy, very quickly.

When you’re deciding on a domain name for a mobile site, the colleagues and companies I’ve worked with have always chosen option #2. Creating a subdomain is the easiest of the options to set up (you already own the domain), it’s the cheapest option (there’s no need to register the .mobi), and it means that you avoid having to spend hours tweaking the server (and potentially messing up normal traffic). The end result is a sandboxed subdomain built specifically for mobile devices. And if traffic numbers are not what you expect (for better or worse), a subdomain gives you the flexibility to grow or scale back the mobile site without impacting on the traditional web site

Validate Your Markup

Desktop browsers can be quite forgiving. A few misplaced HTML tags here and there will, more often than not, be fixed on the fly so that your page is rendered correctly. However, the “smarts” built into desktop browsers in order to perform this error handling equate to more code, which means a bigger install and more processing power.

Mobile browsers, on the other hand, are much less forgiving. A browser running on a mobile device generally won’t have the luxury of a 2 GHz processor and 100MB of disk space. Therefore, you must check, validate, and recheck your markup, time and time again.

Much of the checking and validation of a mobile web site can be done through a normal desktop browser. If you’re developing in XHTML, for example, you can reuse all of the same tools that you use to validate traditional sites:

• The W3C validator can be used to find simple markup errors — there’s even a mobile-specific version.
• The Ready.mobi site lists a few additional mobile specific checks.

You’ll notice at this point that we haven’t yet discussed checking to see if the mobile site works correctly on a mobile device. Once you’ve received the green light from several validators, you’ll need to get a few different types of phones to perform some actual tests.

Test, Test, TEST!

Testing your site with a web browser on a desktop computer can only get you so far in terms of simulating the mobile experience. There are many elements of mobile device usage that can’t be replicated accurately in this way. For example, a mobile operator might restrict packet sizes to something smaller than you expected, and therefore won’t even send your web page or its images! Additionally, content mime types could be an issue between browsers — are you serving the pages with the correct text/html or application/xml+xhtml? What kind of image formats can the phone display?

Due to the small footprint in memory and on disk, mobile browsers are not as robust as desktop browsers, so the best advice is test, test, test! Granted, not everyone can afford to test on every phone that’s available on the market, but there are alternatives:

1. Emulators

There are plenty of online emulators and offline emulators that allow you to quickly see images in context and the general layout, but they’re not real devices, and therefore they have their own quirks and differences. These tools can act as a good first pass to find common issues. Also, they’re free to use, so there’s no reason to not have a peek in an emulator, but you can’t call a site viewed on an emulator “tested”.

2. Rent Time

Renting time is another option. There are services that allow you to upload or view the content one multiple phones in real time. You control the different phone’s features remotely. This service does cost money, but it’s still cheaper than purchasing lots of different phones. For a basic mobile web site, this service probably isn’t needed.

3. Buy a Handful of Phones

Buying a small subset or representative phones is a possibility. If you’re planning on doing more mobile development, spending a little money up front can really help. You probably need to purchase 5 or 6 phones representing the major brands and types.

You’ll need some sort of Windows smart phone — we test on an HTC Mogul PPS-6800 using Internet Explorer on Windows CE, which gives a representative coverage for all Windows Mobile devices. You’ll also need a Nokia model phone. We test on a Nokia 6600 running Symbian Series 6 OS and the built-in Services and optional Opera browsers. You’ll need a Sony Ericsson phone. The model we use is a T630, which covers Sony’s Internet Services. Lastly, you should test in whatever model is most popular in your audience. You do not need these exact phones, but these types of devices will allow you to quickly see the minor differences in the phone browsers and cover the majority of potential customers.

4. Ask Your Friends

Finally, you can simply ask your friends. We all know at east 5 or 6 co-workers or colleagues who would happily lend us their phone for a couple of minutes. Once you’ve tested your web site with the online emulators and validators, test it on the borrowed mobile phones. The pre-tests should have fixed all but the issues that are specific to each phone. Take notes, make corrections, and test again, and again — and again! — until you’re satisfied.

Depending on your budget, one of those options will suit you. Spending just a little time and money really can go a long way — especially if this is your first mobile web site. Getting your test suite right will allow you to find common issues, while helping you to build a library of working HTML, CSS, and JavaScript code that’s known to be tested and can be reused in future projects.

Here are some essential web design tips that every web site should follow. Design your web site by following these tips and I guarantee that visitors will have a great first impression of your site.

1. Fast Loading web site designs - This is the number 1 tip that every web designer should follow. You might design a web site that looks fantastic but few people are going to see it if it takes a long time to load. Your designs should be optimized for the web and should not take more than 15 seconds to load. Remember, you might have a great design but very few people are going to see it if it takes a long time to load.
2. Clear Navigation - Once a visitor has come to your site you need to make them go through your site. To do this you need to have clear navigation. Make sure all your important links are at prominent places. Preferably right on top – that’s usually where a visitor first looks. Make use of menus on the right and the left. Try to link to as many pages of your site. Let your information be accessible from all parts of the site. You never know what a visitor may be interested in. Try to also use the footer for your important links.
3. All Resolutions - Today, there are computers with all kinds of resolution. They range from 640 x 480 to 1024 x 768 and go even higher. Your job is to design your site for all these resolutions. The best way to do this is to design your site in terms of percentage and not pixels.
4. Browser Compatibility - Make sure your site is browser compatible. Your web site should look good in Netscape as well as in Internet Explorer. Don’t stop designing your site as soon as you find that it looks great on IE. Usually Netscape gives some problems, especially when you try doing complicated HTML designs. But don’t give up too soon, usually with patience these problems can be easily fixed.
5. Readable and professional looking fonts - Don’t ask me how many times I’ve clicked out of a site just because the font is in Comic Sans and the color is a bright pink or green. Just by looking at the font you feel that the site is not a professional site. Don’t use Comic Sans and other fancy fonts that may not be available on most computers. If the font you use is not available in a visitors computer the web site will use the default font of your computer which is much worse. So try to keep to common and professional web fonts. The fonts that I always stick to are Arial and Verdana.
6. Minimize the use of images - I believe that sometimes simple designs are the most effective for the web. Keep your site simple but neat. Don’t clutter your page with big, bulky images that take ages to load. Instead use tables creatively and design eye – catching icons that will draw a visitor’s attention to a particular section of your site. Tip – Visitors are usually more interested in content than in design.
7. Use of white space - Try not to clutter up your page with too many images, backgrounds and colorful fonts. Again use the Keep It Simple principle by minimizing the use of graphics and using a lot of white space. White space gives a sense of spaciousness and overall neatness to a site. Notice the white space in our site.
8. Check for broken links - Always check for broken links within a site before uploading it to your web server. In Dreamweaver you can check for broken links by right clicking on any file in the Site Files Window and then clicking on Check links – Entire Site. If you don’t have this facility you need to upload your site and then check it using online tools like Net Mechanic.