As my efforts proceeded in getting this blog set up, I began to realize I was devoting substantially more time and effort to the activity than I originally anticipated. It was roughly at this time of realization that I began tracking time and effort. To date, I have spent about 300 hours(!!) getting my site ready to go, but I know this is in no way typical.

In fact, with services like Blogger, you can be up and running in 5 minutes and for free and posting comments immediately. For reasons noted in my ‘Prepare to Blog’ diary, this de minimus effort may not be advisable. On the other hand, my own needs and demands should not be indicative either. In any event, I present below the breakdown of my time and effort tracking and discuss what may be more "typical" expectations.

Unusual Demands for AI3

As I’ve stated elsewhere, there are some unique and unusual circumstances I have placed on my set-up and investigations leading to AI3. I have wanted, for example, to:

• Understand the blogging and self-publishing phenomenon
• Get my hands dirty with respect to existing tools and infrastructure
• Actually put in place a procedure that will allow me to continue to contribute in an efficient way
• Be aggressive about capabilities and understand "gaps" for bloggers (esp. the "top 1%" in moving forward
• Learn and test tools and techniques to discover gaps and friction points suitable for commercial attention
• Push the edge of the envelop on performance, scale and functionality so as to approach industrial-strength blog sites, perhaps suitable for enterprise use; and
• In general, thoroughly immerse myself into this new culture and technology.

I think I’ve been successful in these aims, but as noted before, incurred time and effort is not typical. As I present the numbers below, I will try to be specific about what may be applicable. Please understand the reference and viewpoint I present is for a serious blog content site, perhaps only applicable to 10% of bloggers or so.

Time and Effort Breakdowns

The table below presents the results of my time and effort tracking. The table shows that about XXX hours have been spent getting AI3 ready over a time from decision to do it until commercial release of about three months. These times and efforts are well removed from a 5-min Blogger site!

The table lists about 30 subtasks (generally documented as individual posts on AI3) broken into the six major activity areas of Research, Set-up, Adding (or integrating) Tools, Composing Posts, or Posting clean posts with review and formatting. Please note the red entries, since these are deemed to be specific to my unusual demands for AI3 and are therefore not typical of what a serious blogger without these aims might experience. The unusual entries are either entire tasks associated with investigating tools and techniques or the efforts spent in composing and posting the ‘Preparing to Blog’ diary.

Observations and Guidance for the Serious Blogger

A serious blogger should be able to get a fairly comprehensive and well-designed site up and running in less than 100 hours, less if some of the lessons and guidance from the ‘Preparing to Blog’ diary are followed, and further less if standard site content (mission, about me, etc.) is shorter than what I provided on the AI3 site. Moreover, unlike the three months it took to get AI3 released, much quicker turnarounds could be easily accomplished. The longer times for AI3 were exacerbated by the three-times effort associated with the site’s unusual demands, business travel and demands, and one family vacation!

Some other observations that may guide planning for serious blogging from these numbers are (with the obvious caveats that different styles and skills may significantly alter these points):

• As a rule of thumb, consider that research and reading in advance of a given post takes about two times longer than actually writing up the results
• Besides normal composition time, consider adding another 50% of time to make sure the formatting is correct and the posting will display properly. In other words, preparing a "content-rich" document for your blog may require 150% of the time it formerly took you
• Set-up time, checklists, site management techniques, naming and filing conventions, etc., are well worth getting worked out in advance to reduce ongoing maintenance and relieve you to post and respond, and
• Continue to record and maintain best practices as you encounter them.

Finally, ongoing requirements and care-and-feeding will remain demands. If one assumes roughly three "good" posts per week to keep a blog active, the numbers above suggest a weekly effort of about 20-25 hours per week or about 1-2 hrs per day, exclusive of responding to user comments. This may suggest lowering expectations to only a couple of quality postings per week.

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

Author’s Note: There is zipped Javascript code that supports the information in this post. If you develop improvements, please email Mike and let him know of your efforts.

Click here to download the zipped Javascript code file and LGPL license (14 KB)

Most blogs provide some text explanation above the comment field for what HTML tags the commenter may provide in her response.  However, I’d seen some other sites that had some buttons that automated some of this process. I set out to add this capability to my site with two objectives in mind:  1) make it easy for the non-HTML user to format a post comment; and 2) keep options narrowed to what I thought was an appropriate subset of HTML format tags.

