I’m all in favor of this concept: 

An electronic portfolio, also known as an e-portfolio or digital portfolio, is a collection of electronic evidence assembled and managed by a user, usually on the Web (also called Webfolio). Such electronic evidence may include inputted text, electronic files, images, multimedia, blog entries, and hyperlinks.

E-portfolios are both demonstrations of the user’s abilities and platforms for self-expression, and, if they are online, they can be maintained dynamically over time.

An e-portfolio can be seen as a type of learning record that provides actual evidence of achievement.

What I’ve learned is that more and more the changes of software particularly browser technology can make these obsolete over time. It actually becomes easier to keep a checklist of change management. I have four samples up at any given time – some have been up since 2003.

Interesting note: I met a new neighbor last weekend who needs a Federal contract fulfilled with a relevant accounting training I touched on seven years ago.

Flash and PDF seem to be the containers of choice. They’re always displayable regardless of which browsing technology is used – they all support the industry standard.

Charles Jeter’s ePortfolio links:

Tutorial – Completing Government Cost Accounting System Employee Timesheets (Adobe / Macromedia / Captivate / eHelp RoboDemo 2003)

Help File – Codo Software’s Laser Squad:Nemesis Tactics Guide (RoboHelp X5 FlashHelp, 2002 – 2003)

Rapid eLearning – Collaborative Blogging Overview (Articulate Studio 2009 with elements designed using GlobFX Swiff Chart Pro and Adobe Captivate, 2008)

Effective Curriculum Development – Securing Our eCity (multiple technology for Instructor Led Training, 2009 – 2010, shows results)

Corporate Blogwriting – Blogging in April on the ESET Threatblog (Microsoft Windows Live Writer / WordPress, 2010)

Never let it be said that MadCap Software is out of touch with the Technical Communication world in these tough times. Sharon Burton posts about MadCap’s soup kitchen for Technical Communicators. This menu’s got it going on with all the trimmings and none of the cost.

If anyone has an ounce of sense and thinks they remotely might have to swat around theories, buzzwords, or best practices across the desk from a hiring manager within the next eighteen months, you really need to hit up these free webinars.That means just about everyone, including freelancers.

Come in out of the cold, pull up a chair, and listen to industry experts like Sarah O’Keefe talk about killer concepts like DITA. And listen to Neil Perlin talk about HATs to do CMS.

For FREE.

By the way, all but one are technology agnostic. For those of you not already using MadCap Flare you won’t be left out in the cold. I promise people won’t point and snicker.

Categories, times and dates below the fold. Seats are limited I’m sure, so register early.

Read the rest of this entry »

No Jedi Mind Tricks Necessary

Whether there are corporate profits or not the Grinch, it seems, has struck twice in one calendar year for Adobe (NASD: ADBE). You heard my forecast about Adobe’s 2008 earnings here in last year’s posts and who can forget my venting in 2007 regarding Adobe’s negative user support strategy.

Now they have to cut 8% of their global workforce. Looks like the San Diego office will be shut down from the tweets I’ve read and MDowney, the Flex evangelist I was following in my Flex vs. Silverlight series is moving on as well… Good luck to everyone.

From the San Francisco Chronicle: Adobe laying off 600 employees

Adobe Systems in San Jose is laying off 600 employees and will restructure its business, the company announced Wednesday after the stock market closed.

Bottom line analysis for 2009: Adobe will survive in one form or another however all their software programs may not.

No Compelling Reason To Upgrade

Without the Vista mandatory upgrade upswing working in Adobe’s favor, I stated that this year’s sales were going to be significantly lower. I said sell short because there was no compelling reason to upgrade and people would figure they could get by just fine with last year’s model of CS3.

Panic in the streets of Bangalore… MadCap Flare Emerges

Well, ‘panic’ is not entirely fair to state about the Mumbai area after their recent security fiasco. 

Gorillas in the Mists

MadCap Software is currently pounding Adobe on the Technical Communication workflow front. According to the MadCap October press release two independent blogging polls showed MadCap Flare to be the new Gorilla in the Game, promoted up from Chimpanzee:

