Wiki Gets Facelift!
March 20th, 2009 by mcdowI’m glad to announce that the WebWorks Docs Wiki has just received a facelift.
Does this mean it looks different?
- – Yes.
Does this mean it functions different?
- – No… well Yes.
So what did actually change?
We changed the MoinMoin theme of the Wiki to use a theme based on the classic Windows Explorer approach to viewing files, or in this case, wiki pages. Then we observed how we could use wiki categories (similar to delicious tagging) to construct a more functional and visual approach to navigating the entire contents of a wiki. You will probably notice that it looks very similar to an online help format, and certainly it has that capability as well. However, there is much more here than just meets the eye….
Please stay tuned, as I have more to reveal, but it will require more than one post. Have a great day!
Blogs and Agile
August 28th, 2008 by mcdowI’m glad we are getting some recognition for our blogging efforts, which leads me to a few thoughts for the end of August.
So now it seems that even Marketing has gone “Agile”. I think having a blog as a company marketing mechanism is very agile and is big change from traditional marketing techniques that require significant investigative, planning, and implementation phases that are very expensive and SLOW. Or at least not taking into account that these phases must be a relatively narrow interval of the overall time frame to achieve the larger goal (i.e. grow market share). I remember in my early days at this company, the ATI folks would always hammer me with statements like: “you have to start your marketing initiatives a year in advance of the release”. Maybe that was true back then because not much was agile and getting yourself in a channel required significant advanced lead time. I remember having to submit an editorial topic a year ahead of the product release, when we didn’t even know if half of what we presented would even matter.
I believe this is more than just the packaging-for-business of powerful methodology, but becoming a business prerequisite for dealing with the shear speed of change in all sectors of business. Of course, the importance of being fast is not new. Tom Peters wrote back in the 80s that: “either get fast or go broke”
With RoundUp and our Agile messaging soon to come, I think we can get ourselves some recognition in this space as well. “Agile is not just for your dev team…”
Another thought:
Agile is the umbrella under which you have many useful tools and practices now making headlines: i.e. wiki, blog, ePublisher…
I even like this better than using “Web 2.0″ as the umbrella, because I believe Agile represents the more substantial component or “secret sauce” of what makes “Web 2.0″ actually deliver value. Do you think collaboration would occur without it? Maybe “Web 2.0″ is a result of “Agile” tools and trends?
Screen Capture Programs
August 15th, 2008 by mcdowAt a recent WebWorks.com Open House, a discussion about good tools for capturing computer screens came up and I recalled that I had actually done quite a bit of research and experimentation with these types of tools. I also had put together a short write-up on my company’s internal wiki about the topic. Now I realize that others might find this information useful, so I have made it available on our main wiki site. wiki.webworks.com.
In a nutshell, here were my findings.
Best in Class for:
Static Screen Capture
- TechSmith’s: Snag It
Dynamic Screen Capture (category 1)
- Blue Berry’s: FlashBack
Category 1: focuses on routine training and recording tasks where there are minimum requirements for modifying the resulting output
Dynamic Screen Capture (category 2)
- TechSmith’s: Camtasia
Category 2: focuses on special applications requiring post editing, scaling, and the remixing of audio and video
Light-weight Static and Dynamic Screen Capture
- From the TechSmith folks: Jing
Wiki Versus the 80-20 Rule
January 25th, 2008 by mcdowI’m passionate about business philosophies and how they can be applied to
business processes and systems. Recently, I realized that new tools, such as internal wikis, can call for rethinking our assumptions/common understandings of even well established business philosophies, such as the 80-20 rule.
I was reading a popular book on how to build and stretch an organization. While I would recommend it
for some of its practical ideas, it did have a section that I
questioned, called: “Don’t Treat Unequals Equally“.
The idea being that a common management *mistake* is to devote the same
amount of management resources across the entire team, irregardless of
any perceived or real value that they might provide, or to quote the
book: 1
The Pareto Principle, also known as the 80–20 rule, stipulates that 20 percent of the people do 80 percent of the work. In other words, there are people in every workplace who are substantially more valuable to the organization than the others are. This brings up an important question: What are you doing to reward, equip, empower, and motivate your top 20 percent? Do you treat your top 20 percent the same as your bottom 20 percent? If so, what message does that send about your appreciation and support of excellence in your business? And what’s it costing you to let your strengths atrophy as you misuse rewards, time, energy, and resources?
Right?
Hmmm…. my BS detector was surely firing now. So I did a little
research and discovered that the 80-20 rule is really a simple concept
that is applied to many situations and is more art than science.
In any case, it is derived from the principle that 80% of the
consequences come from 20% of the causes (more).
Wiki Wins! Get Your 80% Involved!
Okay, for today’s discussion, let’s assume Pareto has some merit. All of us would like to think that we have only the 20% in our organization, but for purposes of discussion let’s assume that we have the 80% as well. Then the question becomes whether a well advised manager would simply accept that the 80% were going to be marginal contributors, or could he/she somehow go after the 80%?
I would suggest for your consideration that wiki’s are a powerful tool
for lowering the barriers of contribution. Speaking from Quadralay’s
experience, we have achieved significant employee contribution, including from those that are presumably within our “80%”, by using
internal wikis for capturing information and promoting communication
throughout the organization. Suffice to say, I believe we are executing
as a company well beyond what Pareto would argue.
DITA and Wiki
Coincidently, at the January 2008 Central Texas DITA User Group meeting, there was an excellent panel presentation about DITA and Wiki. Speakers from IBM, Sun, OLPC, and webworks.com presented supportive evidence of the use of Wikis to supplement structured information (DITA) development and management (more).
More
I’ve read Wikinomics and am a strong believer in wiki and how it can be used as part of a larger information management strategy.
Please feel free to share your thoughts and differences on this topic. Stay tuned.
References
- Anderson, Up Your Business!: 7 Steps to Fix, Build, or Stretch Your Organization, Second Edition, Revised and Expanded, John Wiley & Sons, 2007.
- Pareto Principle
- Wikinomics
Adding Intuitive Icons to Your HTML Hyperlinks
January 2nd, 2008 by mcdowThe following image is a recent screen capture of our website front page. Notice that there are icons placed after all the text hyperlinks.
![]()
Today’s blog entry will discuss a fairly straight forward CSS method for adding this behavior to any web content, including legacy files.
Background
For our website, we wanted our text hyperlinks to be more obvious to our readers. In addition, we didn’t want to require any significant re-work of the exsisting content. So after studying how other popular websites were using this technique, we were able to modify a single CSS file and get the changes across our entire website, including our blog, online manuals, and technotes.
Additional requirements were:
- (
) Identify to the reader external links that are not on www.webworks.com or wiki.webworks.com. - (
) Identify to the reader links that jump to a different topic somewhere on webworks.com. - (
) Identify to the reader links that nest within a given topic, but are on a different page. - (plain) Identify to the reader links that stay on the same HTML page.
- Make sure existing navigation links such as menus are not affected.
- Provide a simple mechanism for overriding the icon behavior using the “class” attribute.
- Be able to deploy it immediately without modifying any of the website.
- Make sure it works as designed for both Mozilla 1.x and IE 7 class browsers.
- Make sure that fallback behavior for non-supported browsers is functional.
Keys to Making it Work
- Use a CSS attribute selector such as: “
a[href]” to handle the default case. - Use a CSS attribute selector such as: “
a[href^="http://"]” to determine type of link destination, by matching a beginning set of characters. - Set a background image with a right position and a padding-right value to create the trailing icon.
- Use the correct order for each CSS rule so that the proper properties get set. For example: place the most general selectors first and then append other rules for additional exceptions based on pattern matching.
- If necessary, prefix the selectors with ancestor element types to restrict their use to just the content areas of the website.
Coding It
Sample CSS code
/* links to nested areas (drill down) */
a[href]
{
background: transparent url("/common/img/page.gif") no-repeat scroll right center;
padding-right: 13px;
}
/* links with in the same file */
a[href^="#"]
{
background: transparent none no-repeat 0 0;
padding-right: 0px;
}
/* links to external websites */
a[href^="http"]
{
background: transparent url("/common/img/www.gif") no-repeat scroll right center;
padding-right: 13px;
}
/* links to same website */
a[href^="/"], /* implicit */
a[href^="../"], /* out of current area, but still implicit */
a[href^="http://www.your_website.com"] /* explicit www.your_website.com */
{
background: transparent url("/common/img/jump.gif") no-repeat scroll right center;
padding-right: 13px;
}
/* links that should not have a button (must remove it) */
a[class]
{
background: transparent none no-repeat 0 0;
padding-right: 0px;
}
Limiting Behavior to Content Areas Only
Very likely you will want to limit this behavior to only the actual content parts of each HTML page, which will require a more complex CSS rule. Usually this can be easily accomplished using one or more ancestor prefixes for each CSS rule. Here is an example of the first CSS rule with an ancestor prefix in the selector.
/* links to nested areas (drill down) */
div.content p a[href]
{
background: transparent url("/common/img/page.gif") no-repeat scroll right center;
padding-right: 13px;
}
See our wiki at: http://wiki.webworks.com/DevCenter/Projects/HTML/AddingIconsToLinks for more details.
Evaluating ePublisher Express instead of Pro
December 18th, 2007 by mcdowToday, I would like to briefly explain a change in the process for evaluating ePublisher that began with the 9.3 release.
The change was to have users download and install the component called: ePublisher Express instead of ePublisher Pro. The motivation being to more gradually introduce new users to the powerful design capabilities built into ePublisher by starting with easiest to configure component first, and then progressing to the Pro component once it is determined that users are ready to create their own Stationery for doing production work.
So how do I use Express without my own Stationery?
Try out one of the example stationeries located at:
~\My Documents\ePublisher Stationery
To do this, follow these steps:
- Download and install ePublisher Express
- Navigate to the folder:
My Documents\ePublisher Stationery
and unzip the example files. This will create 3 example stationeries, each in a subfolder.
- Launch Express and create a new project, using any one of the example stationery files.
- Add your own documentation files to the project and generate all. For more information, see the tutorial here.
So then what?
First of all, note that this is a “one size shoe fits all” stationery, which has been configured to loosely work with many different types of documents and source files. However, it is not intended for production work and at a minimum will require some styling work before it will match your own requirements.
Next, experiment with creating projects using Express and your own documentation files. Take a look at the results for different output formats. Then determine the following:
- What format(s) are right for your needs?
- WebWorks Help 5.0
- Dynamic HTML
- JavaHelp
- …
- What behavior does your output require:
- Topic splitting
- Drop down text
- Pop up windows
- Context sensitive linking
- Client-side search
- Integrated PDF
- …
- What style changes are required?
- Page styling
- Graphic styling
- Paragraph styling
- Table styling
- …
Using this information, you are now ready to create your own Stationery using the ePublisher Pro component. This component works similar to Express accept that it allows you to perform a Save As Stationery operation, which creates your own Stationery for use with Express and AutoMap.
Note: Now you only have one more decision. Does your team require a completely hands-off process that integrates with your select VC/CM system?

