"A Writer's Guide to Web Building" focuses on authors' needs when setting up their professional web sites. The first portion of this blog is a series of "how to get started" articles. Once those are finished, different gadgets and what-not will be featured.

That's all well and good, but that doesn't show a single bit of anything in your web browser. We're going to start by building a plain (ugly) page and then I'll show you how to come back and fancy it up.

The Document Structure

The document structure in a web page is based on the typographical structure of printed documents. That's not really surprising since the impetus for HTML was to electronically reproduce printed documents for academic consumption. HTML was created for sharing annotated reports, not for hyping the next best buy. Frankly, I expect that most writers have at least a rudimentary understanding of the difference between a heading, body text, block quotes, data tables, and citations. If you're not exactly sure what I'm talking about, try reading some introductions to Semantic Typography for web designers.

So, all that to say, don't worry about the uglies of the document: tell us what the structure is. We can make it pretty with Cascading Style Sheets, but we have to know what we're doing. And on that note, here are your basic content tags.

Tag

Denotes

<h1>...<h6>

These are your heading tags. H1 is your top level heading--like the title of your document. H2 works for sections, H3 for sub-sections, etc. It's really, really rare to get down to H5, let alone H6, but, they're there just in case.

<p>

Paragraphs! Need I say more?

<q>

Inline quotes, like <q>No man is an island...</q> (which looks like: No man is an island...)

<blockquote>

Structurally, text contained by a <blockquote> tag pair will be indented left and right, as most style manuals indicate to do for long quotations.

<

<em>

Emphasized text, usually shown italicized or oblique

<b>

Bolded text

<span>

The span tag almost needs a tutorial all on its own. Pretty much, it's a way to introduce new structure elements that are not covered in the HTML vocabulary. When you use it, you need to add an attribute. We'll start with the class attribute, because we'll use that a lot with CSS. The tag pair will look like: <span class=""></span> We define (name and describe) classes inside our style sheets (later article).

<a>

A stands for anchor, and it has one unique attribute that we care about: href. href is short for Hyperlink Reference. In use, it looks like: <a href="http://some.webpage.com/">Linked Text</a>

Now, armed with these tags, let's go show off our opus. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>My Page</title> </head> <body> <h1>My Ugly Page</h1> <p><b>Thank you!</b> ... for visiting my ugly page. Well, it's not <em>really</em> ugly; it just hasn't put on its <q>war paint</q> yet, but we'll get to that in a bit. Read on for an excerpt from my upcoming novel, <span class="bookTitle">What I Wrote, No, Seriously</span>.</p> <blockquote> It wasn't dark and stormy, or some other tired cliche. It was Caterday, and I read the <a href="http://www.lolcat.com/">lolcat's blog</a> with glee. The fur ball otherwise known as Cat decided my keyboard would make a great place to lay down his weary carcass. After all, those fingers poking keys belonged to his human, and they had better things to do than entertain their owner. Or maybe I was reading too much into the cat's actions. Maybe all he really wanted was another set of flying lessons. </blockquote> <p><a href="#">Buy it now!</a></p> </body> <html>

That should now look like:

Want to know more of the nifty tags you can use? Go browse through SitePoint's beta HTML Reference or the W3 Schools tag lists.

Go to the directory in your computer where you saved "index.html" and double click on it--it should now open up in your browser and look something like:

Now that you've done the hard part and gotten started, let's go over what you did.

HTML stands for Hyper Text Markup Language. "Hyper" means it bounces, via links, from one page to another. "Text" is thrown in because this is all written in text, instead of like, ick, machine code (binary is *soooo* not my friend). "Markup" comes into play because you're using <tags> to "mark up" the stuff you're writing. "Language" just means that there is a method to the madness, a structure and a syntax. On the plus side, the vocabulary here is really limited, so there's not much you have to learn to get started "talking" in HTML.

So, on to the syntax!

Basic rules of HTML

Use the vocabularyW3 Schools is a great reference put together by the guys writing the web development standards. However, I prefer the SitePoint HTML (beta) reference because the writing is clearer and there are comments for each article, which allow for peer review (and extra "how to use it" tips).

Every "markup" has an opening tag and a closing tag, framed by less than & greater than brackets. <tag>stuff the tag wraps around</tag>, or in actual practice: <p>Everything between the "p" tag at the front and the "/p" tag at the back is part of one paragraph. If you wanted to separate this into two paragraphs, you would need to close the first "p" tag (with a "/p") and open up a new one.</p>