Flare was identified as the authoring application of choice by more than 39 percent of respondents to the surveys conducted on behalf of the HAT-Matrix.com and I’d Rather Be Writing technical communications blogs.

The surveys represent the first time that Flare, which debuted in March 2006, has seen higher customer use than any other competing solution–including legacy applications that have been on the market for more than a decade.

Add to this the 2008 recession stone skipping across the water and it means sobering trends for ADBE, losing ground on several fronts. From the San Francisco Chronicle:

Read the rest of this entry »

Great article by Michael Hughes, PhD in Instructional Technology.

User books died; if they had value in that form, companies would still print them and users would buy them. Yet PDFs still hang around like pathetic home town sports fans after the team has moved to the West Coast.

Quintus in The Gladiator says “A people ought to know when they’ve been defeated.”

PDFs should get the wake-up call.

Of course the good doctor began his article stating it’s not every single PDF he hates:

Not all PDFs; that would be over the top. I just hate user manuals that are distributed as PDFs. From User Assistance: Why I Hate PDFs

Hat tip to Char James-Tanny’s Helpstuff blog where Char posts many well written tips on PDF user manuals:

If you’re going to distribute an online PDF as a user’s manual instead of one of the many appropriate online formats, then at least make it easy for your users.

A great discussion has started over on MonkeyPi about the Sun Tech Writer who is suing regarding unfair work exemptions. I replied there but this is a far lengthier topic than the comments deserve.

Exempt Tech Writing: How To Not Get Sued

Personally, I tend to view this as a problem that needs a solution. Were I negotiating this matter I would bring up two specific issues which could have prevented this from occurring, or which could lessen the expectations of management.

First, one thing that Adobe does do right is that they allow telecommuting. This allows a 60 hour work week to be reasonably managed along with a busy life schedule because employees can manage their lives around the time they put in on their home systems.

Second, by having a workflow that allows input remotely without endless face to face meetings (the absolute largest waste of time I observed while working as a tech writer for a nameless military contractor) and proper collaboration, a lot of this time saved reflects working smarter, not harder.

Getting Granular about Exempt Status

I found the following definition of exempt status online:

EXEMPT means the job is NOT subject to payment for overtime hours worked. Employer policy may elect to compensate incumbents in these jobs for their overtime, but there are no restrictions on rates used or quantity of hours paid to incumbents in exempt jobs.

Overtime requirements apply to the JOB not the EMPLOYEE. It is the responsibility content of the job that determines if incumbent employees must be paid for the overtime they work.

There is a Highly Compensated Job exempt status but it only applies to Public-Sector Employees.

Legally, exempt employees are due overtime in California law if it can be proven that they regularly cannot complete their normal assigned tasks without working overtime. Two years ago a roommate of mine ended up winning a similar judgement simply by making a phone call to an attorney and having them contact the HR department where he was working.

What it takes to document your situation is at the very least, logging your hours worked along with the tasks you are assigned. Regardless of exempt/non-exempt status, in California the Overtime law states that you cannot be expected to be working for free, which is what regular overtime without pay is.

Summing up, legally Sun is responsible, at least to one employee. The judge’s court order has the attorneys searching for a second employee, a reasonable request given the frequency with which John Edwards-like trial lawyers tend to overuse the class action.

The lawyers will win one person’s case, that’s a given. A landmark ‘blow for Sun techcomms’ it may not be unless they find another employee to sign on the line.

Yet, as this attorney states on his blog in reference to the IT lawsuits:

In this situation, is it any wonder that, increasingly, some California companies are moving jobs across the border to work in other states where employees don’t have to be paid special overtime rates?

Just like the ridiculously high workers’ compensation rates hurt job creation in California several years ago, the overtime pay requirements are doing the same thing in the IT industry.

Below the fold are the boring legalese text from the California Labor site… You’ve been warned!

Read the rest of this entry »

Continued from eDMS Roshambo Part 2: Wikis vs eDMS posted a couple months ago. Sorry for the delay.

…And now you understand my RoShamBo comparison. Wiki, according to the authors I quoted in eDMS Roshambo Part 2 beats plain desktop publishing. In fact, Stewart Mader has an excellent book out that’s on my next-to-read-list.

