Session 2:  Session on "Software Usability and the WOW effect " by Alok Sharma from SafeNet

• Basics of Software Usability
• What lead to the increased awareness on Usability aspects of a product or project?
• How can I measure the Usability of my product?
• How can I determine the ROI on Usability investments?
• How can I contribute as a documentation professional?

-----------------------------

Alok is working with SafeNet Infotech as a Technical Writer. He has an experience of more than four years in technical documentation. His hobbies include reading (motivational stuff), writing, exploring new gadgets, and listening to diverse forms of music.

------------------------------
------------------------------

Source:      Synergistech Communications, Inc.
Job Code:    SDA814
Job Title:   Technical Writer
Cash/Prizes: Up to $100K plus bonus and excellent benefits
Audience:    Software developers implementing company's mobile Linux platform
Location:    Sunnyvale
On/Offsite:  Mostly onsite, 2 days/week telecommuting okay once you're up to speed
Relo/Visa:  No

Company Industry/Products/Services:
Smartphone open-source application development platform

Company Size:
[ ] Small
[x] Medium
[ ] Large
[ ] Very Large

Company History:
[ ] Pre-IPO Startup
[x] Established Company
[ ] Industry Leader

Team:
Four senior-level Technical Writers, and a couple contractors, reporting to an experienced Technical Publications Manager

Tasks:

• Develop, deliver, and maintain clear, accurate publications, online help, and related web content that teaches developers about creating and customizing applications for the world's leading smartphones and wireless mobile devices
• Create original reference and customization documentation, programmers’ guides, and white papers
• Collaborate with Engineering, Marketing, QA, and Support to define documentation requirements and manage projects to ensure quality, timely deliverables
• Work with SMEs and other writers to ensure documentation meets both product and customer requirements and is delivered in multiple formats

Required:

• At least three (3) years’ commercial documentation experience in the computer software industry, with a focus on creating developer documentation and APIs
• Knowledge of C programming, including some ability to read C code
• Demonstrated ability to plan, prioritize, and produce multiple concurrent deliverables
• Working knowledge of FrameMaker, Acrobat, and WebWorks Publisher
• Bachelor’s degree in Technical Writing, Computer Science, or a similar area

Desired:

• Familiarity with Linux or another UNIX implementation
• Ability to read C++ and/or Java code
• Understanding of XML and XML-based authoring
• Working knowledge of Doxygen, JavaDoc, or similar document-generation systems
• Proven ability to write for embedded systems or about open-source software
• Demonstrated interest in, or experience with, mobile systems and/or telephony

Summary:
This stable, innovative, and respected technology company is creating an open-source foundation for the next generation of mobile handsets. They seek a technically inclined Technical Writer -- or a Software Developer interested in making a career transition into technical writing – to complement their experienced, quality-focused team and help create reference documentation. Technical Writers at this company get plenty of respect, and generate quality deliverables; it's a place at which talented people are proud to work.

Posted: 5/19/2008

Starts: ASAP

To apply:
Email andrew@synergistech.com with your resume in Word format, and please cite job "SDA814"

Source: Synergistech Communications, Inc.
Job Code: SLX811
Job Title: Lead/Principal Technical Writer
Cash/Prizes: Up to $120K plus bonuses and excellent benefits
Audience: Software developers implementing company's mobile Linux platform
Location: Sunnyvale
On/Offsite: Mostly onsite, 2 days/week telecommuting okay
Relo/Visa: No

Company Industry/Products/Services:
Smartphone open-source application development platform

Company Size:
[ ] Small
[x] Medium
[ ] Large
[ ] Very Large

Company History:
[ ] Pre-IPO Startup
[x] Established Company
[ ] Industry Leader

Team:
Four staff technical Technical Writers and a few contractors reporting to an experienced Technical Publications Manager

Tasks:

• Develop, deliver, and maintain clear, accurate technical publications, online help, and related web content that teaches developers to create and customize compelling applications for the world's leading smartphones and wireless mobile devices
• Research and create user-experience guidelines
• Create original API reference and customization documentation, programmers’ guides, and white papers
• Collaborate with Engineering, Marketing, QA, and Support to define documentation requirements and manage projects to ensure quality, timely deliverables
• Work with SMEs and other writers to ensure documentation meets both product and customer requirements and is delivered in multiple formats
• Review other writers' work, mentor them as necessary, and project-manage your tasks to completion

