Posted:July 22, 2005

Preparing to Blog – Some Best Practices

I’ve spent the day today cleaning up much of my older draft postings.  I first dealt with the pages; I’m now working on cleaning up the posts.

There have been some major problems and inconsistencies arising from my earlier experiments and tool tests.  Some of the issues I have created for myself that have created their own unique problems are:

  1. I have wanted to "test" an installation prior to posting
  2. I have therefore needed to have a localhost version with a lot of testing; this has complicated standard deployment issues
  3. I have much "offline" content that needs to be re-purposed and imported for this site; this issue alone has introduced major questions of compatibility, tool nuances; etc. (see this related post on re-purposing from Word)
  4. I have a grandiose "vision" of how a site such as mine (or for some minority of others) may move into an industiral strength category — meaning much more functionality and much more scalability
  5. I’m generally not a big "tools" guy.  I have few applications installed on my desktop, I really only use and rely on a handful of applications; the applications I do use I want to understand and rely on thoroughly; and, therefore, I am extremely slow and reluctant to either embrace or shift tools (I may have been one of the last to move from my beloved Wordperfect to Word), and
  6. [As a different reason, let me also mention the weirdness of having latency and other issues in doing all of this testing and posting on the server-side.  While fortunately I am able to do so via a VPN and am not dependent on a hosted service (and also have great support through my main man, Kevin Klawonn), I often feel discombobulated waiting for responses and standard interface environments.}

However, now that I’ve got some experience under my belt and a few scars, I guess I’ll be bold enough to suggest some best practices from this experience:

  • Always try to enter new posts in WYSIWYG mode (in my case using Xinha).  Understand the editor thoroughly; none are perfect, all have quirks, and being practiced with your chosen one will eliminate bigger problems down the road
  • Because of these nuances document, document, and save, save (for example, with today’s version of Xinha when adding new content after saving a draft causes the system to sometimes loose line focus or reference, sending the cursor to never-never land in the file; once understood, this one quirk can be overcome by editing within text and not at the end of a line end)
  • When creating posts, keep two instances of the browser open.  Instance 1) is for completing the text entry on the post; instance 2) is for referencing and getting URLs and other external references
  • Understand CSS.  Somehow, I suspect this is huge moving forward.  Too much "mingling" of content and style may constrain (big time!) future changes.  For example, use the paragraph designator <p> rather than breaks <br> for spacing and presentation.  See my separate post on this topic. In fact, the entire idea of XHTML and CSS is to remove presentation from content.  I’m sorta beginning to understand this concept, which has been a mantra in other forms for my companies, as it applies to blogging
  • Moving external content is difficult.  Every cascade of steps introduces whatever quirks each tool has.  More tools equals more quirks equals more headaches.  Starting from the MS Word environment has its own set of issues, which likely can not be ignored given the ubiquity of these apps
  • When content is imported, take the time to get it clean with the content-style distinctions noted above.  If you don’t do it now, it will be a major pain-in-the-ass conversion later
  • Prior to final posting, you may need to actually review the page code.  Because of editor nuances, prior to posting, review the XHTML code and do some slight re-formatting.  I like to split paragraphs with an extra line break.   This increases readability, and
  • Prior to final posting, review and take seriously your actual HTML code.  If you are using a WYSIWYG editor, this require a toggle to source.  Remember:  Your life will change; you need to be able to convert and understand what you have already been posting
  • Prior to final posting, occasionally validate the code you are producing in draft form using the W3C Validator. You can get the URL reference by "viewing" the draft post while in the system administrator utility of WordPress and noting the URL.

I know I have set a rather high set of thresholds for my own site in comparison to what I suspect most bloggers want or experience.  On the other hand, I have had the opportunity to do a lot of experimentation and tools testing and integration while totally "offline."

I heartily recommend the wisdom of a localhost installation prior to going live for serious bloggers.

Whither Actual Content?

It is not instantaneous nor a Eureka moment to move from idea generation, brainstorning, white boarding, or whatever to something that is actually viewable by a broader public and understandable. In other words, simply because we have the facility to do a quick post, should we?

Ideas that get posted need time, thought and attention before being posted. Even then, perhaps many ideas that are subject to the harsh anvil of scrutiny and time may prove not to have posting potential. My guess, actually the case to date, is that committing to a meaningful blog site means literally tens of hours every week or so spent on deciding, researching, preparing, analyzing, writing, and (often, frustratingly given the status of tools capabilities) refining the appearance of an eventual post. Quick, from the hip, ideas can be generated and written fast, but may not have the legs to get uncorked. I need to be firm about "no wine before its time" and furthermore need to have the discipline to know that some days go without wine or that the bottle once uncorked may be poured down the drain because it is soured or untasty.

Posting Approaches

The creation of posts is the fuel that keeps a blog site going. As I have drafted and prepared this site for release, I’ve come to appreciate a few guidelines:

  1. When an idea of a post occurs, try to draft it completely. Simply beginning a post as a placeholder draft intending to later come back and add the content means efforts are being obligated for the future and the freshness of the insight and ideas goes stale. It is obviously hard to research and complete drafts when first contemplated; after all, we all have regular jobs and demands on our time. But, if possible, complete drafting and delay as little as possible
  2. However, as noted above, that complete draft should be kept in the draft mode; after some time and reflection, publish it or don’t be afraid to deep six it
  3. Another advantage of complete drafting is the challenges of editing and re-posting long drafts in the editor and within the blog CMS. These inefficiencies are discussed elsewhere
  4. Try to post on a regular basis. That pace obviously differs by individual. Steady paces win the race: "Inch by inch, life’s a cinch; yard by yard, life is hard"
  5. Post in smaller chunks; it makes the points above easier
  6. Be willing to look back on some earlier related posts and re-factor into a more complete treatment. I intend, in fact, to do just that with a compilation of my ‘Prepare to Blog’ series.

The seduction of becoming a blogger or auteur is self-evident.  However, moving forward without thought and foresight could create heartaches (if not fatal issues) for sites that eventually move into the big time. I now have a great appreciation for those who simply took the blog plunge, learned by doing while exposed in such a public way, and had to fix and correct on the fly.  Hats off, pioneers!

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Schema.org Markup

headline:
Preparing to Blog – Some Best Practices

alternativeHeadline:

author:

image:

description:
I’ve spent the day today cleaning up much of my older draft postings.  I first dealt with the pages; I’m now working on cleaning up the posts. There have been some major problems and inconsistencies arising from my earlier experiments and tool tests.  Some of the issues I have created for myself that have created […]

articleBody:
see above

datePublished:

One thought on “Preparing to Blog – Some Best Practices

  1. Thanks for this helpfull episode.

    Does anyone knows if WYSIWYG editors do content styling, so it shows like the actual result?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>