Creating your first Web site is easy — get the hosting, create the site, test it… and when you’re ready, start promoting the site. (Hah! Easy…)

But once you have a Web site, how do you create a new one? People are (hopefully) visiting your current site — browsing pages, clicking on services, sending emails. You need the current site to be fully functional for regular visitors while you are working on the new one.

Problem is, since your home page is defined by the Web server as a particular file name (usually index.html or default.htm), you can’t just replace it, or your whole site will break. What to do? There are several common ways to solve this, but one way is better than the others.

Bad Option 1: Intermingling
I’ve seen developers create the new site in the midst of the old one, using different file names to keep things unique. The new Home Page becomes index-new.html and the new subpages are given unique names. New images and scripts are jumbled in with old ones. Once the new pages are tested, the old Home Page file is renamed to index-old.html (or just deleted) and the new Home Page file is renamed index.html. Since the new site doesn’t link to any of the old site pages, they are orphaned and can be deleted, or converted to redirects to the new pages, or (sadly, most often) just left there.

For very small sites, this can work, but it’s messy and can be disastrous.

• During and after development of the new site, it is not immediately clear which pages are associated with which site.
• Since at least one of the filenames must change (the Home Page), that means that all links to that page must also change… right at the moment of launching the site. Most HTML tools help manage the change (for example, Dreamweaver fixes the links automatically), but it’s still an extra task.
• If the old site pages are deleted from the server after launch, there’s a risk of accidentally deleting the wrong ones, thus breaking links. If these files are left, any bookmarks to the old site will still work… to the old site. (I’ve seen this!)

Bad Option 2: Subfoldering
To avoid some of the problems above, people sometimes create a new subfolder inside the current site (e.g. /newsite/) and put all the new site files there. Then, when it’s time to launch, they collect all the old site files into an archive folder (/oldsite/ — or just delete them), then move all the new site files out of the subfolder into the site root. Voila, c’est vrais?

Non. It’s better, but now all the files have to move. All your links might have to change, or links on certain scripted pages might have to change. Even with a program like Dreamweaver helping, I’ve launched sites like this and then spent the next few days (weeks!) finding old links that still include the /newsite/ folder.

The Better Way: Subdomains
Many Web hosts allow you to set up a “subdomain,” which uses your base domain name and adds a prefix instead of the www. It acts like a separate domain name, but you don’t have to register another name. You just need the Web server configured correctly, and most hosting control panels make it easy to do now.

So you set up a subdomain like test.yoursitename.com, then do all the development there. You can browse to it, test the links, run scripts, access databases, and so on. Once you’re happy, you still have to move all the files, but all relative links should not require any changes.

That’s the way I do it.

Today’s my birthday. Yippee!

Here’s the reason for the disclosure: in an increasingly social online world, business can no longer afford to be faceless. Facebook and Twitter facilitate connections between people that are often unexpectedly personal and intimate. For example, I’ve learned from Facebook of the death of an acquaintance’s mother; of the birth of a son to one of my closest friends (I knew the birth was imminent, but the actual news broke to me via Facebook); and I’ve reconnected with old acquaintances such as my high school choir teacher.

But I also represent a business (two of them, actually). And one of the things that I hear a lot is that people hire me for Web site consulting because they feel they know me. Sure they can look at my online portfolio, read my resume, browse the Web site and read about the services I offer… but mostly, when they talk to me, I end up hired. Social media allows that same kind of casual, person-to-person networking, but on a potentially global scale.

So for businesses getting into social media, here’s today’s tip (before I go stuff my face with chocolate cake): Be a real person. In social media, people follow you, not your business. They want to know about you — what you’re reading or watching on TV, what’s important in your life. Share real details about yourself, not just sales pitches.

On the other hand, maybe you should keep your cross-dressing fetish to yourself.

You’ve paid big bucks for your site — original artwork, professional photos, carefully written content. How do you keep someone else from stealing it?

You don’t. If someone wants to grab your Web site content, images or HTML, they can find a way. Best you can hope for is to let them know that they’re stealing, make it a little harder, and (if needed) prosecute.

Here’s the problem: In order for your Web page to display on someone’s computer, the HTML and all images must download to that computer. So it’s all in a temp directory somewhere, and the browsers even make it easy to right-click on an image or text and copy or save it.

Here’s the other problem: Most people look the other way when copyright is concerned. (“Everything’s free on the Internet, right?” or “I downloaded it from Google, so it’s okay, right?” or “They’ll never know.” I’ve heard all these, the last one more than once….)

I always recommend placing a copyright statement in the footer. (Not that it does much good, but at least they were warned.) You can try to protect your images by including JavaScript code that disables the right-click function, or overlaying a transparent DIV, but that won’t stop people for very long. You can use visible watermarks, but that ruins all your nice images. You can embed near-invisible security codes like Digimarc’s (included in Photoshop) into your JPGs, but that only helps if you’re going to go searching for violators… and then… prosecute? You can use Flash or PDF security to protect text or other site content, but these techniques are pretty limited and they can really reduce the usability of your site. There are other advanced protection techniques, but they are expensive and can also be cumbersome.