The WordPress Quicktags Facility

The internal WordPress post and page editor comes with what it calls “quicktags.”  These tags, and their explanations, are:

str

“Strong” – creates a <strong> tag that gives strong emphasis (read – bold) to your text

em

“Emphasis” – creates a <em> tag that gives emphasis (read – italics) to your text

link

Link – creates a hyperlink to a web address which you supply in the pop-up box that is activated by the quicktag. If you select text before you click on the link tag, that text will be used as the link text (the clickable stuff) that will be displayed in your post

b-quote

Blockquote – creates a set of blockquote tags that indent text on both the left and right margins. An example follows

This text is within a blockquote tag

del

Delete – deleted text, text that has a strikethrough line through it

ins

Insert – inserted text, text that has been inserted; marked with an underline

img

Image – this works in much the same way as the link tag, you enter the URL of an image into a pop-up box and the image will be inserted into your post

ul

Unordered List – this adds the opening tag to create an unordered list (bulleted) in your post

ol

Ordered List – this adds the opening tag to create an ordered list (numbered) in your post

li

List Item – this adds a single list item to either the unordered or ordered lists. This tag requires either the ordered or unordered list tags to precede it.

code

Code – text that is formatted in a monospaced font to differentiate between code clips and regular text

more

More – this tag adds a <!–more–> tag to your post, which puts in a “more . . . ” link and puts the rest of your post on another page

page

Page – this tag adds a <!–nextpage–> tag to your post, which continues your post on a second page

Dict.

Dictionary lookup – looks up the word you enter into the pop-up box at dictionary.com and opens the definition page in a new window of your browser

Close Tags

Close Tags – this closes any tags (str, em, link, b-quote, del, ins, ul, ol, li, code) that must be closed in order to stop the formatting from continuing down the page. Each tag also turns into a close tag sign (ul becomes /ul, etc.) to allow you to close that individual tag as well.

Alex King’s Expanded Javascript Quicktags

As an addition to either the existing administrator quicktags or for addition in formatting online comments, Alex King expanded this listiing and provided it in a LGPL-based Javascript download.  This Javascript Quicktags is up to version 1.2 and is the basis for what I incorporated on my site for formatting online comments.

My Modifications

While I liked this version, it had some limitations in meeting my objectives:

1. Too many buttons were provided; I wanted a simpler subset of format tools
2. None of the buttons had tooltips, so that it was hard to understand what some of them did
3. Some of the labels needed clarification
4. I wanted a ‘Preview’ option that would show respondents what their final comments would look like once posted.

The result was that I modified Alex’s starting code.  If you would like to install the same version I have on this site — see the comment field with its buttons below — download the file noted at the top of this post. It includes all of the license and installation instructions of Alex’s current 1.2 version with my modifications.

Future Efforts

I will work to add a preview capability so that the commenter can see her formatted comments before submitting the post.  Longer term, I want to install a limited format WYSIWYG editor, similar to what I am using internally with Xinha.

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

Setting a Ping List