Wikipatterns by Stewart Mader Read more about this book…

And as we remember from my eDMS Roshambo Part 2 quote from Dan’s blog, Dan Ortega feels that with the proper corporate restraint wikis can work well within a corporation.

This is with caveats, and not all of them are limited to technology. There are significant conflicting social elements regarding wiki implementation as well which is a point that Stewart Mader and I both agree upon.

Sacha Chua from The Orange Chair discusses this dilemma in It’s the culture, not the technology:

Corporate culture isn’t something you can change in a few months. You can’t install goodwill. You can’t enable cooperation.

In short, if you work in a hostile corporate environment, wikis might not be the best method to collaborate. Then again, in such an environment there’s probably zero collaboration going on at all.

Wiki Strength: Wiki Usage Resolves Siloed Content Challenge

No more of that developed content (.doc, .pdf, .fm) shoved somewhere on the eDMS or intranet with only desktop tools to edit it with. A wiki provides a single authoring framework that all can use.

Wiki Weaknesses: Homogenizing, Updating, and Repurposing Content

The primary objection / weakness that I have of a wiki integration is in single-sourcing and repurposing the resulting content.

Bringing exported content out into XML or another form is possible in some wikis but the end product still requires some sort of editing tool such as Microsoft Word, Adobe FrameMaker, or MadCap Blaze. Now you run into some issues.

The content’s single sourcing is critical, and if it’s updated in the wiki getting the changes into the technical communicator’s source working files could become a devastating bottleneck. 

The second weakness of a wiki is in the editing tool itself. The integration of concepts such as snippets and variables doesn’t currently existi in wiki editing. 

I would also add that the snippet suggestions and many other ‘homogenizing’ methods that MadCap’s Analyzer offers allow significant time savings in structuring content. This is a capability that the wikis I’ve seen don’t have and I consider this to be a particular weakness when overall content structure is considered due to the time required to get ‘er done.

Wiki content needs to be cleaned up if it’s going to see the outside world. I think behind the firewall a wiki gives everyone something to work with but there’s still considerable work to be done prior to integrating raw text into a corporate presence.

So even with a wiki there is still a workflow requiring a tool, and usage feedback can still be examined within the published online resources.

With RoboHelp or Flare the WYSIWYG is very sophisticated, the result of both product’s design team experience with help authoring. With a better editing tool for XML Flare tends to overrule both RoboHelp and straight wiki collaboration with the MadPak suite which has that killer app Capture, which takes the image variables into consideration so graphic inclusion isn’t such a chore.

I came across a few letters authored in Word 2.0 from my final cruise in 1995 and it got me thinking about my roots in TechComm. Have you had any experiences which led you towards TechComm which stand out?

Yep… Everyone Has a Story…

The initial knowledge management / content wrangling that I learned prior to using specific software tools was through my time in the service in the 1990s. I would have loved tools that MadCap, Articulate and Adobe now make for that. This was even before Microsoft Word and PowerPoint were adopted!

When looking at the time spent in communication simply in my collateral, non-aircrew duties, it seems that my “part-time job” of about 40 hours a week was a Technical Communicator. Somehow I managed to fit flying into this, probably due to the seven day work week that we military folks enjoyed while being deployed.

Workflow of a Typical Aircrew Technical Communicator

While I was in the military, we didn’t have a job description of Technical Communicator however once I was out of training and ‘in the fleet’ we were required to:

Read the rest of this entry »

What do you need to get started?

The Federal government requires that all applicants for Federal grants and cooperative agreements with the exception of individuals other than sole proprietors, have a DUNS number.

That means that if you’re an S Corporation or a C Corporation, or in any way shape or form NOT working as a d/b/a sole proprietorship you will need your DUNS number. 

Great… What is a @#@# DUNS Number

Sounds difficult, doesn’t it? Let me shortcut this for you: Before you can bid on anything as a small business, you must have a DUNS number.

Getting a DUNS number is free and takes only a few minutes. Just click beneath the fold…

Read the rest of this entry »