That "should be" hits a key point in html. So long as you're using the right tags, most browsers--where your web pages are interpreted--will understand the wrong example and show it the way the author intended -- well, for text formatting markup. When you start nesting tags that tell the browser about the framework of your page, getting it wrong screws up the page's format.

There are also these things called validators that are rather like automated proofreaders for your HTML coding. They're great for helping you figure out where the problems are in your pages--and, hey, everyone typos at some point, right?

One last point to make before we go back to explanations: Cascading Style Sheets (CSS) are for beautifying the page; HTML is for telling it like it is. Headings are headings, paragraphs are paragraphs, bulletted lists and block quotes and inline quotes and ... well, you get the picture. There are still some presentational tags in HTML, but these are being weeded out. Using these tags--font, strike-through, underline, et all--means setting yourself up to re-write your entire site when the support for these tags finally gets dropped. I'm going to keep it simple and show you the stuff off the latest implemented HTML standard--version 4.01.

So, back to what you did.

Every page should start with a DOCTYPE declaration. A DOCTYPE tells the browser, "Here are the rules this page plays by." Without the DOCTYPE, most modern browsers are going to assume your page was written in a free-for-all style, which means it'll treat the page like it came out of the 1990s. It's called "Quirks Mode" because each browser developed then had its own quirky way of interpreting HTML. It was icky--not as bad as machine code, but still icky.

The first part, "!DOCTYPE HTML PUBLIC" tells the browser that this is the DOCTYPE definition (Document Type Definition, a.k.a. DTD), it's for an HTML page, and the definition is a public definition--not something proprietary (that would be SYSTEM and the next part would be omitted). The second part, " "-//W3C//DTD HTML 4.01//EN" ", tells it that the W3C (World Wide Web Consortium) drafted the definition, that it's a definition for the 4.01 version of HTML, and developed in English. The last part ("http://www.w3.org/TR/html4/strict.dtd") is the URL pointing to where the machine-readable DTD specifications are hosted.

By the by, the DOCTYPE tag is the only tag that you don't close in proper HTML.