Required:

• At least eight ( 8 ) years’ commercial documentation experience in the computer software industry, with a focus on creating useful and understandable developer documentation from scratch
• Experience working with user experience (UX) and user interface design experts to document user interface guidelines and user interface components for developers
• Strong knowledge of C programming, including the ability to read C code
• Demonstrated ability to design and implement technical documentation suites
• Excellent project-management and mentoring skills
• Experience working with cross-functional and globally distributed teams
• Proficiency with FrameMaker, Acrobat, and WebWorks Publisher
• Bachelor’s degree in Technical Writing, Computer Science, or a similar area

Desired:

• Familiarity with Linux
• Working knowledge of a GUI development toolkit, ideally GTK
• Experience with GTK Glade, Eclipse, or similar development environments
• Ability to read C++ and/or Java code
• Proven ability to write for embedded systems or about open-source software
• Experience with mobile systems and/or telephony documentation

Summary:
This well-funded, take-the-long-term-view company is developing the foundation for the next generation of mobile handsets. They need a smart, technical, C-literate Lead Technical Writer to complement their experienced, quality-focused team and help create original API documentation, developer’s tutorials, and user-interface guidelines.

The ideal candidate will also have a keen interest in and knowledge of wireless mobile devices and the wireless industry, as well as resourcefulness, flexibility, and a sense of humor.

Posted: 5/13/2008

Starts: ASAP

To apply:
Email andrew@synergistech.com with your resume in Word format, and please cite job "SLX811"

To recap a little... after wrapping up my M.A. in history from O.D.U. last spring, I started another program in pursuit of a M.A. (and recently shifted to the M.S. track) in Technical and Scientific Communication at J.M.U. I skimmed over some items about digital history prior to the start of the fall semester and realized the potential that the Web has as a more effective tool for the delivery of historical content... as well as perspective. So, with the start of the fall semester, the focus of my studies was on the Web (integrated with my personal interest in digital history). Fortunately, the TSC grad program is very flexible in accomodating students from various disciplines.

As the second semester of this program winds down, I'm able to look back and see that I've come a long way in a short time. So far, I've had hands-on experience with Adobe programs such as Photoshop, Illustrator, InDesign, Fireworks, Flash, and Dreamweaver... as well as Framemaker and RoboHelp. I've also improved my knowledge of Technical Communication as a profession and have experience in (among other things) usability testing and technical editing (aka, "emendations").

However, the hypertext theory class that I took this spring really struck a chord in me. I thoroughly enjoyed reading Hypertext 3.0 and Remediation, and could certainly see how various theories could be applied to history. What's even more significant about this class is that, as projects for the class, I 1) developed this blog, 2) created a hypertext nonfiction (based on my personal Civil War "memory"), and I'm 3) completing another project in which I remediate part of a Civil War unit history (link to follow soon!). The class has also made me realize that I want to learn more and, therefore, I'm taking a interaction design class next fall. I can't wait!

What is interaction design? It might sound simple (perhaps at least until one starts reading the Wikipedia definition of IxD). This is what has led me to the topic of the day. When I tell somebody that I'm working on a graduate degree in TSC and my main focus is on Web design, I think I'm selling myself short. To me, saying that I am studying "Web design" sounds too basic. After all, a lot of people build their own websites these days. So, saying that simply doesn't encapsulate all of what I want to do. Don't get me wrong, knowing HTML, DHTML, XML, CSS, Javascipt... that can all be quite a challenge to someone who hasn't gone down that road (and I'm still learning it all!). Yet, when I look at a lot of websites (some of my old websites included in that number), they remind me of headstones. Data in stone, immovable, cold, dead. That's not what I want in the creations that I plan on developing for the Web. I want interaction. I want to engage the reader. I want the user experience to be so gratifying that the reader will return time and time again.

