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.

I’m the so-called “Webmaster” for a couple of large nonprofit organizations, which has me either managing the content of the site or coordinating with other content managers. It turns out that being a Web Content Manager requires a pretty diverse set of skills.

Tech Knowledge: Sure, a pretty good knowledge of HTML and CSS is needed to deal with all the inconsistencies that WYSIWYG editors introduce, especially when copying and pasting from Word or email programs. But last week alone I also had to deal with PayPal buttons, cookies, server settings, ftp publishing settings, DNS and domain name issues, and Flash animations. And on any given week it could be a host of other tech issues to deal with: client- or server-side scripts, database issues, backup and recovery, security and compliance, and more.

Content Organization: It’s just as important for a content manager to understand content organization, and how new content can best fit in with old content. This sounds easy, and I suppose it is in a way, but the number of sites out there with jumbled content suggests that somebody’s not paying attention to the big picture. If it’s just “post this” and “post this” and “post this,” your Home Page is going to become a mess in a hurry. Content managers: take charge, even if it means pulling all the stakeholders together and having a discussion about priorities.

People Skills: Speaking of which, you’d be surprised how much of Web content management has nothing to do with technology. When content is coming from multiple sources, understanding the interpersonal dynamics of people can go a long way towards getting things done. I can’t count the number of times when I’ve said the wrong thing to somebody and had to spend time smoothing out the egos. I like to think I’ve gotten better at working with people over the years.

Think the soft skills are not as important? I’m convinced that, more than anything, this is why I get recommended often. In references, most of my current clients note that they can work with me, and that I explain things to them without making them feel stupid….

Training: …Which brings us to the teaching aspect of technology. Unless you subscribe to the Wizard of Oz school of knowledge hoarding, you’re going to be explaining a lot — tech issues and techniques, your reasons for organizing content as you do, and so on. Having the patience and ability to make difficult concepts clear is going to be one of your tools. Also, be prepared to repeat the same thing several times. (Full disclosure: I’m a former English teacher, so this is probably in my blood.)

Grammar & Writing: In any larger organization, you’re going to be getting source content from many different people, and they all have varying skills of their own. Some will be excellent writers, otherz cant Spel, and some will be just incomprehensible. Sometimes your source writers will be too close to their own content, so they’ll prepare something that works for them, but is useless when jumbled together with everything else on the Web. You’ll need to decide what your role will be. In all my work, I’ve chosen to be pretty active in fixing grammar and spelling and a little less active in rewriting people’s source (except the incomprehensible stuff).

Design, Layout and Formatting: You’ll find people apply different formatting rules, or design for a printed page layout, or just design badly. One of my clients keeps using underlining throughout their source text, even though I’ve explained to them that on the Web underlined text looks like a link and shouldn’t be used for emphasis (people try to click on it, then get annoyed when nothing happens). I’ve worked with people in the past to explain that Web content should probably list the most crucial information at the top, rather than at the bottom. Sometimes you’ll encounter people who’ve gotten the creative bug, so they overdesign things. (Note to those of you who do this: I understand that the process feels very creative for you and you find that rewarding… but for the rest of us who just want the information, we might be less interested in your creative use of vibrant colors and background clip art.)

Clearly, a good Web manager must wield many skills, sometimes at the same time. Good luck!

Okay, we all know that junk email is a problem. But today, within the space of about 15 minutes, three things happened, and they illustrate a problem…

1. A Facebook friend has apparently picked up Koobface, the Facebook virus whose least-troublesome symptom is spamming all your friends with posts (which link to the virus file — therein lies the much-more-troublesome aspect of Koobface). So my Facebook page was filled with junk posts.
2. I logged into this Wordpress blog, which uses a cool utility to restrict comment spam. After I deleted the 327 junk comments that had been posted in the past weeks, here is the message.
   
3. At the same time, my email program pops up an indicator that I have received 11 new messages — 10 of which are junk.

The point is not that junk mail is a problem — it is, but we all know that. The point is that the problem has spread. Not content to clutter up my email inbox, the jerks who put this stuff out there are hitting my blog, and now Facebook, and MySpace, and Ning, and as many other interactive contact points as they can find.

It’s not really me I’m worried about… I set up filters in my email, and they work pretty well. Akismet keeps my blog comments pretty clean, and I set it to manually approve anything that gets through. As for Facebook, well, my common sense to keep me from clicking on ridiculous links.

It’s everybody else that worries me. As we use more and more widgets, and embed things from one site inside another site, how can anyone be expected to keep all the security holes closed?

Problem is, you have to do it. It takes time, specialized tools and some common sense, but you have to commit to all of those things, and not enough people are. Yikes.

First, this isn’t a process tutorial; more a warning: If you move your Web site to a new host or a different server within a hosting company’s server farm, you might break some things…

Here’s a hint: hosts will always tell you what technologies they run (or, as they say, “we support”). But they don’t automatically support your custom applications. They’ll report that their underlying technologies are working properly, and beyond that, you’re on your own.

If your site is nothing but HTML and images, you should not have any problems with a move. That’s because these are basic technologies, common to all Web servers. JavaScript running on the client side (that is, sent to the end user with the HTML and processed by their computer rather than processed by the server) generally is portable as well. However, as Web sites get more complex, the underlying technologies begin to matter. If your site has scripts, forms, a content management system, e-commerce shopping carts, databases, or any basic interactivity, you should review all your technologies before starting a move to be sure everything will still work on the other side.

