Editor Log: November 2005

Rootbeer277's Top 10 Edits
or
please stop doing this, it's getting repetitive

There are no end of nit-picking guides to formatting, we don't need another one. We don't need randomly constructed advice on how to use HTML tags and how to format our writeups and what mistakes to avoid. What we do need is a listing of the errors I see show up most often. A random list is easily ignored because most of it doesn't apply to you. This particular list has been generated by my experience as an E2 editor; they are, in order from most to least common, the errors I see creep up over and over again. Please put extra effort into watching for these specifically when proofreading your work. Oh and by the way, please proofread your work. You'll save us some work and yourself some aggravation.

I should point out that I'm not just being picky with the HTML standards I've included. In order to demonstrate the improper formatting used in this writeup, I couldn't properly implement the <OL> tag! The bad formatting screwed up the formatting of the list and I had to manually type in the numbers 1–10 (including the ever-so-fashionable ASCII decorations). So it does cause problems, I'm not just being a stickler for the "rules".

-= 1 =-

It's/its errors
My #1 edit is, without a doubt, the all-too-common it's/its error. I can't remember the last day that's gone by that I didn't send out a correction on at least one of these. I'm sure you all know the difference, I'm sure it's just an accident. Either your fingers instinctively reach for the apostrophe or you're just not paying attention, but you keep doing it. This can be caught easily with a careful proofread.

On a related note, I occasionally see plurals with an apostrophe, such as "Put all the spoon's in the drawer." This isn't so common but it's just as obviously wrong. You all seem to be doing pretty good with affect/effect and their/there/they're. It's/its still trips a lot of people up though.

Example: Its easier to read your work when it's formatting and grammar are clean of errors.

-= 2 =-

Spelling mistakes and typos
If I see one, I'll copy-paste your whole writeup into MSWord to find them all, then send you a list. You could just as easily do this yourself, in fact it would save a lot of effort on your part because you won't have to track down where my corrections are in your writeup. Please do not draft your work from the text input box in the nodeshell you've created, or even in your scratch pad. Not only does any decent modern text editor come with a spell checker, but it's a lot easier to lose your work when drafting in your browser. E2 doesn't ask you if you want to save your work before closing.

If you're using Mac OS X, you can enable spell checking in your browser, but I would still advise drafting in TextEdit.

I must congratulate E2 as a whole, though, for not falling victim to the spellchecker affect.

-= 3 =-

Unreadable formatting
I know that most of you have been taught that punctuation should pretty much ignore formatting. You're not technically supposed to include surrounding double-quotes or parentheses with the italics or the ending period in the boldface and suchlike. But following these rules can make it difficult to read on a pixellated computer screen, and the rules you have been taught were for printed text. Tall or high punctuation like double quotes, exclamation points, and parentheses are most readable when included with the italics, otherwise the leaning text runs into it.

Furthermore, when using odd characters like Greek letters, accent marks and other diacritics, and mathematical symbols, you'll want to double check to make sure they're not crowded by punctuation or parentheses, or worse, obscured by the underlining a hard link adds. It's often a good idea to include a space between quotes or parentheses and the character you're using if it's crowded.

Finally, do not nest SMALL tags more than 2 deep, and do not combine SMALL with italics. It's very hard to read, especially for people who don't have the best eyesight to begin with.

Examples:
(∫) vs. ( ∫ )
"Wait!" vs. "Wait!"
Is this readable? vs. Is this readable?
≡ vs. ≡

-= 4 =-

Thousand-word paragraphs give me a headache
Remember that text on a computer screen is different from text in a book or newspaper, especially with regard to the length of lines. A line across the computer screen can be many, many times longer than a standard line in a book, which causes problems when drawing your eyes back to the beginning of the next line from the end of the previous line. This is why many textbooks are formatted with two columns per page, it can be easy to lose your place. For this reason it's good to keep your paragraphs on the short side. There have been numerous writeups I've been forced to read by highlighting lines so I don't lose my place.

