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.

Tutorial on Designing for 800 x 600, 1024 x 768, 1280 x 1024 and higher

Designing web sites to fit all resolutions is a very important web design principle. Try out the Entheos site in all resolutions higher than 800 x 600 and you will find that it is designed to fit the page exactly. Therefore, visitors who have higher resolution can see more content in one page which reduces scrolling. Most web sites are designed for only one resolution. They may look perfect in a 800 x 600 resolution but if viewed in a 1024 x 768 resolution look a little empty. You’ll find a lot of wasted space around it making the web site look quite small.

From our research we have found that majority of our viewers are on the 1024×768 resolutions and higher. As time goes by more and more people are going to switch to higher resolutions as seen by our site statistics. It is therefore very important to design web sites for all resolutions. That is one of the principles we follow while designing web sites for our clients. With that bit of background information, lets get started on how to design a web site for all screen resolutions.

Step 1: Decide on the lowest Screen Resolution

Before you start you need to decide on your lowest screen resolution. Your web site will have to be designed keeping the lowest resolution in mind. Through our research we have found that less than 0.5% are on the 640 x 480 resolution So we ignore that completely. The next important resolution is the 800 x 600 resolution. Some of our visitors are on this resolution so we use this as our lowest screen resolution. This means that our web site has to fit all resolutions equal to or higher than 800 x 600.

Step 2: Design Your Web Site On This Resolution

Once you decide on your lowest screen resolution you need to design your web site for that resolution This means that all your graphics will be designed for this resolution. Design your web site and export the images as you would normally do.

Step 3: While converting your design to HTML make sure all your tables are measured in terms of percentages

Important: This is the trick to developing web sites for all resolutions. You need to work in terms of percentages and not pixels. If you work in pixels you are giving an absolute measurement to a table, whereas working in percentages gives a relative measurement. The table will be a given percentage of the screen resolution.

I hope you have understood this clearly. I’d like to explain this with an example. If you were to design a site for a 800 x 600 resolution, you would probably make a table with width 800 px and height 600 px. Now if you were to design a web site for all resolutions you need to make a table with width and height 100%, so that whatever the screen resolution may be the web page will scale to fit the page. It will be 100% of the screen resolution or whatever percentage you choose to give it.

The first step is to make a table with 100% height and 100% width. You could make it 95% if you want some white space around it.

Step 4: Insert images and content

Once you have designed your tables in terms of percentages you need to insert your images and content. The usual layouts will probably have a logo which can come on the top left corner and your navigation buttons in the top right or left navigation bar.

For more complex layouts you will need to use background fills to design your web sites. Remember since you are designing web sites to fit all resolutions you need to position your images accordingly (for your header). The easiest principle I follow (if possible) is to use the top left and right corners for fixed images and let the middle tile according to the size of the page.

Step 5: Test your site in all the resolutions

The last step is to test your site in all the resolutions that are available on your computer. To do this you need to:

1. Right click on your Desktop and click on Properties
2. Click on the tab Settings
3. Under Desktop area click shift the scale to 800 x 600, 1024×768 or higher if possible
4. Once you have chosen the resolution you want to check the site in, click on the Test button
5. If you can see the bitmap clearly you can click on Apply

Buy products with payday loan

The Number 1 rule that every web designer should follow is to create a fast loading web site. You might have a great design but very few people are going to see it if it takes a long time to load. While designing a web site always think about how long it will take to load. Try out our tips to build a great looking web site that also loads fast.

1. Minimize the use of images - The key to a fast loading web site is to minimize the use of images. Images do enhance a page but don’t make 80% of your web site only images. Instead break it down as much as possible to simple HTML. Notice the popular sites like Yahoo, Google, Ebay, Amazon etc., they have very few images because the load time is more important. Very often simple designs are the best.
2. Optimize images for the web - Once you have decided on the images that you need on your site, make sure that it is optimized for the web. They should be in the gif or jpeg format. You can also minimize the size of the image by choosing the number of colors you need, from the color palette. The less the colors you choose, the less the size of the image. You can also use online tools like Gif Wizard to optimize your images or to get a recommendation on how to cut down the size of an image.
3. Use Tables creatively - You can get some great looking designs by using tables creatively . Tables load very fast because it is just HTML code. Tables can be used in the homepage, menus or anywhere you like. Check out our homepage and our menus to see how we have used tables in our site.
4. Cut down the use of animated gifs - Don’t use animated gifs unless it is necessary. Animated gifs take a long time to load and can also be very irritating. But since they catch your attention you could use small animated gifs to draw a visitor’s attention to a particular section of your site.
5. Design simple icons - Instead of using big, bulky images use simple and small icons that add a little color and draw the attention of a visitor.

1. Use background images instead of big images whenever possible - Use background images whenever possible. This is usually a very useful tip for headers and footers. Instead of using an image of width 580 which is a uniform design you can use just a part of that as a background fill. This reduces the size of the web page as the image is small. The code will look like this : <tr background=”/images/header_backgroud.gif” width=”100%”>
2. Try out CSS Styles - Have fun with CSS styles to get some cool text effects. Again, a CSS Style is simple HTML code so it loads very fast. You can create cool rollovers using CSS Styles.
   Rollover the text on the right menu to see how we have used CSS Styles to get a simple but nice text effect.
3. Use Flash sparingly - There seems to be a lot of hype about Flash but I recommend that you minimize the use of Flash on a site. Don’t make entire sites using Flash. It may look great but it takes hours to load and can really put off visitors. If you do want to use Flash use it within an HTML site and make sure it loads fast.
4. Design most of your site in HTML - As much as possible try to design your site using HTML. You can create great designs by just using HTML code. Use tables, CSS Styles and simple fonts to design your site. Minimize the use of animated gifs, Flash, bulky images etc.
5. Keep checking your load time - Last but not least, before you decide on the final design of your web site, check its load time on NetMechanic. This site gives you a free analysis of your web site which is extremely useful. We kept using it to improve our site till we got a report that said good loading time!

We learnt these tips while building our web site. We’ve enjoyed sharing them with you and hope that you found them