When you find new authors it’s exciting to read their viewpoints. I initially started this blog with a thread of analysis of Adobe’s RoboHelp 6 release with which I was thoroughly underwhelmed. I had been watching the discussion on MonkeyPi previously, and part of the enjoyment of blogging is responding to what I call distributed discussions.

Back to RoboHelp vs. Flare: The Blog Review

It’s interesting that today’s examples are all from Utah. Being a former Coloradan for several years I have to say it’s nice to see some of the Rocky Mountain crowd. Now let’s enjoy some distributed discussion of RoboHelp 7 and MadCap’s marketing.

First, a view from Paul Pehrson on RoboHelp 7′s competitive abilities with his analysis of Adobe playing the innovation catch-up game:

RoboHelp is now in catch-up mode trying to figure out how to emulate the innovative features in MadCap’s product suite. Now it is MadCap pushing the innovation envelope here.

Will RH be able to maintain pace with MadCap’s one (or more) releases per year? Will RH be able to come out with new features that aren’t already in Flare?

Maybe so, but RH 7 wasn’t proof of that yet. Again, it will be interesting to have this discussion in two years and see where the major players are at.

I found Ben Minson’s blog when he guest posted to Tom Johnson’s blog. Ben posted a critical thesis about MadCap’s marketing which, by the way, is a great opinion piece.

The thing that has bothered me the most about what has happened with RoboHelp and Flare is MadCap’s marketing approach, which caused “Flare” and “MadCap” to leave a bad taste in my mouth.

Granted, Macromedia’s treatment of the original RoboHelp team was probably less than professional. However, Hamilton seemed to make it his quest to blow RoboHelp to smithereens. It wasn’t business—it was personal. If he could carry that little ring to Mount Doom and throw it in the fire, it would be worth everything that happened in between.

In my research into my Web 2.0 Technical Support series about MadCap Software I hadn’t seen anything untoward expressed online or in print. They did, however, carry a gag gift of the die kadov tag die T-shirt, an inside joke about RoboHelp’s shortcomings.

In fact, in my podcast with Mike Hamilton in December 2007 he was neutral about Adobe. I asked Mike H. several tough and somewhat leading questions about RoboHelp and Adobe. Before, during, and after the podcast he never said anything truly outside the norm, and in fact was more generous than I was in his analysis regarding the level of dedication that Adobe may have with RoboHelp.

In my podcast program we find the relevant segment within the Hamilton podcast:

10:10
Clarifies MadCap’s focus on Adobe: “…we don’t care what Adobe does, we’re focused on solving the problems of the technical writing community… I want to dispel any myth that we’re chasing Adobe.”

11:40
Why I started analyzing the space closer: MadCap’s openness in summer 2007.

12:10
Thoughts on other blogger’s views about Adobe’s Technical Communications Suite (TCS) launch. Mike responds by comparing integration of tools within Flare and within Adobe TCS – Example of Capture’s integration with Flare to support the concept of single sourcing workflow.

We went into other discussion of workflow…

34:30
Remembering RoboHelp: we each discuss where RoboHelp came from and why it’s so different from this model MadCap’s following. Mike elaborates on the competitive edge MadCap has right now in integrating all of their products.

36:40
Mike believes that both RoboHelp and Flare will be around for a long long time, of course he and I differ on this viewpoint. He does mention the caveat of how much innovation Adobe puts into RoboHelp being questionable which we both agree upon completely.

Read the rest of this entry »

Indiana Jones & TechComm?!?

My first impression of government Technical Communicators  while in the military brought to mind that last scene in the classic film Raiders of the Lost Ark where, after the entire film’s adventures the Ark of the Covenant is being (air finger quotes) examined by top men.

Indy asks who, and the reply is the same: Top. Men.

As the film cuts away, we see the famous box holding the Ark being wheeled down the hall of a warehouse.

I tended to think of Technical Communication within the Government as being the same. Content repositories being siloed. It was hard to access and in the worst case in recent history, being responsible for the events of 9/11 according to the 9/11 Commission’s report. Agency A couldn’t communicate with Agency B in time to bring actionable information to bear, therefore… We all know the rest of the story.

How interested is the dotGov in listening to TechComm consultants?

Read the rest of this entry »