If you’re selling creative work, you probably need to concern yourself with these issues and take some or all of the above precautions. For the rest of us, it’s a lot of effort for little payoff. We hope people will ask for permission and give us credit… but we may never know.

Recently, I had success looking up an image using TinEye, a reverse image search engine. A client sent me an image asking about using it on their Web site. This is always a concern for me, since most better photos and images are under copyright, and I try to be careful.

But with a reverse search engine, you upload a photo, and the engine tries to identify it for you. In this case, we were able to determine where the image came from and how to get the needed copyright clearance. Not bad for a few minutes’ work.

One thing I always advise my clients is: if you’re going to put anything on a Web site, keep it up to date. Solid advice, and often overlooked.

A few years ago, I was doing background research for a client that had me reviewing Voss Water’s Web site. At the time, their News section was more than a six months out of date, and they had an Events category that was more than a year out of date. In my report to my client, I wondered if they had gone out of business. They haven’t. Don’t know what happened that caused their site to get completely out of date, but I’ve been using their story as an example ever since.

Then there’s this blog — my collection of free Web site advice items, which I’ve been posting to periodically since 2004. And it pains me to admit that the most recent post before this one is July 10, 2009 — more than five months ago! Ugh… I never intended to publish something every day, but a five month gap is ridiculous. Raises the same question as Voss Water: has Brian Wold Consulting gone out of business?

Nope. Thankfully, I’m still in business, and as it turns out the latter half of 2009 was filled with plenty of fodder for more posts to this free advice column — Web strategies implemented, CMS lessons learned, thoughts on the future of the Web, and more. But the gap still looks bad, and I feel compelled to explain. (I was busy!)

Bottom line is, if you’re going to have a News page, you had better keep the news coming. Your Calendar page shouldn’t say “no events” for months at a time. And — gulp — your blog of free Web site advice needs to be updated.

Resolution #1 for 2010…

You have to have been living under a rock to not realize that more and more of our life and work is happening online – online bill paying and banking, online socializing and networking, online radio and TV, online applications like Google docs. All within a Web browser, I can edit videos — my own or someone else’s, create and manage a database, find my buddies using GPS, store and share files, collaborate with a project team, manage my calendar, create fine art, do complex math functions, and make new friends or reconnect with old ones. (In fact, many of those items I can do with an iPhone or Android phone.) There’s even a new shopping site that’ll remind me when it’s time to reorder toity paper.

Earlier this week, Google announced a new operating system, Chrome OS, which will be available next year for netbooks and other smaller devices. I’m oversimplifying, but here’s the essence: since you use the browser for everything anyway, why not architect the browser as the central component of the OS and push other lesser-used things to the side?

I’m sure the news of Google’s OS foray is a blow to the good folks at gOS, whose Cloud browser for netbooks was announced last December. If you missed that announcement, so did I.

Of course, Microsoft tried this years ago, and they woulda got away with it too — if it weren’t for those meddling kids at the DOJ and the EU.

And let’s go back even further. In the mid-90s and early 2000s, I recall a bunch of discussions of how the Internet was going to kill the desktop. In early discussions, people applied terms they knew: it was first called terminal computing until people remembered the leftover stigma that term carried with it from the 80s; then later called cloud computing or software as a service (SAAS) or Application Service Providers (ASPs), and now commonly called Web apps.

Obviously, it’s a slow change process — dependent on Web browser technology, network speed, and the pace of human behavioral change. I think we’re (slowly) turning a corner here, and the things some of us have been discussing for a decade might be finally maturing.

Search is back in the news again. Long dominated by Google (and for now, still dominated by Google), some new tools are emerging. Microsoft is throwing a lot of ad dollars into Bing, which to me is Google with random header photos. Yawn. Meanwhile, Wolfram Alpha is fascinating, even to a mathematics noob like me.

Earlier today, with a few clicks, I learned that in 2008, one in every 414 babies was named Brian and that the name was most popular in the early 70s. (Thanks, Wolfie!)

It’s the next iteration of search — not just keywords, but keywords in context (or tasks combined with keywords to produce context). Instead of a search engine just returning someone else’s information, hopefully ranked in a way that puts the most useful stuff first, the new search guesses your intent and tries to provide what you need — answers, maps, formulas, analysis. The trick, of course, is that guessing my intent must be automated, and the programming for that is immense.

At the same time, I just started using a new (experimental) Firefox extension, Ubiquity. When invoked, it adds an overlay to Firefox that can be made to do tasks, like map an address, email a snippet of a page, check the weather, etc. You type a command or command shortcut and results appear as you type.

