Without fail, there is one argument I find myself involved in with every site I test: LOGIN is not a verb.
You do not “login” to a website. That’s just not a word. You “LOG IN.” “Login” is a thing. That’s the login, which is where you log in.
Next time, I refuse to have the argument. Next time, thanks to The Lone Gunman, I can simply direct the offending party to this site: loginisnotaverb.com.
Despite what many people –mostly in the computer field– think, “login” is not a verb. It’s simply not. Whether or not “login” is a word at all may spark a debate in some circles, but assuming it is then it may act as many parts of speech, but not as a verb.
I will repeat the important part for clarity: “login” is not a verb. It’s simply not.
Case closed. I hope.
(Originally published at Black Marks on Wood Pulp.)
Hey, let’s not get the idea that I only think about web passwords, because I don’t, despite this being the second consecutive blog post about web passwords.
But, you know, sometimes companies do it wrong.
Background: I sometimes forget passwords, especially those connected to sites I rarely visit. When that happens, I usually just click the “retrieve password” link. That’s what you do. That’s just how it’s done.
Often, password retrieval is a simple process. They send a message to the email associated with the account, and you click the link, and you reset the password, and then you get into your account, and hooray!
Perfect. Especially if you’re the only person with your email password. And ESPECIALLY if you’ve taken time to make a good email password, because that’s an ACTUAL account that deserves major protection, and one you should rarely forget because it’s YOUR EMAIL and there’s a good chance you have to enter the password every two days.
Other times, you’re required to answer a “security question” before getting your magic email. Such as “What is your dad’s middle name?” or “What is your waist size?” or “What did you drink the last time you threw up?” One question. Then, you get your password.
This is common with sites that need a lot of extra protection. Banks. Credit cards. Airline mile programs.
NO SERIOUSLY. Airline mile programs.
Enter Delta.
As with any airline-related web property, Delta’s site is bogged down with extraneous security and over-written drivel. It’s like one of those collections of legal books you see behind most personal injury lawyers has BLOWN UP and reanimated itself as a website.
I forgot my airline mile password, because I usually don’t care about my airline miles. I hopped in to reset my password and was greeted by a new step: selecting security questions.
Security questions are designed to offer security via a person’s history. The assumption is that the answers are known only by the person accessing the website, and are therefore more secure than an address or zip code or whatever. Also, they’re easier to REMEMBER, because they are a part of our personal history.
Delta, however, attempted to make this process as difficult as possible.
Issue Number One
First, I had to select TWO security questions.
Answers must be AT LEAST 4 CHARACTERS LONG, for some reason. Also, let me remind you, I was logging in to check airline miles. Miles that I can only use as Corey Vilhauer. Miles that do not need to be double protected, because they are useless unless I have a hundred thousand of them. Which I don’t.
Whatever, though. I chose the first one (“What is your father’s middle name?”). Then, I tried to choose the second. And I couldn’t.
Issue Number Two
I couldn’t because I was unable to nail down definitive answers to any of the remaining questions.
Understanding that these are security questions, I needed to be fully sure that the answer I gave then was an answer that can be replicated later on. The problem is, I couldn’t guarantee I’d be able to do that.
None of the questions related to DEFINITIVE answers:
1. What was your first phone number? Do I enter with dashes or without? With or without area code? Will I remember which one I did six months from now?
2. What is your paternal grandmother’s given name? I couldn’t remember this at the time. I know it now, but that wouldn’t have helped much.
3. What was your favorite place to visit as a child? I had several. How will I remember which one?
4. What is the name of your first pet? We had a dog and two cats growing up. I don’t remember which was my first, and I sure won’t remember which one I chose six months from now.
5. Where did you meet your spouse/partner? We went to high school together. Will I remember if I say “high school” or will I assume it’s something more detailed, like “biology class?”
6. What is the name of your childhood best friend? I had three very close friends. Which one will I choose?
7. What is the phone number you remember most from your childhood? Is this even a real question?
I decided to choose the last one (“What is the name of the first school you attended?”) Even then, I knew I wouldn’t remember if I answered “Lincoln High” or “Lincoln High School” or “Lincoln.”
Issue Number Three
Which brings us to the last issue. The only question I could definitively answer, I COULDN’T ACTUALLY USE.
My father’s middle name is “Lee.” Three letters.
Disqualified.
Why can’t this have been easier?
In issues of security, definitive answers are required. These wishy-washy security questions are unusable and frustrating, and the character limit for answers is misguided.
The solution is to allow a user to create BOTH the question and the answer. In my case, I could have said “Full Name of High School” and the answer would have been “Lincoln High School.” No ambiguity. I make the rules.
Instead, I fell back to a makeshift solution: I wrote the answers on a piece of paper.
Pretty safe, huh?
(Originally posted on Black Marks on Wood Pulp.)
Go ahead. Go to this site: Senior Healthcare Consultants. Notice the line at the bottom of every page.
“This site is not intended for distribution to any client.”
Snicker. Laugh out loud, if you want; let loose with a rolling guffaw, friends, because that line may be the funniest thing you’ll read all week.
Then, look away. Quickly. NOW.
Because, damn it, that site IS NOT INTENDED FOR DISTRIBUTION TO ANY CLIENT. And you KNOW that means it SURE ISN’T INTENDED FOR YOU, you plebe. This is Very Important Information. This is a Web site that doesn’t just tell secrets: it changes lives. It teaches you the way of the Jedi Consultant. It leads to riches beyond your control. Beyond your DREAMS, EVEN.
Forget everything you just saw.
Because, thankfully, the Web isn’t a completely open and public medium, allowing anyone with a browser and a search term to stumble upon this site, which is not protected in any way, and which, while overwritten and filled with weasel-word jargon, is very much out in the open for everyone to see.
Even their clients.
Just know this. THIS site, by virtue of that adorable little line, IS NOT INTENDED FOR DISTRIBUTION. So stop acting like it was distributed to you.
That’s not what it was intended for. Obviously.
(Originally posted at Black Marks on Wood Pulp.)
Spoiler alert, you guys.
So New York Magazine’s Vulture blog posted a little ditty about whether or not Don Draper chose the right woman on Mad Men’s season finale, complete with an episode spoiler right in the headline: “Is Megan Really Right for Don?”
Spoilers in the headline? One comment summed it all up:
“It’d be awesome not to have spoilers in the headlines.”
Point taken, apparently: New York Magazine’s response was to change the headline.
Unfortunately, the headline doesn’t stand alone.
Updating Content = Updating Metadata
As with any content management system worth its licensing cost, posts on Vulture’s site are published with an automated simple URL. The assumption is that this URL becomes the permalink of the article, forever and ever, despite any changes in content or, in this case, the headline itself.
The headline was changed, but the URL remains the same. The result: a spoiler is only partially averted.
The lesson is simple: our blog posts and articles and Web pages are so much more than art and copy, and – especially in the case of a major news blog – we as writers and content specialists need to always remind ourselves that changes do not necessarily cascade throughout the metadata.
It’s not only a problem in the URL, either. When we update an article, do we also update the timestamp? Do we let the reader know the article has changed? Does it now fit under a different category, or are there different tags that can be assigned?
Updating an article or blog post or even a static HTML block of copy can range from a spelling correction to a major re-write or adjusted attribution. Different levels of change lead to different levels of updating.
That being said, all levels of updating require a quick confirmation that EVERYTHING has been updated. It’s something I forget on this blog every day. I’d be willing to guess it happens to you, too.
The “Change Everything” List
It’s one thing for this to happen on your little personal blog. But when it starts popping up in a major publication’s news feed, it becomes a larger (not to mention, more noticeable) problem.
Having a simple workflow in place to address post-publication changes can help catch the small things that might fall through the cracks. For example, when updating a blog post, a content wrangler should check:
A. URL – Does the URL still reflect the nature of the article?
B. Metadata – Tags, categories and other items of taxonomy – are they still valid?
C. Post Status – If the post has changed drastically, is there a way to flag the post as “changed” or “updated?”
D. Date/Time – Some CMS programs will automatically update the timestamp. Determine whether the timestamp needs to stay the same (in the event of a minor spelling change or other item of insignificance) or if the timestamp needs to be adjusted to reflect new information.
There’s more, too, depending on the level of journalistic integrity, what your CMS allows and what your readers expect. Adjust and administer as you see fit.
But What About Links?
Yeah. Good question.
In the case of this Vulture article, the headline itself was changed rather quickly – enough to think that, if the URL was also changed, it would still be in the initial stages of gathering inbound links.
But what about an article that’s a few hours old? A few days?
That answer ain’t simple, folks. It’s a matter of serious discussion, comparing the benefits of giving the post a more fitting URL with the risks of losing those inbound links.
Some CMS packages allow for single-page URL redirection. Most don’t – at least, not as a base function – and changing the URL runs the risk of leaving a sea of broken links, especially as an article moves further away from its original publish date.
In the case of this Vulture article, what seems like a URL mix-up may, in fact, be on purpose. If the article blew up early and garnered a large amount of traffic, the editorial staff may have said, “Hold on, buddy. Spoilers are a part of the business, and we’re a news-based blog, so let’s keep that URL and just change the headline.”
That being said, there’s a lot to be said about the editorial process before we even reach this kind of decision. If articles go through a solid set of checks and balances, there will no reason to get this far.
Boiling it Down
Above everything, the question of changing URLs after publication outlines the necessity of carefully reviewing content before it’s posted: a policy of steering clear of immediate spoilers, in this case, would have prevented the need for a URL change.
We can’t be perfect all the time, though. I know I can’t be.
So develop a quick checklist and apply it to all post-publish edits. Do it right now. It’ll take no more than 15 minutes, and it’ll save you from spoiling the finale of Mad Men for some unfortunate soul.
(Originally posted at Black Marks on Wood Pulp.)