Pinging is a powerful way to alert posting and blog searching services that you have posted a new entry. There is a facility within the WordPress administration center for setting a ping list under Options-Writing-Update Services; the standard ping provided with the default installation is Pingomatic. Eliliot Back has provided a useful starting list of ping sites to include with WordPress. In reviewing his list, I looked at and decided to include these entries, excluding dead links and most foreign sites:

     www.a2b.cc/setloc/bp.a2b
    api.feedster.com/ping
    api.moreover.com/ping
    api.my.yahoo.com/rss/ping
    www.blogdigger.com/RPC2
    blogmatcher.com/u.php
    www.blogshares.com/rpc.php
    www.blogsnow.com/ping
    www.blogstreet.com/xrbin/xmlrpc.cgi
    coreblog.org/ping/
    www.mod-pubsub.org/kn_apps/blogchatter/ping.php
    www.newsisfree.com/xmlrpctest.php
    ping.blo.gs/
    ping.feedburner.com
    ping.syndic8.com/xmlrpc.php
    ping.weblogalot.com/rpc.php
    www.popdex.com/addsite.php
    rpc.blogrolling.com/pinger/
    rpc.pingomatic.com/
    rpc.technorati.com/rpc/ping
    rpc.weblogs.com/RPC2
    www.snipsnap.org/RPC2
    topicexchange.com/RPC2
    xping.pubsub.com/ping/

What is Trackback?

Trackback is a mechanism for a third-party to post on its own site a detailed response to one of your posts.  When done, the third party site pings your site, provides an excerpt ithat displays in the standard comment field, and can then be viewed by URL reference from your comments list.  Thus, the third party respondent need not post on both sites and more detailed responses can be provided on each author’s respective site.  Trackbacks can also be used for content aggregation purposes by topic.

There are many trackback overviews — which sometimes seem hard to understand because of its poor name — available on the Web.  A couple that are useful include the newbie guide from Moveable Type, the original developer of the trackback function and protocol, and a different short version..

Should Trackback be Used?

Initial difficulties in getting trackback configured for my site led me to question whether the function was even desirable.  In fact, within the past year, there has been an explosion of spamming against trackback facilities.  ‘Trackback is Dead‘ is one of the more provocative discussions arguing that the time for trackback is past; Matthew Mullenweg, a founding developer of WordPress, has spent time looking at how spamming can be overcome.

Because WordPress 1.5 has what appears to be a pretty effective trackback moderating facility — the same as what is used for comments — and because there appear to be some trackback spam filters and other plugin utilities, I decided to implement the feature for now, see if it is used, and if spam does occur deal with that problem at that time.

Configuring and Testing Trackback

My attempts to grapple with trackback had some difficulties, compounded by my fundamental misunderstandings.  First, the term is not descriptive, and it took me quite a bit of time to understand exactly what trackback was designed to accomplish.  Second, most blogs that have a trackback function show it as a link prior to the comments section.  I first had difficulty writing my comments code such that the trackback link URL displayed properly (for some reason, I needed to pass arguments in single quotes, not double quotes).  Then, when that problem was fixed, clicking on the link produced a 403 error from my hosting server.  This latter problem suggested that I did not have trackback properly configured, when, actually, it was my misunderstanding of how the function worked that was the problem.

The breaktrhrough in understanding came from external sites that offer ping and trackback testing.  The one I used was from Red Alt .  Definitely use these utilities!  I also testing pinging with  Pingomation. 

The Red Alt instructions showed that my site was indeed sending and receiving pings properly.  In fact, the use of the Trackback link appeared solely to be a means to get the reference URL to display for the third party to properly link to it.  That caused me to re-think the use of a link in the first place.

Displaying Trackback and Permalinks within Comments Section

To prevent others from having the same confusions I had, I decided to make two changes to how most sites handle trackbacks. First, I decided to eliminate the active links for both trackbacks and permalinks, instead replacing them with more description text fields with URLs that can be copied directly off the browser page. For example, for this post, the references are:

The URI link reference to this post is: http://mkbergman.com/?p=103

The URI to trackback this post is: http://mkbergman.com/wp-context/trackback/?p=103

Second, I also decided to make a clear distinction between direct comments and trackbacks in my post comments field. I did this by testing for the type of comment; if a trackback, it is shown as a a different type. The PHP code for implementing this is as follows, placed into the comments.php file where the comment display loop is shown:

             <?php if ($comment->comment_type == ‘trackback’) : ?>
          provided a trackback on
      <?php else : // the comment is a true comment ?>
          commented on
      <?php endif; ?>