So, that in mind, my thoughts are starting to turn to one year from now. This graduate program has done a lot for me already and will do more for me in the year to come (I can't say enough how thrilled I am to take on Applied Geographic Information Science as my science cognate - it will be a great addition to my new "box of technical tools" in delivering effective digital history). Yet, I want to know even more about how to enhance the user experience on the Web. I've thought about this and started making my way through the Web in search of doctorate programs. Yet unlike before, when I looked at different schools for their history programs, I'm now looking at programs that focus on Human-Computer Interaction (HCI) and Informatics. The way that I see it, the history and the historiography will continue to serve as my content, but it is the many ways in which the content can be delivered that intrigues me now. Like I said, saying that I am studying Web design just doesn't do it anymore. It's deeper than that now. This week, I signed-up as a subscriber to the Interactive Design Association (IxDA) and UX: Matters. It's my next step in seeing that the history that I put on the Web doesn't just sit there as idle content.

Source: Synergistech Communications, Inc.
Job Code: SMD807
Job Title: Senior Technical Writer
Cash/Prizes: Up to $110K plus bonuses and excellent benefits
Audience: Software developers implementing company's mobile Linux platform
Location: Sunnyvale
On/Offsite: Mostly onsite, 2 days/week telecommuting okay
Relo/Visa: No

Company Industry/Products/Services:
Smartphone open-source application development platform

Company Size:
[ ] Small
[x] Medium
[ ] Large
[ ] Very Large

Company History:
[ ] Pre-IPO Startup
[x] Established Company
[ ] Industry Leader

Team:
Four senior-level Technical Writers, and a few contractors, reporting to an experienced Technical Publications Manager

Tasks:

• Develop, deliver, and maintain clear, accurate publications, online help, and related web content that teaches developers to create and customize compelling applications for the world's leading smartphones and wireless mobile devices
• Create original API reference and customization documentation, programmers’ guides, and white papers
• Collaborate with Engineering, Marketing, QA, and Support to define documentation requirements and manage projects to ensure quality, timely deliverables
• Work with SMEs and other writers to ensure documentation meets both product and customer requirements and is delivered in multiple formats

Required:

• At least six (6) years’ commercial documentation experience in the computer software industry, with a focus on creating developer documentation and APIs
• Strong knowledge of C programming, including the ability to read C code
• Demonstrated ability to plan, prioritize, and produce multiple concurrent deliverables
• Proficiency with FrameMaker, Acrobat, and WebWorks Publisher
• Bachelor’s degree in Technical Writing, Computer Science, or a similar area

Desired:

• Familiarity with Linux
• Working knowledge of a GUI development toolkit, ideally GTK
• Ability to read C++ and/or Java code
• Understanding of XML and XML-based authoring
• Working knowledge of Doxygen, JavaDoc, or similar document-generation systems
• Proven ability to write for embedded systems or about open-source software
• Experience with mobile systems and/or telephony

Summary:
This well-funded, take-the-long-term-view company is developing the foundation for the next generation of mobile handsets. They need a smart, technical, C-literate Technical Writer to complement their experienced, quality-focused team and help create original API documentation and developer’s tutorials guides. This is not a “throw it over the wall and pray” shop, but rather a well-managed, talented department that gets a lot of respect.

The ideal candidate will also have a keen interest in and knowledge of wireless mobile devices and the wireless industry, as well as resourcefulness, flexibility, and a sense of humor.

Posted: 4/8/2008

Starts: ASAP

To apply:
Email andrew@synergistech.com with your resume in Word format, and please cite job "SMD807"

And FrameMaker has some special Magic baked in!

How else would it know when you have exactly one hour left until you absolutely have to mail the pdf to the build guy so he can put it on the special CD for the giant prospect?

Since it's Magic, FrameMaker can tell exactly when it's time to have some fun by BSOD-ing repeatedly, just because I tried to update a graphic that was imported by reference. A graphic marketing sent me 5 minutes ago...just a little update! No big deal! Just rename and save it and everything will be cool, right?

I forgot about the special FrameMaker Magic that makes life so fun!

Source: Synergistech Communications, Inc.
Job Code: SDB803
Job Title: Technical Writer or Senior Technical Writer
Cash/Prizes: $open (depending on seniority and skills), plus excellent benefits
Audience: Database administrators and application developers
Location: San Mateo
On/Offsite: Mostly onsite
Relo/Visa: No

Company Industry/Products/Services:
The undisputed leader in enterprise applications for vendor-neutral database reporting (“business intelligence”) and performance improvement. Products integrate data from all sources and deliver personalized, intuitive reports.

Company Size:
[ ] Small
[x] Medium
[ ] Large
[ ] Very Large

Company History:
[ ] Pre-IPO Startup
[x] Established Company
[ ] Industry Leader

Team:
Four senior-level staff Technical Writers and a couple contractors reporting to a seasoned Tech Pubs Director.

Tasks:

• Research, write, test, and maintain original documentation and training content covering the implementation of object-oriented business intelligence tools and including most or all of the following: system administration guides, course notes, API references, programmers’ how-to guides, and code examples
• Collaborate with other writers to edit and test new content, develop example code, and create training exercises
• Track source files and doc defects using engineering department's tools, including SourceSafe and Perforce
• Deliver PDF doc and online help from FrameMaker source files

Required:

• At least two (2) years’ experience documenting enterprise software and, preferably, also creating training materials
• Strong understanding of enterprise-scale relational databases
• Demonstrated ability to document products under development and explain cutting-edge technologies
• Working knowledge of FrameMaker, Paint Shop Pro, Word, Excel, Microsoft Project, bug-tracking, and version-control systems
• BA/BS degree in technical communication or a similar discipline

Desired:

• Knowledge of server technology, web services, Microsoft Foundation Classes, C#, Java, and/or APIs
• Experience developing original, viable example code
• Experience working with or documenting business intelligence, data integration, and related products
• Ability to speak and/or write a foreign language, especially French, German, Spanish, Chinese, Japanese, or Korean

Summary:
Stable, profitable company's well-managed documentation team has an immediate staff opportunity for a Technical Writer – or Senior Technical Writer – with a strong understanding of relational database technology and commitment to effective developer-oriented documentation. Experience matters less than demonstrated potential, which is why the salary is open (but it could go above $100K). This is a tight-knit, respected, collaborative team where you're well-rewarded for doing work that makes you proud.

Posted: 1/5/2008

Starts: ASAP

To apply:
Email andrew@synergistech.com with your resume in Word format, and please cite job "SDB803"

When I started studying I was in college, and my professors did their best to impress on me that things were changing, that I'd better listen up and keep in step. I was lucky because I had a portable typewriter. When I became editor of my college's student newspaper, I was amazed by the latest equipment at the printing press. Linotype, hot metal, metal frames where the newly set type fit exactly with the aid of small pieces of metal for "leading." Tres magnifique.

I leaped out of college to use a fancy "Selectric" typewriter that was faster and prettier than anything I'd typed on before. Later, after five years in Africa where the equivalent of writing for the local newspaper consisted of banging on drums, I was introduced to the world of computers.

In the summer of 1984 when I started graduate work on my MBA degree at Cal State LA, the computer was a rare but coveted possession. I'd taken a chunk of savings and other funds from my years in Africa, including payment for stolen goods, and had bought my own PC for $10,000 for a lightweight metal box with a fan and a small collection of circuit boards in one corner. Only two software programs, WordStar and Lotus 1-2-3 were available at that time. I even bought a printer with output in little dots.

This put me above everybody else in the MBA program. With a computer and a good command of the English language, I was the envy of the class.

Now I have three computers, any one of which can hold more data and run more programs than a thousand or more like my 1984 model.

But things are still changing, almost as fast as when I landed on American soil back in 1984 and began running to catch up.

Since 1988 I've been editing and designing books for self-publishing authors. Tonight I'm putting the finishing touches on a book when the author whispers from his vantage point a couple of thousand miles away, "Of course you can put the book in one file, can't you? Lightning Source requires that."

To tell the truth, I've never needed to do that. I send two files to the computer: one for the text, and one for the front pages. My graphic designer usually sends the cover art separately. I've dealt with three major book printing companies, and they've never said, "We have to have your book in one file."

So I got motivated.

Trial and error, search and find, add and delete. After twenty minutes of hard mental work, I figured out that FrameMaker is happy to put those two files in one book. It worked!

I've tried to figure this out several times, but the solution has always eluded me. Now, with the author breathing rapidly, the learning curve gentled out for me.

Still learning. Things keep changing. We have to run to keep up, even when our joints are stiff and our eyes are fading and our muscles are flabby. As long as we can, we've got to keep up. Or try to.

I'm attending as many sessions as I can at the Quadralay WebWorks User Conference - called the WebWorks RoundUp. Right now I'm listening to a great demo using WebWorks to publish Word or Frame source files to wikitext.

Start with WIF

The WebWorks wiki defines WIF as WebWorks Intermediate Format - basically their Document Type Definition. Serendipitous search engine love for WebWorks. I hadn't realized that when you Google "WIF" you'll find there is a lot of academic call for the Wiki Interchange Format - a lowest common denominator of wiki content exchange. WIF defines a subset of XHTML as an over-the-wire format for wiki content exchange.

Keep it simple

He's demonstrating the concept with headings and paragraphs only, but I would imagine that ordered and unordered lists would be simple, even nested indented lists are simple enough to mark up.

No tables, and I'll admit, they're a nightmare to markup in wikitext, so I sure wouldn't tackle writing the XSLT to create tables from XML to wikitext.

Graphics you could create the wikitext for the file reference, as long as you take the time to upload the graphics to the location where the wiki is expecting them.

Generate the wikitext

He's generating wiki markup using XSLT transforms that he has already set up.

Wikitext markup is really simple, using ASCII characters such as == heading text == to mark up a heading. In this example markup, more equals signs surrounding the heading indicate a deeper nesting of headings. Two equals signs indicate a heading 2, three === indicates a heading 3. Paragraphs are often not marked up at all, making them the simplest output of all. Refer to the wikimatrix.org's markup comparison tool for more examples.

I would have liked to see examples of links and image references created, but this was an hour demo after all. :)