Server OS (Unix vs Windows): The operating system of the server that runs your Web site can matter a great deal. Most hosting companies support Unix-based servers, which generally run Apache Web hosting software. Some also support Windows-based servers.

People can argue the various benefits of one over the other; I’ve got clients successfully working on both. But if you switch your site from Windows to Unix (or vice versa), you’ll want to at least check all your links to be sure the case of the link in HTML matches the actual file name, as Windows tends to be less forgiving of capitalization differences.

Server-Side Scripts: Common server scripting languages are ASP.NET (on Windows hosts) and PHP (commonly on Unix, but also often available on Windows). In either case, each server supports a particular version of the scripts. If your ASP.NET application is written in version 3 and the new server only supports version 2, expect problems. Also, don’t assume backwards compatibility: your PHP4 app might work on a PHP5 server, but it might not. Even if the main versions are the same, differences with individual settings might cause problems.

Less common these days, but still of concern: CGI scripts and languages such as Cold Fusion. Same guidelines apply: plan ahead and test carefully.

Databases: Blogs, CMS and e-commerce systems use a database on the server to manage the content (commonly, Microsoft SQL or MySQL). If you’re moving a site that uses a database, you’ll need to ensure that your database will work on the new system, or that you upgrade or transfer the data. Also be aware that many hosts keep databases on separate servers, so moving the site and the database might require two steps.

I’ve had a few projects recently where an existing site need a lot of help in a lot of areas: poorly organized, ineffective design, hardware or programming problems, inconsistent integration of various services, etc.

Problem is, design is visual, and clients get that. So they know they want a new design. The other things are harder to grasp. When told that they ought to step back, review their priorities, upgrade their hardware, reorganize the site, and then put a new design together, there’s a disconnect. “Okay, you’re telling me all that other stuff is important, so fine: when can I see the new design?”

Or, worse yet: “Right, we’ll do all that other stuff later — we want the new design now.”
You end up with linoleum design — covering all the problems with shiny new buttons. Perhaps you’ll fix some things, but the underlying problems will still be there. And if those problems are slowing sales or otherwise reducing the value of the site, the shiny buttons will not fix the problem.

A few weeks ago, I was working with two separate clients to track down their various passwords and access notes. Took a long time… Meantime, a friend of mine started a new job where the outgoing guy didn’t leave any documentation, so he was trying to figure out procedures, and in a few cases finding out things the hard way. It occurred to me that you should know, right now, how to access a bunch of different things related to your Web site. If you don’t, it’s no big deal… right?

• Your Web hosting username and password. Note that some hosts have the main login for the account and billing info and a separate login for the Web site control panel.
• The username and password for FTP or other file uploading (such as WebDAV or Frontpage settings).
• The username and password for the domain name registrar (this might be the same as your hosting, but it might not… you’ll probably only need this once a year)
• If you use a content management system (CMS) to manage parts of the site, you’ll need the highest-level administrator username and password (in some CMS tools, it’s called a super-admin).
• If your site uses a database (note that CMS tools and blogs generally use databases behind the scenes), you’ll need to know the database name, location on the hosting server, and username and password.
• You can generally manage the passwords of any email accounts through the Web site control panel, but often all you can do is reset the password. So it might be handy to keep the most crucial account passwords in your list.

Keep this information in a safe place, but somewhere accessible. Posted on the wall in your office might be accessible, but it is probably not secure.

If you haven’t looked at your Web stats lately, perhaps you should. There are useful things to learn there.

I’ve written about Web stats before (see Web Stats: Useful and Dangerous and Hit Counters and Other Bush League Giveaways), so this is just a quick reminder to check your stats periodically. Now let’s talk about errors.

Recently I found myself reviewing Web stats for one client and Web error logs for another. It’s a sign, sez I… must go write about it.

Error logs record activity on your Web site — like Web logs, but instead tracking broken links, bad incoming links and other missing files. Basically, every request to your server that results in an error gets logged. Most servers log errors in a separate file, but your stats program might collect them into a nice report for you. Handy, if that’s your situation.

Common errors are:

• Missing favicon.ico file. This is an image file that the browser requests. If it finds the file, it displays it in the location bar next to your URL. If not, your error log has one more line in it. You don’t need one, but they’re an extra way to brand yourself. On the other hand, getting your logo down to 16×16 pixels will make you cry.

• Missing robots.txt file. This is a text file that responsible search crawlers request when they visit your site. You can use it to exclude certain bits of content (danger here: some hackers look at the robots.txt file to see if there’s any “excluded” folders worth attacking.) At the very least, create a text file and put two lines into it:
  User-agent: *
  Disallow:
  That’s right, it’s mostly blank. Name it “robots.txt” and place it at the root level of your Web site. Done!

• Broken links that you can fix. If your site has broken links, each time somebody clicks the link, your error log reports it. Besides being sloppy and annoying to users, search engines may rank you lower if you have broken links. There’s no excuse for having broken links, so do it now. But before you do, smack yourself in the forehead.

• Incoming bad links. This might be links to old content that the other site owners have never updated, or old bookmarks that a user tried to follow, or they were typing a URL and misspelled something. There might be little you can do to address these.

There can be plenty of other tidbits in the error logs (also, if you have scripts running, you might have multiple log files), but these seem to be the most common. Fix what you can, and try not to lose too much sleep over the rest.