On a related note, sometimes you'll have a OL or UL list in which each listed item is a paragraph in its own right. Normally these will be single-spaced and difficult to read. In this case, it's best to use <LI><P> to double-space your listed items (don't get it backwards though). Remember to end the list item with </P></LI>, or the double-spacing won't work properly in Internet Explorer.

-= 5 =-

Using ALL CAPS instead of italics
All caps have very, very limited use in a medium that allows italics and boldface. Acronyms like NASA obviously use them, and shouted dialogue uses them. But there is no more reason to use all caps for emphasis than *asterisks for boldface* or /slashes for italics/ or _underscores for underlining_. You've got the formatting tools to do this properly, so use them. Don't forget that you've also got <TT> for inserting monospaced fonts in the middle of a sentence, too.

-= 6 =-

Very long sentences with grammar errors
Most of you do a great job of using correct grammar in normal, short, straightforward sentences. However, when writing long sentences interrupted by multiple parenthetical, prepositional, or subjunctive clauses, things can get pretty ugly. Subject/verb disagreement turns into a problem, cases and tenses get swapped around, and sometimes the sentence taken as a whole turns into a sentence fragment because something got left out. The solution to this is to imagine the sentence with all the clauses and phrases removed, stripping it down to its bare subject - verb - direct object essence to make sure this makes sense. The clauses themselves rarely have errors. The problem here is that a very long sentence is difficult enough to read as it is, but grammatical errors compound the problem because the struggle to make sense out of it is destined to be fruitless.

-= 7 =-

Invalid HTML using "li" without "ol" or "ul" tags
Yeah, every major browser will interpret it pretty much the same way, by putting a bullet in from of each item but not indented — normally. It's still invalid HTML, you can't guarantee it will look the same way on every browser now and in the future, and it makes you look like an HTML n00b. If you try to nest this inside of another list, you'll definitely mess up the formatting. If you really want the bullets without the indentions, you can use &diams; — ♦

On a related note, sometimes I'll see bullets with letters or roman numerals after them, because somebody wanted the indentions but didn't know that the OL lists have more options than the default Arabic numerals. You can use <OL TYPE=A> to get capital letters, a to get lowercase letters, I to get capital roman numerals, and i to get lowercase roman numerals.

Examples:

Wrong

• Right

• A. Wrong

1. Right

♦ &diams;
• &bull;

-= 8 =-

Indenting with UL instead of BLOCKQUOTE
UL and OL are for defining the beginning of lists, and only for defining the beginning of lists. BLOCKQUOTE is for indenting text. Yes, this is important, especially when nesting your formatting with other types of HTML formatting, especially other lists. Browsers can usually determine what you meant to do, but get confused easily when you use multiple nested tags for purposes which they were not designed. Use them correctly and you don't have to worry about that. Remember that what looks right in Internet Explorer running on Windows XP might not look right in other browser/OS combinations (what, you mean the whole world doesn't use IE and Windows?).

-= 9 =-

Using TAB in a PRE formatted list
One of those things that sounds like a good idea at the time. The problem is TABs are interpreted ever so slightly differently depending on your browser and what monospaced font it's using. If one of your words is crowding up just on the borderline of the next TAB spacing, a different font or browser could push it over that limit and you'll wind up with one line offset from the others by a full TAB. You will never have this problem if you use normal spaces instead of TABs. I see this most often on actor/character lists in movie nodes.

-= 10 =-

Confusing BBCode with HTML
This one pops up from time to time when someone who uses a lot of public forums with BBCode starts using E2. Tell-tale sign: bhard linked formatting tags/b, because BBCode uses square brackets for formatting while E2 uses standard HTML angle brackets. This one's easy to spot and diagnose, and an excellent example of why you should proofread your formatting in your scratch pad before posting.

Last Month | Next Month

Hi, folks.

Last month wasn’t too smooth personally or professionally (some of which will get noded in due time). As such I wasn’t as active on E2 as I’d hoped to be. But I am logged in once or twice every day, and welcome your comments and questions.

Without further ado, let’s get to the admin news from October.

E2 technical problems

The technical team, all volunteers just like the admin team, doesn’t get enough praise for keeping the good ship E2 from coming apart at the seams. This month there were a few alarming sounds from the engines, but we held together.

Writeups not showing up in node heaven

About mid-month it was noticed that deleted items were not appearing in users’ Node Heaven as intended. This was alarming, as writeup deletions on E2 are meant to "un-publish" contributions rather than to fully eradicate them. This took a few days to work out, and in the meantime there was a delay in servicing Node Title Edit, Broken Writeups, and Writeup Deletion requests. Over the course of about a week the problem was identified and rectified. However, it is likely that some writeups deleted during glitch-time didn’t make it to heaven. These may be recoverable - ask an editor if you're missing something you want to see again.

While this went on, the technical team asked the editorial team to defer all deletions until the problem could be diagnosed. Instead, sub-standard writeups were simply hidden from the New Writeups list. This worked pretty well, and suggests a possible change in policy towards poor but potentially salvageable content.

Time is an illusion. E2 time, doubly so.

With the end of Daylight Saving Time in the US, our yearly hiccup occurred where certain display times (such as last seen) drifted off by an hour. Apatrix remarked that “ Keeping our time vaguely in touch with reality is more voodoo than system administration.” We’ll probably have this sorted out by, oh, next April or so.

Editorial policy discussions

Suicide threats, part II

Discussion of the manner in which we handle suicide threats continued, with no answer that satisfied everyone. Most feel that there’s no legal obligation to intervene on anyone’s part, but that we should have a clear statement of policy on the issue (see last month’s Editor log for more).