Put wikitext into your wiki

Finally, he's copying and pasting the marked up wikitext into his wiki. For a long article where one page is one article, this approach makes a lot of sense. I could use a tool like this for the One Laptop Per Child project, where we have a Simplified user guide all in one wiki page. Each section is editable just because the wikitext is marked up using ==section name==, which is the markup for that particular wiki (MediaWiki).

And in his keynote the following day, Ben Allums demonstrated that he could publish to the wiki itself. Now THAT is an exciting development. I'll dig deeper into the guts of that and report back.

Scenarios for converting to wikitext

I can think of plenty of scenarios for using this conversion process. Let's say you need a hundred page user manual put into wiki format. This type of conversion would give you a huge leg up on the pre-population of a wiki with a user guide that is already in FrameMaker or Word. I would imagine you could somehow automate the webform population. For example, use IBM's freely available CoScriptor to record the process where you create a new wiki page, then just run the CoScriptor script and paste when needed, then run another script that renames the new wiki page.

Because you can also publish directly to the wiki, but it seems to be in a way that doesn't touch what's already there, this method is a great way to continually update your wiki with fresh content.

Another great use of creating wikis with a conversion process would be for API documentation, especially if you already had a large body of work in a wiki. Let's say you're using DITA as your source file for your API, convert new portions to wikitext.