When activitated, a regular comment will show as XXX commented on date; if a trackback, it will show as XXX provided a trackback on date.

With these changes, I now had pinging working, trackback working, and clear distinctions in my comments fields as to true comments or trackbacks.

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

As time to release the site drew near, I was presenting the draft AI3 site to some colleagues for commentary.  I was using a projection system that forced my laptop screen display to 800 x 600, unlike my normal setting of 1024 x 768.  Unfortunately, registry of key elements was totally screwed up with this lower resolution. I realized I needed to also keep in mind the 20% of users or so that use this lower resolution. (Note:  up until a few years ago, we designed our products for the 640 x 480 resolution, now totally abandoned. We now standardly design to 1024 x 768, but again some users with older machines and browsers or who need larger fonts keep the 800 x 600 setting.)

What Others Have Found

Like the earlier cross-browser posting, there are differences between browsers (specifically IE) that need to be accounted for in screen resolution-compatible design.  However, the major issue relates to the use (or, more accurately, the improper use) of the so-called "box" model in cascading style sheet and modern HTML design.

Here are some sites that reference the "box" model and positioning that I found helpful:

• Brainjar has a good multi-part tutorial on CSS positioning, and
• These general considerations are also related to the design of "liquid" Web pages, as a helpful The Man in Blue discussion shows.

The guidance from these sites suggested that the key aspects necessary for modifying my site for different screen resolutions were to: 1) make the display elements "relative" in positioning, and 2) set display orders (z-index) properly for wrapping and overlaps.  (The z-index sets the display order of an element with negative values allowed, with a higher number always in front of another element with lower stack order.  The z-index can also be set to ‘auto’, in which case it has the same display order as the parent element. Z-index only works on elements that have been positioned, e.g., ‘position: absolute‘.)  However, as noted next, there were undocumented changes also necessary to get the proper display.

Specific Changes to the AI3 Site

I made all of the changes to my class definitions to ‘position: relative‘ and ‘z-index’ to reflect the display order and foreground/background preferences suggested by these references. But I was still not getting the display desired.

After experimentation, I found that I needed to wrap all display elements that occurred below the masthead in a parent class that would provide a "relative" positioning to the masthead, after which the left and right panels could be absolutely positioned below it.  This I called the BoxParent class:

.BoxParent {

    position: relative;

   }

In addition, my index.php files also called in left or right panel includes at the bottom of the file.  For some reason for registry order to still work properly, I also needed to move these up to the top of the file prior to the posting loop that occurs in the main panel.  While I did not search exhaustively, I did not find any reference to why this change was necessary nor why it worked.  Oh, well, another mystery for this newbie.

These changes provided proper registry in Mozilla/Firefox and IE for different screen resolutions.  However, for reasons unknown, and perhaps related to missing end tags in the multiple php files that are included and invoked during the dynamic display, I found I was seeing both indent and paragraph centering problems in IE that did not show in the other browsers.

My solution was to put extra calls in my source files either for ending a center (/center) or specifically setting margins in-line rather than coming from the external CSS.  These are surely hacks and probably can be chalked up to the standard cross-browser gremlins.  Nonetheless, they worked for now, and I was able to move on.

What Possibly Remains

One of the compounding difficulties of the AI3 design is the use of a GIF in a table within the masthead that forces width in other columns to be narrower at lower resolutions. This effect causes the overall masthead depth to be quite large at lower resolutions, which is not aesthetically pleasing even though the efforts above fixed the registry and layout problems.

The next step is for me to include some Javascript to detect browser screen resolution.  At lower resolutions, I would switch out a smaller version of the masthead GIF and lower the scaling factors for the AI3 and other fonts in other cells.  When implemented, I will invoke these four changes:

1. Use the Javascript to detect screen resolution, and then at lower resolution
2. Replace out the masthead image
3. Change the 900% scaled fonts to 600%
4. Change out the 150% scaled fonts to 115%.

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