So, thanks to Ubiqiuty, I can say that the number of words in this post so far is: 239. And I could Twitter on it (if it weren’t so long). Or email it through a Gmail account. Or translate it to Russian.

There’s a lot of room for improvement in these tools, but I’m very interested in the direction all this is going.

A few weeks ago, a client Web site disappeared. It happens: in the past, other clients have occasionally lost their sites, for reasons ranging from hosting hard disk failures to various human errors. (In this client’s case, they hadn’t renewed the domain name, so the site was still there, but the URL pointing to it had disappeared.)

The problem is, you’re usually the last to know that your site is down. Maybe a client calls and asks if you’re still in business, or your accountant wonders why there were no sales last week.

An easy solution is to use an outside monitoring service. It’ll ping your site periodically, and if it gets no response, you’ll get an alert. I’ve started using mon.itor.us for a few Web sites. It has a lot of features, including a pay service for more advanced monitoring, but the basics are pretty easy and free.

I’m in WYSIWYG hell… and I’m not alone. (For those who don’t know, What You See Is What You Get — the acronym is pronounced whizzy-wig — is a term for any visual HTML editor such as the ones in Web-based email editors, blogs or content management systems. It’s supposed to let you do basic formatting, like bold and italics.)

WYSIWYG editors are great, until they don’t work. Which, lately, has been often.

One of my clients has an older online text editor plugin for their content management system. Problem is, with this editor plugin, what you see is NOT what you get. Formatting is very tricky, especially when I’m pasting text from another source. Even when typing from scratch, there are issues. We’re making plans to upgrade the system, and that should fix some of the problems. However…

Yesterday, I spent about 20 minutes trying to figure out why an entry in this blog (WebBlather) went into bold and didn’t come out of it. Different system, different editor plugin, more up-to-date — still throwing formatting problems. The WYSIWYG editor was showing the text correctly, but when I saved the post, one bold header was making everything else after it display in bold. Fixing it in the visual editor window was useless, since that window displayed everything correctly.

Ugh.

Here’s the problem: WYSIWYG editors display a visual representation of what the HTML code will look like when displayed in a browser. To do that, they create the necessary HTML tags behind the scenes as you type. Sounds easy enough, except for the endless possible scenarios that these tools must cover. Here are a few simple examples.

• Copying and pasting HTML code from another program: if the original code is formatted differently than what the editor uses, how much should it try to fix the pasted code?
• Typing, then using delete or backspace: if you delete all characters in a particular format, should the program keep the format tags in place for when you retype the new text?
• Text formatted with inline CSS versus text formatted with older tags, like [font] or [bold]: should the editor leave the older tags or attempt to convert them to cascading style sheet formatting?
• Clicking at the beginning or end of formatted text: if you click to put the cursor right between plain text and bold text, should the new text you type or paste be plain or bold?
• Microsoft’s many proprietary tags: MS Word and other office programs use an extended set of HTML tags for detailed formatting. Many of these are not part of the HTML standard, but IE reads some of them and other browsers do not. When pasting from these programs, should the editor strip these?

Add to that the many variations with different browsers and browser versions, and it’s a wonder any WYSIWYG editors work at all. And in the case of my client’s CMS, the sitewide cascading style sheets tend to affect the formatting as well… so even if the editor has done its job, the page might still look wonky.

What to do? Most WYSIWYG editors have an “Edit HTML” button. When needed, I go searching through the raw code to find an errant tag or malformed bit of code, fix it, and see if that solves the problem. Some editors have a button to strip all formatting (or strip Word formatting), which can sometimes help — start clean, then carefully add just the formatting you need. And I’ve sometimes pasted code into Dreamweaver (itself a WYSIWYG editor… but better at interpreting code), fixed the formatting, then copied and pasted back into the other editor for publishing.

So even though the WYSIWYG editors have made it easier to publish formatted code, there are still times when they fail, and the old-fashioned solution becomes necessary.

Thirty-six seconds. That’s how long it took to crack my password a few years ago.
Years back, the IT guys at a company where I worked called me to ask if they could use my account passwords to run a test. They wanted to try to hack an account on the system, to test their security and network monitoring. I agreed, thinking that the oddly spelled word I had chosen would hold up.

They called back. We were all a bit stunned by how fast the program had found my password. They had used a dictionary-based attack, using a tool that is available to anybody with an internet connection and a little technical knowledge. Wow. The program had cracked my password so fast, they didn’t have time to test the rest of the network security settings.

I’ve upgraded my passwording habits, but the quality of the tools has improved in the intervening years. Now the security world is holding its breath about Conficker, a nasty little worm that is set to rear its head tomorrow. (Details at PC Mag here.) Among other things, it tries to guess passwords.

So maybe today’s a good day for a quick review: have you changed your passwords lately? Are they strong passwords? If not, make some time to fix the problem before it gets worse.