Any other scenarios for this conversion tool?

Scott Abel, The Content Wrangler, noted the price temptations, especially for people currently on RoboHelp. I'd just add that the upgrade price is the same price as Adobe Creative Suite 3 Web Standard ($999).
Dan Ortega's message from Astoria appears to be but there's no enterprise workflow and it's a desktop solution, meaning, tech writers will still be the only users in a company using FrameMaker. Charles Jeter notes the same lack of collaboration in the suite in a nice wrap up post as well.

Sarah O'Keefe notes that most of her clients are going lighterweight than FrameMaker for their XML solutions.

Bill Swallow (techcommdood) notices that you can only go from Frame to RoboHelp, not back.

While single sourcing is always interesting to me, what I'm curious about are the use cases for Captivate, Acrobat 3D, and Flash, when using this Suite. I've used FrameMaker and RoboHelp in the past, but haven't gone beyond the trial version of Captivate. So I looked at the webinar listing and there are hints at use cases that are an interesting sweet spot for the technical writer who wants to move past the static manual into interactive user assistance - not to mention the technical trainers looking for the correct tool to build interactive demos. Here are some catch phrases I lifted that might be just marketing-speak, but also might speak to where our profession is headed.

• track help system usage
• leverage existing content to create interactive help or performance support
• question randomization
• animation imports from PowerPoint
• do this cool buzzword stuff... without the help of your engineering department