Next up are the <html> tags. The opening "html" tag goes just under the DOCTYPE declaration and the closing "/html" goes at the very end of the web page. No exceptions (especially if you're still learning =D). These tags tell the browser that everything in the page is web page stuff.

The "head" tags come next. Inside the head, you should always have at least a title for the page, contained in opening and closing "title" tags. You also want to drop your "meta" tags in here. Meta data is data about data. More will be made of these tags in a later article. Not least, links to accessory files, like your style sheet and any web scripts, get planted in the head. The "/head" tag closes before the "body" tag opens -- rather like the chin coming before the torso.

All of your content, all the beautiful, wonderful, BUY-MY-BOOKS-NOW stuff goes inside your "body" tags. If you want the content to show up in the web browser, you put in between the body tags, which means your page structure is also going to go in here.

Thursday, July 31, 2008

If you've been following this series, you should already have an idea of what you want your web site to come out looking like. Now, we're going to cover how to get from a blank page to that concept dancing in your brain. First thing's first, though: what tools do you need to have ready?

Basic Tools:

HTML Editor

Graphics Editor

HTML Editor

An HTML Editor is something like a word processor for HTML code. The most basic is Notepad, which comes with just about every Windows operating system installation. Because it is so ubiquitous, it's what I'll base examples on. You can use this Real-Time HTML Editor to copy & paste code samples for an instant view.

If you want to work with something a bit spiffier, check out the below guides:

Graphics Editor

The main reason for picking up a graphics editor--as far as this article is concerned--boils down to re-sizing and re-sampling images.

I use PaintShopPro as my main graphic editing utility because I'm a digital painting hobby-ist, and it's powerful, yet still easy to figure out--unlike Adobe's Photoshop. Then again, I think most of Adobe's editing software requires advanced degrees in geek-out to get to even a middling of their usefulness. If your budget isn't that stretchy, there's the free stuff, starting with the Paint program that comes with Windows to Brush Strokes, which I'm told is pretty nifty for the price (free). And there's always the GIMP. It's one of the big Open Source Initiatives.

Wednesday, July 30, 2008

Decades and decades (okay, just *a* decade) ago, hosting a website was expensive. As with all maturing technologies, the cost has come down and you have more choices. If you like the whole techno-geeking stuff, you can pay your local Internet Service Provider for a static IP address, set up a web server on a computer attached to that IP, and host your own. All things considered, this is *not* the service of choice for most small businesses, and rarely needed for most authors. The second choice is to pay someone else to host your website, and let them deal with all the minutiae of keeping the servers ticking.

If you want to go the first route, I am not the best reference for you, though you may find some of the points below interesting. For those paying to host their sites, read on.

What do you need to know about your site host?

How much is it going to cost me?

Depending on where you go, you can pay as little as nadda to upwards of thousands of US dollars. On average, though, the prices for a decent hosting package are settling between the US$3 and US$15 per month mark.

Quick note here - there ain't no such thing as a free site host. If it's not a promo deal, you're paying for the hosting by watching ads, or allowing ads to take up valuable space on your site, and almost always with no control over what gets put in those ad slots.

What should I look for in a hosting package?

This is one of the places where things get more personal. If you plan to podcast from your site, you want more space to store your podcasting files and more monthly bandwidth to serve them. A basic plan that gives you under 100mb of storage and less than 1GB of monthly bandwidth isn't going to be useful. However, if you just plan to send out text-based files, like your web pages, 50mb to 100mb of storage with 1GB bandwidth per month may be more than enough.

The average web page file is between 2kb and 3kb and accent pictures average between 5kb-50kb. In a purely vanilla website, assuming each page view requires five images, the html and the style sheet, let's figure each download to average about 80kb per page view. That means a 1GB bandwidth allowance will let your pages be served 12,500 times. If you have a 15 page site, that's about 800 visits per month, or a little over 27 visits per day, which is pretty decent starting out.

If you add podcasting, well, 1GB of monthly bandwidth doesn't cut it. A rule of thumb for mp3s is that each minute of recording is 1mb of file size. A five minute recording then becomes a 5mb file. If you were to just serve that one file, 1GB of bandwidth would let you send it out 200 times per month, or just under 7 times per day. If you're podcasting, though, the likelihood that you'll have only one 5mb file to serve is slim to none. On a low volume site, you would do best to have at least 10GB of monthly bandwidth. That's why there are podcast hosting services like Podio Books or Podcast Alley.

Where are the servers located?

Why does this matter? Well, for one location defines most of the applicable laws. If you plan on hosting topics that could be subject to censorship in a given region, hosting out of that region is asking to have your site shut down. Another point on local laws is what kind of fiscal burden they place on your site host--who passes that down to you. In Texas, for example, one of the Private Investigators associations has successfully lobbied to make computer technicians subject to PI licensing requirements. There's also the matter of supporting your local economy.

What Server Side Scripts do they Serve?

Server-side scripting languages are the types of involved code-behind stuff that make for the truly "dynamic" sites, where the pages are made on the server based on the programmed code. If they support PHP (most do) and MySQL (a free database server platform), then you can usually set up a WordPress blog on your site with a few instructions and maybe a call to their tech support line or two. ASP and ASP.NET are only served from Windows OS servers--it's a Microsoft invention.

Why do you care about this? Later on, when you want to add extra perks (or pay someone to add them), knowing what Server-Side Scripting languages you can program in will help.

Where can I get hosting?

If you're going to go the route of the no-money-out-of-pocket site host, Microsoft's OfficeLive for Small Businesses is actually a pretty good deal. I set up a site at http://shaybee.web.officelive.com/ just to see how it worked. They do offer extras for a fee--like shopping carts--but the basics are good, like setting up the web pages without having to learn a lot of the code-behind-the-pages. In fact, their site builder system is easy enough to use that, with just a little bit of CSS know how, you can create some pretty nifty static sites quickly and easily. And, aside from being so darn easy to use, they serve ads to *you* and not on your web site.

If, however, you want more control over what goes on behind the scenes, or you want to run a blog at "yourdomain.com", you may find paying for a hosting service to be more useful.

I host shaybee.com through Planet Small Business. The admin screens are fairly easy to use, they offer FTP uploads, and setting up sub-domains is pretty easy, in case you want to run blog.yousite.com. At the same time, most of their tech support is via email, even for basic stuff.

Dixiesys.com has also been recommended by a member of the Writing and Publishing Group.

Feel free to add notes about different hosting companies in the comments for this post.

Tuesday, July 29, 2008

There are two things you pay for when setting up a website: the file server to host the site -- where you store the files that make up your web site -- and the domain. Let's start with the domain.

What *is* a domain?

You've probably already heard or seen someone mention "URL"s. That stands for Uniform Resource Locator, which is a fancy way of saying the directions to stuff you want to see on the 'net. URLs are a subset of URIs, which is where you start needing a degree (or matching experience) to keep from getting lost in the techno-speaking. Domains come in three parts: top-level, site, and sub-site domains. The first, top-level domains, are your .coms and .nets and all. The next up, the site domain, is the part that goes yoursitename in yoursitename.com. Sub domains include the www. or blog. or whatever. All together, they look like: sub-domain.site-domain.top-level-domain.

CAUTION: Each site domain is specific to a top level domain (TLD). Yoursite.com is not the same registration as yoursite.net or .org or any of the other TLDs. If you want yoursite.com and .net and .org and any other TLD (or want to prevent someone else from registering variants on "yoursite"), you have to register for each TLD separately. Most brand concious businesses stick to registering the .com, .net, and .org versions of their site.

Where do you get them, and what do they cost?

Something to make clear, you cannot "buy" a domain--you only lease it. The cost depends on who you register through. You can find accredited domain registrars, entities authorized by ICANN (a.k.a. the guys who run the internet) to lease out domains, through InterNIC. A number of site hosts will also provide domain registration services, though these are usually through reseller agreements. All in all, expect to pay from US$8 to US$15 per year to lease a domain under the .com, .net, and .org TLDs.

You can register your domain lease separate from your hosting service, or you can pick a package. For the most part (i.e. read the fine print on any package deals), your domain registration is separate from your site hosting service.

CAUTION: There's a recent move toward "proxy registrations". One of the pushes for it is that the information you provide when registering for a domain is posted to the WHOIS database as required by existing laws, which privacy advocates find a cause for concern. With a proxy registration, a proxy company registers the domain and sub-leases it to you. I do *not* recommend proxy registrations.

Sunday, July 27, 2008

Graphics

The genre you write in has some say in what graphics you pick. Hearts and flowers and fanciful flourishes abound for romance writers, while tombstones and dripping blood play well into horror. Since you're marketing *your* writing, think of the things that might end up on your book covers. Published authors might be able to get permissions from the copyright holders to use modifications of their book covers as site elements. If you are not the creator of your artwork, you are going to have to concern yourself with the copyrights covering the graphics you choose.

But, as part of your site design, what graphics are you probably going to be looking for? Please note: this is a separate issue from "content" pictures, which could include your book covers or any other pictures posted as part of the reading experience on your site.

Header

The header is the banner at the top of your web page that identifies your site. You may choose to have one header for the entire site or a different one for each section. If you do choose different headers, remember to keep them in "theme" - carry over consistent elements through out the graphics.

Navigation Buttons

These "graphics" don't have to be graphics at all, but if you want something fancier than plain colors, you're probably looking at button pictures. The nice thing is they are easy to build. Try the Buttonator and see for yourself, or use a graphics editing program to build them--these will be covered in a separate post on "Basic Tools for Web Building".

Accent Pieces

Rather like the little touches around your home, accent pieces are all those "minor" flourishes that round out your site presentation. These are the horizontal rules, the bullet points for your lists, attention buttons, and the like. To get a better idea of all that can be considered an accent piece, head on over to the css Zen Garden and flip through the designs there.

Oh, and a nifty thing to note: all those gorgeous designs on the css Zen Garden are accomplished by changing the css file--the cascading style sheet. The actual html--where all the content is stored--is the same through out all the designs.

So, now you've got an idea of what you want your site to look like, it's time to decide *where* to put your site.

Saturday, July 26, 2008

If you read the last article, you should have also gone through this tutorial from Xavier University of Louisiana, about planning your web site. At this point, you should have the content for your site outlined, so this article will expand on the factors that influence design choices.

Back in the first article, I stressed deciding what "message" you want to present. Keep that message in mind while you weigh your choices for page layout, site colors, fonts and graphics--the look of your site.

Page Layout

There are lots of ways to fancy it up, but, in the end, there are only so many ways to arrange your site. The below graphic points out some of the standards:

If you want to get a look at how these can be used, click on over to Open Source Web Design (OSWD). This is also a good place to get templates, but watch the license agreements--some of them are "non commercial use only".

Colors

The colors you choose for your site say a lot. I recommend taking a tour of Claudia Cortes' Color In Motion flash film to get an idea of what associations different colors carry.

Also, while you were over as OSWD, did you notice that most of the sites have a limited color palette? Some good rules of thumb on color schemes are:

At most, only use three colors for background: one for your header, one to put text on and one to look fancy off to the sides

Make sure your font colors have a high contrast with your background colors. Examples: black and white, violet and cream, burgundy and blush

Use complementary colors for your headings and your body text. Using a different color helps set off the headings, but you don't want to lose readability.

Use mildly contrasting colors for your link texts and your body text.

Fonts

Fontography on the web sucks. No matter how many fonts are available for print, there's a bare handful that you can count on being installed on your viewer's computer. If the font isn't on their computer, then whatever they set as the default for that font family comes through. All in all, that means your best bet is working with that bare handful of fonts, or just specifying the font families.

This post is getting long and the graphics are probably going to take as long, so that'll be the next article.

Friday, July 25, 2008

Just as planning your book helps to get it written, planning your site helps to get it--and you--published. This is not a step that you can skip. Even if you pay a professional to code your site, you still need to know what you want to put out for all the world to see. Because this is such a big deal, I'm breaking this up into a few posts. We're starting with the concept, and below are some questions to help you define what your web site is going to be.

Rolling back to the first post, what did you decide your web presence message is?

There is a lot of hype about how every professional entity needs a web site, but, when you aren't a marketing guru, getting to the reason behind the clamoring can be confusing. What it boils down to is that web sites can do a lot of the same marketing activities in cyberspace for far less than it costs to do in print: bill boards, press releases, product demos, newsletters, opt-in mailing lists, Question & Answer guides.... The list is huge, and it can seem intimidating at first glance. DON'T PANIC. Not every web site *needs* to do all these things.

Let's take this page by page.

Every web site has a home page. This is the page you land on when you type the site's URL in the address bar and click your browser's "Go" button. "Above the fold" is cross-over jargon from journalism. That phrase refers to the portion of the page your viewers see as soon as the page loads. "Above the fold" on the home page is the single most important part of any web site. Viewers browsing through decide how relevant a site is to them based on what they see in that first glimpse. Think of this part as your bill board.

Next up are section pages. These are mini-home pages for each topic you cover in your site. Common section titles for author web sites include: Bibliography, News, Contact, and Appearances. Some authors provide "added value" sections, such as a blog related to the topic they write on (mystery writers keeping track of forensic advances, for example). Your bibliography is your book list. News sections are usually blog-style roll outs of the latest on dit regarding your writing--the status of books in the pipeline, the updates to release dates, new appearances scheduled, etc. Contact sections can be as small as an "email me" form or they can have the F.A.Q.s (Frequently Asked Questions) and the publisher's address, too.

Under the section pages come the content pages. These are where you get down to the nitty-gritties. Take, for instance, a content page in your bibliography. The bibliography section page should have links to all the things you wrote that you're trying to sell. Those links go to content pages that provide more information on the particular piece, possibly even samples of the writing and a "click to buy" button.

So, that's the flow of a web site with the overview of what the different pages do. Next article up is going to cover planning out your site.

Welcome to my new blog, inspired by questions raised on the Writing and Publishing email group. It seems there's a lot of confusion about web pages and making them and--even more important--making them work for you. This blog is going to focus on addressing those issues for the benefit of authors. If you're reading this blog, I'm working from the point of view that you already know *why* you want a web site: exposure. As a general rule, people don't buy what they don't know is out there.

So, to begin, let's start with the next big question: *when* do you need a web page?

I take the stance that the sooner you develop your "web presence" the better. This doesn't necessarily mean shelling out cash for electronic real estate, though. A web presence means how much you come up on a search engine's response, or how much 'net cred you get on the groups and forums you belong to. It's how active a member of the internet community you make yourself. Most important, though, your web presence is the message you take into cyberspace.

What does that mean, the "message you take into cyberspace"? The internet is a growing extension of our local communities. Just as your clothes and your body language and what you say tell people you see face-to-face who you are, the text you type and the videos and sound files you share give your fellow netizens insight into your personality and just how polished and professional you are. Before deciding when to set up your customwebsite.com, decide what message you want to communicate. Are you a hard-hitter or laid back? Are you a details person or is the big picture more your style? Are you publishing for the money, the glamor, or the crazy need to get these damn stories out of your gourd?

Once you know what image you want to present, it's time to look at the next factor in deciding your publicity plan timing points: How much self promotion do you need to do? If you're still writing your first submission, don't sweat the web site. If you have that first manuscript in hand and you're sending out query letters, definitely get set up on MySpace, and think about the web site. If you've just signed your first contract, that web site is knocking on your door. If your first book is in stores, yoursite.com is clearing its throat beside you. Self-published authors and authors with multiple books in store who lack a web site are missing a key component of their marketing strategy.