Complicating the question is the nebulous commercial status of E2. In some ways E2 is a research project, but from a legal viewpoint E2 is still owned by Blockstackers. Honestly, I don’t know exactly. I’m not affiliated with BSI or any of nate’s original crew. I assume that what Hemos wrote is still pretty much accurate. Regardless, we do need a policy, and I’ll be soliciting advice from one and all about assembling one.

The fled make easy targets

The oeuvre of a long-time user of some notoriety came up for discussion. There was some debate about whether said user’s inactive status made them vulnerable to writeup deletions that wouldn’t happen with an active user. For myself, I do look at long-fled user accounts with a more skeptical eye, because they haven’t been around to read their Message Inbox and clean up their own work. But as always, we should be judging the content, value, and reputation of works, not of users. Fled or not should make no difference.

One editor notes that “conservative deletion is the best policy. If you can't support (it) with good reasons, don't delete.” Amen.

Editorial and supra-editorial powers exercised

Being Editor-in-Chief gives me the responsibility to make decisions regarding user accounts, and to to wield the “big stick” when necessary. Fortunately this isn’t necessary often.

Changing user account names

We dislike changing user account names once a user is established. Just as you may look for your favorite author in a bookstore, columnist in the newspaper, or on-line blogger, so too do E2 readers look for user names they know. Changing these names leads to unwarranted confusion. However, there were a few cases this month where name changes were made. One was simple regularization of a StudlyCaps user name, which was an irritant to the owner and readers alike. Another was a slight alteration made to disambiguate a user’s name from a like-named writeup. One more was done to help protect a prolific user’s personal writings from discovery by the user’s mundane-world family.

Deleting all writeups and closing user accounts

Sometimes a user chooses to leave E2, and want to take their content with them. Although this can damage the integrity of a linked database like this one, ultimately E2’s stance is that a user owns their writeups, and so we respect these decisions. The editorial staff will try to talk the user out of it, or get them to donate key writeups to the everyone account, but in the end we will do it. Such a departure occurred this month.

We have a database tool that lets us handle departures cleanly. Sometimes users simply blank their writeups and leave silently. This is a kind of database vandalism, and we ask our users, please, do not handle it this way.

The Hall of Noder Discipline

Deceptively similar user names

Some user names are vulnerable to catbox spoofing with like-names accounts. Users with an m in their name, for example, may be vulnerable to spoof accounts using rn in place. This is juvenile. While not precisely identity theft, it will not be tolerated. Such accounts will be locked, and if there is clear evidence pointing to a user’s main account, that account may be locked too.

Racial epithets

We tolerate a wide range of expression, but hate speech and racial epithets are not normally among them. A user left us in October and left a poisonous rant on the home node. I don’t know what prompted the user’s reaction (no valid contact points were given), but it was out of proportion with having a few writeups deleted. I edited this account to remove the worst of the vitriol.

The good stuff

There were some excellent entries in the 2005 Halloween Horrorquest and as always Page of Cool has some great stuff, including the literally cool iceowl’s latest Antarctic adventures.

Next month

Another rambling report like this, plus questions from the user base, if anybody asks any. Stay well, node well, and let me know if you need any help with the site.

New people here would significantly improve their experience here (especially in the beginning), if they would only take the time to RTFM.

I can only assume new arrivals have read some of the nodes here, or why join? But if they have, why don't they notice stuff about the way wu's are posted? Don't they see that every wu has line breaks, subheads, hard links, and such?

If so, why are most first posts so poorly done? Don't the writers see that what they are about to add to our database doesn't look like what is already there?

Maybe they think that's our job. Maybe they think all they have to do is dump their stream of consciousness on the site and one of us industrious editors will format it and add links.

It can't be that they don't care, because anyone driven by the muse enough to put their words into the public eye must care. Even if all they care about is their work, don't they want it to be well received?

I feel bad when I send a welcome to a newbie and have to kill their first wu that same day. Why don't they read (or even skim) the links to the E2 FAQ and the perfect node I provide when I greet them?

Back when I started writing these Editor Logs, I somehow got the idea that the log with the title of the current month should reflect what I’d done the current month, even though I posted it in the following month.

Therefore, the Editor Log for, say, June 2005 would be posted in July, but be titled “Editor Log: June 2005”.

After a slew of messages from well-meaning but confused noders, and some lengthy re-education from my partner, I’ve seen the error of my ways. It turns out that most folks assume that though the title of the log reflects the current month, it relates work done the previous month. I suppose this has already occurred to everyone else. It’s not the first time I’ve been out of step with everyone else, and sure as hell won’t be the last.

Therefore, this is all you get for “Editor Log: November 2005”. Nothing to see here; press on to Editor Log: December 2005 for November’s doings, if you would.