So perhaps a key aspect of what Adobe has heard from tech writers all over is, we want to do cool stuff, but we're not getting the resources we need to program the cool stuff.

And indeed, the webinar folks seem to want to help define where we're headed and how we'll get there. To quote from the intro paragraph, "What does this mean for technical communicators, instructional designers and eLearning professional today and tomorrow?" As go the toolset, so goes the career? I suppose that the skill demand certainly shapes what you learn as a technical communicator in order to stay employable. Does your software toolset make you do your job a certain way?

Not a trick or a hack, but native unicode (utf-8) support.

I did some research on this topic, attempting a conversion of legacy unstructured Framemaker content to DITA, and wanted to write it up here in case it helps others.

In my experience with Frame 7.2, I wasn't able to complete the entire complex process, partially due to the unstructured Frame files, partially due to my limitations in getting XSL to work through Framemaker and writing a Framemaker structured application. Feel free to comment on these instructions if you have questions or ideas for where this process may not work well. Note that I haven't fully studied how this process might change with the introduction of Frame 8, although many of these tips and tricks will still be useful for preparing your content.

Content preparation tips and tricks

If your Frame content is not already written in topics and pretty well structured, work really hard on getting the legacy content into some sort of order that will help in conversion. For example, make each Heading a topic starting point. Next, you may want to type the content into task, concept, reference beforehand using style tags to indicate what type of topic the content is, such as heading1task, heading1concept.

Indicate your task step numbered lists with a different style name from "plain" numbered lists.

Write your abstract and shortdesc (short descriptions) as initial paragraphs of each topic.

Use test Frame files that have few paragraph tags used. Add in paragraph styles one at a time and test the step-by-step process to make debugging easier.

Use a subset of DITA tags for your conversion, meaning you will be converting content to topics with fewer tags than the full DITA tag set. After conversion you can re-tag the content more specifically but having fewer tags to go to means less troubleshooting for the conversion itself.

Performing the conversion

The overall steps for the conversion involve the following tasks:
1. Structure the current unstructured FrameMaker document with the conversion table and rules text file as mapping helpers.
2. Open Frame book file and import the EDD or Element Definition Document, a proprietary FrameMaker file that correlates to a DTD (Document Type Definition).
3. Save the new resulting file as XML, either using a customized migration structured application that applies custom XSLT, or using the DITA Application Plug-In (which is a structured application also).

Each overall step is described in the tasks below.

I'll also describe the files you'd create to start such a conversion. To create a structured application, you create a new folder in a C:\Program Files\Adobe\FrameMaker7.2\Structure\xml\ directory. This folder contains:

• A text file that tells FrameMaker what XML means in it’s own formatting conventions. For example, it tells Frame that the “xref” element is a cross-reference in FrameMaker.
• A Document Type Definition file that works in concert with the EDD file that FrameMaker needs to interpret the DTD.
• An Element Definition Document required by FrameMaker. This file is what you import into a FrameMaker chapter file.
• An XSL file that could transform FrameMaker XML into separate DITA topics rather than maintaining many topics in each chapter file, instead each topic would be in its own file.
• A structured FrameMaker file containing the configuration information for both the DITA plug-in and the new structured application that could use the XSL file for transformations.

To apply the conversion table

1. Open the Frame book file that has had the EDD imported into each chapter file.
2. Open the conversion table file.
3. Click File->Utilities->Structure Current Document.
4. Select the conversion table file name from the drop-down list, and then click Add Structure.

To apply the EDD

1. Open the Frame book file and select all chapter files using Shift+click.
2. Click File->Import->Element Definitions.
3. Select the EDD file name and click Import.

To save as XML

1. Click File->Choose Structured Application. Select either the trx-migrate structured application or the DITA-Topic-FM structured application.
2. Open the Frame book file and select all chapter files.
3. Click File->Save As and choose XML.
4. If you are using the trx-migrate application, the XSLT would be run on this step. If you are simply saving as DITA XML, then you would choose DITA as the Structured Application from the File menu.

