Sunday, June 29, 2014

Web Development : Publishing (FTP & Testing) - Part 1

Preparing to publish

Most web servers are set up to recognize index.html (or something similar) as the default ‘home page’ for each folder on the site. (Note: you must verify this information with your host company before getting started. If a different default page name is used, adjust your file naming accordingly.)

There are a few other considerations to check before publishing them:
• Page titles – Do they all accurately reflect the actual page content?
• Links – Do all the links work?
• Media – Do all the images and multimedia elements display as intended?
• Alternate text – Do all media elements include appropriate alternate text explanations?
• Layout – Does the layout remain constant across multiple platforms?
• Text – Is the text content readable and accessible across multiple platforms?

Finally, we need to add a few meta tags. The meta element is used to help search engines and browsers index and identify our page content, using special instructions not visible to most users.

As mentioned previously, meta tags are added to your page’s header, like this:
<head>
          <title>Online Math Tutoring by Erinn</title>
          <meta charset=”UTF-8”>
          <meta name=’description’ content=’Online’>
</head>
To reiterate, the charset meta tag tells the browser which character set is used in the content of thepage. This little line of code is essential, according to the W3C specifications – more on this later.

The description meta tag is required to relay a brief description of the page’s contents. Most search engines then use this description to help users decide whether to click the page link when displayed in search results. Over the years, many developers have attempted to fool Google with misleading page descriptions intended to raise their page’s listing in the search results.

Be warned: Google has advanced methods of determining whether a page description is accurate and will not use any it deems inaccurate. It is therefore best and safest to simply write a short (two or three sentences is a good start) and accurate description of your page’s contents.

Validating

Earlier in this post we mentioned a certain line of code was required by the W3C.

What does that mean exactly?

Well, the browsers are built according to the specifications set up by the W3C, and if your page isn’t written in compliance there’s a good chance it could have hiccups when displayed in some browsers. To prevent this, it is advisable and prudent to run all pages through a special tool called a validator.

There are three basic ways to validate a web page:
• Validate by URI
When you validate by URI, you simply type the web address into the tool and it does the rest.
• Validate by upload
If your page isn’t yet live, you can upload your HTML file to the tool to have it validated.
• Validate by direct input
If you’re working on a page and want to test a certain section of code, you can copy and paste it directly into a validator

To validate your pages, visit http://validator.w3.org.

The validator will check the file and display any errors for us to fix. Remember, the first line of our HTML tells the browser which specification we’re using. That means it’s critical to include the doctype identifier before adding any other HTML code. Without that identifier the validator won’t know which standard to check the code against. The standard referenced here is HTML5:
<!doctype html>
Here’s a list of common validation errors. Keep these in mind during code development:
• Deprecated (old) code – If tags and attributes that are outdated (i.e. part of an older specification which has since been phased out) have been used, the validator will alert us.
• Incorrectly nested tags – When using several tags in a row, make sure the order in which the tags are closed matches inversely.

While this is correct:
<p><strong>This text is important.</strong></p>

this is not:
<p><strong>This text is important</p></strong>.

The first to be opened must be the last to be closed.
• Junk characters – If text content from word processing apps such as Microsoft Word has been copy-and-pasted, it is possible Word formatting instructions have been imported too. That ‘junk’ is unnecessary for web development and can, in fact, cause the page to display incorrectly in the browser, and fail validation. To prevent this from happening, always paste from plain text documents (instead of Word documents).
• Alternate text for images – Don’t forget to include the alt attribute with all your image elements! Not only will missing alternate text cause the page to fail validation, it would also make the page difficult for non-visual users to access.

We can also validate (and troubleshoot!) our pages from many web development tools, such as the Web Developer toolbar add-on for Firefox.

To install into Firefox, choose Tools > Add-ons, then search for ‘Web Developer’ and follow the prompts. After it’s installed, choose View > Toolbars > Web Developer Toolbar. Then choose Tools from the toolbar menu and select the type of validation required (as shown in below).


Testing

Another part of finalizing our pages is to test them on multiple platforms, and in previous post we discussed the effect various platforms can have on them. If a site has been developed on one platform, such as a Mac
desktop computer, and the pages not checked on a Windows machine, a smart phone, or a tablet, we might be in for a surprising setback.

But we don’t have to own these different devices to test our pages on them. There are several online tools available to show us how our pages display in varying platforms.

My favorite free tools are :
Adobe Browser Lab (browserlab.adobe.com)
Browsershots (http://www.browsershots.com).

Adobe Browser Lab is accessible both from inside Dreamweaver as well as from within the browser. Their ‘onion skin’ option, which lets me view how a web page looks in two browsers simultaneously. In this Figure IE 6 on Windows is shown beneath the same page display in Safari 5.1 for the Mac. This type of testing can help identify positioning issues such as those preventing a page from displaying uniformly.

Adobe Browser Lab and Browsershots do a great job of enabling us see our pages on the most popular
desktop-based browsers, but what about mobile and tablet browsers?

Adobe has a new tool called Shadow ( http://www.adobe.com/shadow ) that makes it easy to test on our own phones and tablets, but what we really want is an emulator to enable us to a preview without actually owning the various different devices.

Opera Mobile Emulator ( http://www.opera.com/developer/tools/mobile/ ) is a useful tool for testing on tablets such as Amazon Fire and mobile phones like Samsung Galaxy and Motorola Xoom, but doesn’t
cover any of Apple’s devices.

Mobilizer ( http://www.springbox.com/mobilizer/) is a downloadable tool that lets you preview your site in several different mobile browsers. Note that for testing purposes, this tool doesn’t use the auto-zoom feature
available in mobile browsers like Safari. Instead, it shows you which portion of our website is visible by default in the small viewable area. If a mobile style sheet has been created, that version of our site will be
displayed instead.

A quick and easy way to test our site in Safari for the iPad is to use iPadPeek ( http://www.ipadpeek.com ). Simply enter the web address into the space provided, and the display will be updated accordingly.

Read Next Web Development : Publishing (FTP & Testing) - Part 2
Post a Comment