Comments on the conversion table

The conversion table takes existing content and maps each paragraph and character style to an XML element, then wraps the elements in outer elements as needed. To accurately portray the information and ensure that one change doesn’t affect other areas of content, you must modify this table one element at a time and then check for accuracy. The conversion table is a painstaking and time consuming project in itself, depending on the complexity of the content you have to start.

Manual cleanup and DITA map creation

According to this article, you would have additional manual cleanup of graphic importing, copy and paste for all table cell text, creation of cross reference links, and creating the hierarchy for your DITA maps because of the flattened nature of the saving topics at the heading level.

Reading list and references for conversion

• Migrating from Unstructed to Structured FrameMaker white paper
• Appendix A in the Structure Application Developer's Guide Online Manual
• Using XSLT in Adobe FrameMaker 7.2 technical paper
• DITA Language Reference included in the DITA Open Toolkit download page at sourceforge.net
• Integrating DITA at Idiom Technologies article on Bright Path Solution's web site

Its a strange issue where when you export a PDF file from FrameMaker text is missing from the output.

On my test system the only way I could trigger the problem was to pull the fntcache.dat file and reboot twice. The awful thing is now that I can reproduce the issue I can't make the problem go away in my case without pulling all the type 1 fonts off my computer. These fonts caused no issues however until I removed the fntcache.dat file.

Strange ehh?

Being the lazy person I am, I decided to find out if I could find a process to make the process simple. This was the result.

1. I copied the data from the screen onto a text doc. The resulting output had commas as separators.
2. Next I saved the file as a csv file and imported the same in Microsoft Excel.
3. I then started deleting the columns that weren’t required and sorted the data.
4. I proceeded to save the file as a csv file.
5. In FrameMaker, I selected the csv file for import. A dialog, ‘Unknown File Type’, popped up and I selected the ‘Text’ option and clicked on the ‘Convert’ button.
6. Another dialog, Import Text File by Copy, popped up with three options. I selected ‘Convert Text To Table…’ option and clicked on ‘Import’.
7. The next dialog, Convert to Table’ listed the various table formats available in the document and also the options on how to convert the text to table. I selected comma as a separator as shown in the figure and clicked on ‘Convert’



8. The data was now present as a table in FrameMaker for additional formatting.

Jen Linton, the co-author of Introduction to DITA:Getting Started with the Darwin Information Typing Architecture is in Austin to teach the DITA Getting Started workshop hosted by BMC Software. I'm attending along with several of my co-workers, and we're all learning a lot.

Last night I went to dinner with Don Day, chair of the OASIS DITA Technical Committee, Jen, and Wendy Shepperd, a manager here at BMC. Jen asked Don, "What's the story with the bird in the DITA logo?" I had blogged earlier that it's a finch with a specialized beak, but it turns out there's more to the story. Don explained that it's a woodpecker finch, one of the finches Darwin documented from the Galapagos Islands, and it's a tool-using animal. Woodpecker finches pluck the spines from cacti or use wooden splinters to extract grubs and other bugs from holes that their beaks don't fit for a tasty meal. That's a fun piece of trivia. Here's the logo to which I'm referring.

After dinner we went to the Central Texas DITA User Group meeting, where Jen told and showed us how she assembled the Introduction to DITA book using DITA topics. The most interesting part for me was to learn about the Mekon FrameMaker plug-in that lets you import DITA content into FrameMaker for book assembly and above all, index generation. Nifty! It's part of the DITA Open Toolkit if you browse the CVS repository.

In our training class, we wondered out loud where all the local User Groups are forming currently, and I found this list at http://dita.xml.org/user-groups:

Canada

• Ontario: Toronto DITA User Group
• British Columbia: Vancouver DITA User Group

United States

• California: Silicon Valley DITA Interest Group
• Indiana: Indy DITA
• Massachusetts: Boston DITA User Group
• New York: NY Metro DITA Users Group
• North Carolina: Research Triangle Park DUG
• Texas: Central Texas DITA Users Group (Austin)