Web 2.0 and Truth
posted by Sarah
My presentation at X-Pubs was about the impact of Web 2.0 or user-generated content on technical communication. (You can view the presentation at the bottom of this post.)

A phrase I heard repeatedly in reference to professional content was "a single version of the truth," which alludes to the idea that you should only have one instance of any given piece of content.

And that got me thinking. There are many areas of tech comm where this idea makes sense.

User-generated content, though, is in direct conflict with a single, unchanging, objective truth. Wikis, by definition, have content that is constantly evolving.

Furthermore, there's truth and then there's, well, truth. Compare and contrast these two snippets:

"The ABC feature is unusable. Use the XYZ as a work-around."

"You can use ABC to do blah blah. Here's how:
(many annoying steps)"

Which one is truth? Both? More importantly, which one is more useful to the reader?

It takes a brave or maybe foolish corporate technical writer to criticize their own product explicitly. (This, in turn, is probably why third-party computer trade books sell so well. Somehow, I don't see a title like Word Annoyances getting the Microsoft seal of approval.)

But even though technical writers try to act as user advocates, there's a built-in conflict of interest -- technical writers are paid by corporations, not by users.

User-generated content meets a need that corporate technical publications do not (or perhaps cannot). It provides unfiltered, opinionated, and user-biased coverage of technical topics.

Why is there a gap between professionally created technical publications and the end users?

1. Updates can take a long time to get into the official documentation because of lengthy review, approval, and publishing processes.

2. Annotation capabilities are rarely provided to users. If they are, they're usually fairly limited.

3. The documentation is not sufficiently candid.

What are the implications for technical writers?

1. Document publishing needs to accelerate.
2. Online documents should allow for comments and discussion.
3. The documentation needs to be explicit about product limitations and workarounds.

In effect, technical writers need to have more of an editorial voice.

Here is my Web 2.0 presentation:



Notes: Use the arrow keys to navigate through the slides. The first slide may take a few seconds to come up; the presentation file is quite large.

Labels: analysis, conferences, web 2.0, xpubs

11:21 AM Permalink | |

 
A Quarky new approach?
posted by Sarah

Recently, Quark has announced their new dynamic publishing concept and/or solution.

Where to start?

Although traditional publishing allows each author to hand-craft the appearance of each page, the limitation is that it ties information to the way it is presented. This means that if you want to publish the same information in print, Web, and electronic formats, then you have to create an entirely separate version of your information for each media type.

Fascinating, but it sounds oddly familiar. Where could I have heard this before? Wait! This sounds like an argument for...single sourcing!

[S]ingle sourcing means writing information once
and using it many times. It does not mean writing it and
then copying and pasting it into another source, or modifying
the information for different needs such that you have
multiple sources.

That would be from The Impact of Single Sourcing and Technology by Ann Rockley, published in Technical Communication in 2001.

The term "single sourcing" also appears in Designing Windows 95 Help: A Guide to Creating Online Documents, which was published in 1996 (!). You can see excerpts via Google Books. I'm sure there's more, but 1996 is plenty early.

Anyway, back to Quark:

Dynamic publishing is a different way to create and share information. Dynamic publishing lets you create information as reusable components of information that you can easily combine for different uses - different types of documents and different audiences.

Dynamic publishing also automates the page formatting process, so you can automatically produce print, Web, and electronic content from a single source of information.

Sorry, guys, but what you're describing is "single sourcing" and it's been around for a while. And I don't think redefining "dynamic publishing" is going to work, either, because that term already means something. Dynamic publishing can refer to the following:

• Publishing on the fly: The information presented is based on the end user's requests and/or profile. Information is assembled when the user requests it (and not ahead of time).
  
• Customized publishing (or variable data publishing): The process of publishing content where the information varies but the overall organization stays the same. Financial statements are a good example of this type of publishing -- each customer needs their specific transactions on the page.

Wikipedia has a definition of dynamic page publishing. RR Donnelley has dynamic publishing products. Here's a discussion of low-end dynamic publishing inside Six Apart (blogging platform). The RenderX engine has dynamic publishing ("For high volume, mass composition of personalized correspondence..."). For one-to-one marketing, we have PageFlex from Bitstream and Fusion Pro from Printable. Here's Arbortext and their discussion of dynamic publishing.

Arbortext. Hmmmm. There's something about Arbortext....

And here is where the situation gets truly weird. Take a look at the Quark executive biographies page. Of the ten people listed, five are ex-Arbortext, including the CEO, CIO, marketing VP, and two of three sales VPs.

So, Quark is the recipient of some sort of a multiple-organ management transplant from Arbortext. Given the rumors that the Arbortext-PTC merger hasn't been exactly a lovefest, the departure of senior management and others isn't surprising. It's their reappearance at a single company that's striking. And furthermore, it appears that they are trying to create Arbortext, MarComm Edition.

Will this work? The landscape is pretty bleak.

Here is an excerpt from Eric Kuhnen's analysis (published on TheContentWrangler.com, and you should read the entire thing):

Quark, in proposing to integrate a CMS into its Dynamic Publishing Solution, has just added a well known set of problems to their offering. There are literally dozens of CMS-enabled solutions on the market already; Quark’s entry is nothing new (well, it is to Quark but not to its customers). It’s not that adding the CMS itself is the wrong idea, but that incorporating a traditional CMS will yield fewer benefits to the customers in the markets it serves, and will not do much to displace the leading ECM vendors in the markets it would like to serve. So, Quark will follow the road it has always taken.

(Emphasis mine)

A variation on this theme is found in an interview with Raymond Schiavone conducted by Pariah S. Burke, editor of QuarkVsInDesign.com (again, read it all, especially the analysis of the interview on the third and fourth pages). This excerpt is from Burke's analysis:

I think QuarkXPress will continue to have utility on its own, but its primary role will be to function as a desktop client for an as-yet unrevealed enterprise-grade suite of systems.

XPress 8 will be the first stage, I predict. [... Schiavone's] realistic goal for the XPress 8 generation of products will be to make the market take notice of Quark again, to open a dialog with large workflow managers who will help refine Schiavone’s vision for XPress 9.

By the time XPress 9 and its matching systems do release (probably less than 12 months following the release of version 8), QuarkXPress will be little more than a client application. All the real power will reside on the server-side systems. More importantly, by abandoning the so-called “feature war” with InDesign, Quark will create a lopsided conundrum for potential users—you can have near total automation of your publishing and production, with output to print, PDF, PDF/X, HTML, XML, and everything else you can think of, but without certain creativity, composition, and proofing features the competition will have had for generations.

The existence of InDesign Server notwithstanding, I think the overall analysis makes sense. Basically, transitioning Quark into a server-based publishing system requires moving away from freelancers and small business customers. They can't afford and don't need server-based publishing. Instead, Quark needs to make inroads into large companies with large marketing departments. And there, they run up against the twin buzzsaws of InDesign and existing competition in the content management space. This might work if Quark's offering was deeply compelling, unique, and game-changing. In its current version, it appears to be none of the above.

The most difficult part of any change in technology is end user adoption. I've discussed change management on this blog and elsewhere. Bringing XML and automation into a marketing or publishing workflow is going to present some unique challenges.

In publishing (not technical publications), the deliverable is in fact the product. As a book publisher, you care greatly about the appearance of your final product, the book. In technical publishing, the appearance of the documentation is often negotiable, and making the inevitable compromises on formatting to get better automation is an acceptable tradeoff. This may not be true for most magazine and book publishers. (It's worth noting that the most technical of trade book publishers, O'Reilly Media, was also the first, as far as I know, to move to XML-based publishing.) Quark grudging acknowledges the challenge in the description of their solution:

Dynamic publishing started in the realm of technical documentation, where large manufacturers and some types of publishers have implemented dynamic publishing to produce user guides, service manuals, parts catalogs, legal documentation, and similar types of information.

Some publishers have built their own dynamic publishing systems for publications that have more elaborate layout requirements than technical documentation, but these systems have been cobbled together from multiple technologies. In many cases, they have achieved some of their business goals but at the expense of far higher process costs.

"Cobbled together"?

"Pot? This is Kettle. How you doin'?"

Here is a description of what's in Quark's DPS (from the Quark DPS FAQ)

Quark Dynamic Publishing Solution (DPS) is publishing software. It consists of multiple software components, some from Quark and some from third parties, including:

• Optional desktop products for creating content: QuarkXPress, QuarkCopyDesk®, Xpress™ Author for Microsoft® Word, Adobe® InCopy® and InDesign®
• Standard server-based publishing software: QuarkXPress Server and Quark Transformation Engine, for publishing to print and electronic media
• Standard server-based product for automating workflow: Quark Publishing System
• Optional browser-based product for content creation, final document edits and reviewing
• Integration with server-based products for content management partners such as Alfresco®

(emphasis mine)

(Image from Quark's web site: http://dynamicpublishing.quark.com/dps/how_it_works.html)

Uh-oh. Getting marketing people to follow structured authoring concepts is going to be really difficult.

A couple of final notes:

• The Quark-written content attempts to position this solution as the logical response to non-single source workflows. This is silly. I'd like to see a discussion of what makes Quark's approach to single sourcing better, faster, and/or cheaper than others.
• There's a discussion of return on investment, which includes this gem: "the return on investment can take from six to eighteen months." Indeed. It can also take forever. Not every organization will be able to show ROI for this solution, and claiming otherwise is ridiculous.
  

All in all, I'm none too impressed with Quark DPS version 1. Now, if the "dynamic publishing" bit in the name is a preview of coming attractions rather than an accurate label for what they have now, then perhaps there's hope. But I'm glad I'm not the one trying to pull this off because from out here, it looks like an extreme long shot.

Labels: analysis, quark, xml

2:55 PM Permalink | |

 
DocTrain: Document Engineering in User Experience Design
posted by Sarah
Bob Glushko
blog: Doc Or Die
University of California, Berkeley

Has a history as a consultant in hypertext (Hypertext Engineering), Passage Systems (single-source publishing and SGML), and then Veo (business-to-business commerce stuff), which was purchased by Commerce One. "And I made a gazillion dollars."

He has just started a company called Document Engineering Services.

What is document engineering?
Designing the information models and repositories that enable document-centric applications.
Building an information supply chain
Examples: tracing lettuce origins because of contamination concerns, simplifying passenger travel (and then some wildly entertaining attacks on TSA, the agency everyone loves to hate), integrating web-based stores and retail stores (purchase something online and return at the local store)

Information tech and business process are co-evolving

• New business processes are created/coordinated/choreographed via the management and exchange
• Standards/patterns

Document exchange patterns

• Businesses exchange documents to transact stuff
• Supply chains and distribution channels are metaphors for the coordinated flow of information and materials/products
• Processes are "glued together" by overlapping information components in the documents

Interesting discussion.

Document design questions are fundamentals.

"Drop shipment" pattern
* web store takes the order and validates it
* warehouse has the stuff
* web store notifies the warehouse
* warehouse ships the stuff

"hidden documents in business processes"

overlapping info models from shipping note, purchase order, transaction advice

traditional design approaches were preventing him from seeing the whole problem. Focus on documents is wrong. Need to focus on user experience -- not the interface, but Did the Product Arrive on Time and was the order fulfilled properly? Does the right person pay? Does it go to the right address? Did it arrive on time?

Traditional User Experience Design
* emphasis person-to-person interaction
* focuse on touch points where service is delivered or received
* implies that a richer or more personalized user experience is usually better

The need to bridge the "front stage" and "back stage"

* focus on the service encounter implies a sharp distinction between the interaction between customer and provider and what makes the interaction possible.

compare restaurant experience: MacDonald, gourmet restaurant, Japanese steakhouse -- amount of "front stage" varies greatly.

"Radical Claims Start Here"

* Many design ideas and methods need to be substantially rethought.
* Moment of truth reveals service quality but rarely determines it.
Front stage/back stage is not an architectural distinction -- it is just a point of view.
* It embodies some design biases that cause problems in service system design.

hotel service
* quality of check-in service
* Ritz higher than Motel 6
but missed the point of quality of experience.
Losing the reservation: Bad. No amount of nice will help with that.
kiosk check-in: low interaction/high quality

four encounters at hotel check-in:
* employee looking up reservation
* hotel systems talking to Expedia
* and some others I missed

all have to work for the front stage to work properly
quality is enabled or constrained by all of the service encounters.
even though many encounters don't involve or are invisible to the customer

service encounters are information exchanged
* person-to-person and machine encounters are less different than you might think.

Service system
* abstraction of service encounters are information exchanges

front stage/back stage distinction is a point of view
tension between front and back stage is not intrisic
merge the mindsets between front and back
services should be modular and configurable
information flow and process models across both
actionable user models
model-based user interfaces

customization and personalization
what information is required to do this?
where can this information come from?

ask question or fill out form?
one form or many over time
how about using information we can already to make it unnecessary to collect information from the user

mass customization/segments of one

model-based UI and UX

personalized banking...specific accounts but generic offers

traditional service design concepts -- moment of truth, front stage/back stage

need a methodology for designing service systems that are more horizontal or end-to-end
all services can be viewed abstractly as information exchanges.

Very interesting presentation.

His book is Document Engineering.

Labels: analysis, doctrainwest08

1:43 PM Permalink | |

 
WritersUA: Pundits panel
posted by Sarah
The pundits' panel is always fun and usually slightly wacky. The panel this year was Alan Houser (Group Wellesley), Scott DeLoach (ClickStart), Bogo Vatovec (Bovacon), and Kevin Siegel (Icon Logic).

Tools and technologies

Alan Houser: XML-based authoring and publishing will remain a niche component among user assistance workflows. Alan points out that XML-based tools do not match the features of conventional authoring tools and haven't achieved substantial market share. Thus, he expects that this will remain a niche approach.

[I would have to disagree strongly with this. Organizations are implementing XML despite the challenges with the authoring tools. As the tools improve (and they HAVE TO because surely it can't get a whole lot worse), they will become less of an obstacle and thus open up XML-based authoring to more people. In our business, we are seeing demand for XML-based authoring across every possible industry, company size, and content type.]

Kevin Siegel: Adobe will develop the Tech Comm Suite for the Mac

[Sorry, Kevin, I suspect this is wishful thinking. I'll be happy if you're right, though.]

Bogo Vatovec: User assistance technologies need to bridge the gap between readers and creators and support user-generated content.

[Is this a prediction? It seems like more of a feature request. But I would have to agree that this is needed and will probably happen.]

Aha. The tools aren't so great and it's the help authors fault because we're asking for the wrong features.

Scott DeLoach: Within seven years, your applications, your files, and almost everything else will be web-based. (And also, PCs, phones, cameras, and GPS systems will converge.)

[Yes. This is already happening with GPS-enabled phones and the like. I'm not too sure about the seven-year estimate, but the convergence assumption seems reasonable. And the move to the web is clearly already underway.]

Scott thinks that we won't have RoboHelp for the Mac, but that RH will run on the Mac because it will be web-based!

Joe Welinske thanks Scott for "going out on the edge there" with a prediction that "in seven years, gadgets will be smaller." Hee.

User Assistance

SDL: Within five years, all software UA will be embedded or web based. Web-based content means only one copy and updates are immediate. Other web-based UA will become part of the help -- wikis, discussion groups, FAQs, and the like.

[That seems uncontroversial. Next?]

KS: Unsociable help systems won't be invited to the party. Today's students want to be fully engaged by media and games. He predicts the era of "rich media." If your help system isn't dominated by interactive commenting and interactive media, it will be irrelevant.

[This may be true for tools that are optional (think Quicken), but not so much for tools that are needed to do your job (not optional).]

BV: Introverted technical writers will not be writing help any more and will be replaced with experts moderating support forums. Companies should focus on enabling search of user forums rather than on help development. Technical writers can no longer afford to hide in their cubes, they must go out and become experts and talk to the users. At this point, they are support engineers rather than technical writers.

[Second reference today to "not providing obvious information" and instead focusing on important information.]

AH: Rich Internet Application technology will fill the current void in help delivery engines.

Lots of stagnation in the help delivery tools and mechanisms, but more innovation in the last year. The logjam seems to be breaking with the new RIA technologies, such as Adobe AIR.

[Totally agree with this.]

Joe: "The majority of the help created in the last 20 or 30 years is pure crap because it was created by people who would much rather be doing anything else." But the people in this room are creating much better stuff, he says.

Bogo definitely struck a nerve with his comment about not being introverted. Several comments about how introverts can TOO do this job.


IT Industry

SDL: Within 10 years, the web will not be free. Access devices and access will be free or inexpensive. Free web access will include ads on pages and ads at set intervals.

[Interestingly, that's exactly the model that the "free municipal WiFi" in Portland uses. You can access the web for free, but you get a sidebar full of ads, and an occasional interstitial ad (interspersed when you try to follow a new link).

I hope he's wrong about this one, but I've got a bad feeling that he's probably right.]

KS: Smaller training companies could virtually meet their demise. Companies must add virtual classes and eLearning. This puts the responsibility for the software on the student instead of the training company. The technology works, the bandwidth is available, and the cost of hosting online meetings is reasonable.

[We are offering a significant number of classes online, and I suspect that this is true. Although classroom learning is better than web-based instruction, it's also a lot more expensive. So, web-based training provides a cost-effective alternative and removes a lot of the friction associated with travel required for classroom learning.]

AH: The quality of machine translation will improve dramatically within 5 years and will match the quality of human translators within 10 yeras.

[Oh, not a chance. (Usually, I agree with Alan on stuff. Not today.) However, it may be that machine translation will become "good enough." Hand-crafted translation may be reserved for high-impact documents rather than for "utility" documents.]

BV: Computers as we know them will disappear. We will have one-for-all devices, specialized devices, and embedded computers. Additionally, the oddest devices, like kitchen ovens, have full computers embedded. So the challenge is to figure out how to provide user assistance for the oven?

Bogo thinks that we will not "pay for access to the Internet" as Scott said, but instead that we will "pay to get non-crappy content."

Fun panel to round out a great conference!

Labels: analysis, writersua2008

7:51 PM Permalink | |

 
"Once you start down the DITA path, forever will it dominate your destiny"
posted by Sarah
Eliot Kimber has a lovely article on using DITA for narrative documents. I'm trundling through it, nodding in agreement, and then we have this horror:

[...] DITA offers at least two compelling advantages over any other candidate XML application:

1. The initial cost of ownership is low, approaching zero, and the ongoing cost of ownership is low.
2. It offers a number of sophisticated features in terms of modularity, extensibility, and linking that either are not provided by other applications or would cost a prohibitively large amount to build from scratch.

That is, the cost of applying DITA is almost always going to be significantly lower than the cost of any alternative (and at worst will be no more expensive than any other alternative).

Now, he does qualify this statement by saying that these assertions apply only if DITA is a reasonable fit for your problem. But the overall thrust of the argument appears to be that since DITA can do narrative documents (which it was emphatically not designed for), it can potentially be applied to an enormous new set of content.

Ugh.

Before I begin today's DITA-bashing session, I need to point out that we are currently using DITA for several projects here at Scriptorium. DITA slices! DITA dices! DITA advocacy raises your IQ, improves your health, and makes you irresistible. I like DITA just fine.

Moving right along...

"1. The initial cost of ownership is low, approaching zero, and the ongoing cost of ownership is low."

Just because it's free doesn't mean it's cheap. The default output from the DITA Open Toolkit ranges somewhere between unattractive (HTML) and fugly (PDF). If you care about the appearance of your final documents, you are going to have to do a lot of work to get the look and feel you want. And although the OT offers a starting point, customizing it is kind of like a trip to the dentist. The impacted-wisdom-tooth-removing kind of trip.

Getting your output working properly is Not Easy because of the, er, unique design of the OT. If the set of tags you need is small, you might be better off building a nice petite NovelML and then writing the transformations you need for NovelML instead of wrestling with DITA's complexities.

"2. It offers a number of sophisticated features in terms of modularity, extensibility, and linking that either are not provided by other applications or would cost a prohibitively large amount to build from scratch."

I agree that DITA has some lovely features in this area. However, I fail to see how they apply to the example at hand -- a narrative document such as Moby Dick. If you need modularity, extensibility, and linking features, you should consider DITA. If you don't, then these features will just get in the way.

That is, the cost of applying DITA is almost always going to be significantly lower than the cost of any alternative (and at worst will be no more expensive than any other alternative).

If DITA is overkill for your requirements, then applying DITA may not be cheaper.

But the issue that upsets me the most is this: when you attack a problem by assuming (or hoping) that DITA will work, you necessarily look for DITA features you can use. You may not think carefully about non-DITA features that you might like to have. For fiction content, I can think of several things that would be quite useful (and for which DITA offers no immediate support):

• For a book that is part of a series (like a science fiction trilogy), a listing of the entire series and an indication of where the current book falls in the series.
• Metadata to identify the point of view. Many novels switch from one narrator to another, or from a first-person point of view to an omniscient point of view. It would be lovely to filter the content to see only the first-person content (after reading the book from cover to cover as the author intended).
  
• Similarly, metadata that helps with scene location and time could be invaluable for studying literature written with numerous flashbacks. The Time Traveler's Wife and anything by Jasper Fforde come to mind.
• The ability to index by character occurrence. This is more often seen in nonfiction books, especially biographies. But imagine scanning the entire Harry Potter series for scenes with Severus Snape to determine whether his ultimate allegiance was consistent.

Of course, you could pervert and/or specialize DITA to support these and other requirements. But if you start with a DITA-shaped box, how likely is it that you will think carefully about the possibilities outside the box?

As Eliot says, the advantages of DITA can be significant. But I fear that a generation of documents will be crammed into DITA, resulting in documents that are not as well structured as they need to be.

I will now await my smackdown from the DITA Disciples.

Signed,

DITA Dissident

Labels: analysis, dita, xml

9:44 PM Permalink | |

 
2008 Predictions: They'll keep me humble in 2009
posted by Sarah
Each year, I write up an internal annual report, which discusses company performance in the previous year, looks at trends, and lays out a strategic plan for the following year. Generally, this report looks great in November and December and is completely obsolete by March (at the latest). Nonetheless, I thought I'd share some of the highlights from this year's analysis. I hope you will share your agreement or disagreement in the comments.

No clear leader for DITA
DITA authoring tools are everywhere. Long-time contenders (FrameMaker, Arbortext, and XMetaL [anyone remember SoftMetal or HotMetal??]) are adding DITA feature support. Many help authoring environments are adding DITA import or export. Several companies are developing web-based DITA authoring tools, and In.Vision Research has a DITA authoring plug-in for Microsoft Word.

The tools proliferation is disconcerting. In the olden days (the early 90s!), serious technical publishing was a fairly easy choice among FrameMaker, Interleaf, and maybe Ventura Publisher. Now, some tools are on the desktop, some are in the browser, some reside inside other tools, and life is much more complex.

Will things look different in five years? Certainly. I doubt, however, that we'll be back to half a dozen (or fewer) contenders. Instead, I think DITA output will become a check-off in the same way that HTML output is now.

Reuse analyzers
Both MadCap Software and Author-It have developed reuse analysis software -- Analyzer and XTend, respectively. Most of us are familiar with translation memory tools, which try to match new content to be translated against existing content in the TM database. The reuse analyzers do similar work, but in the source language. As you write, the software compares new content to existing content and recommends matches.

This is such an elegant, obvious idea that I can't believe it's new. But I haven't seen this type of tool in desktop-level software before.

Web 2.0 integration
User-generated content, such as blogs, wikis, and forums (not to mention YouTube), is on a collision course with "professional" content, such as user assistance and documentation created by technical writers. The complaints about the amateurs butting in where they don't belong must be painfully familiar to those who remember the rise of desktop publishing software and the destruction of the vast majority of the professional typesetting business.

Note: I laid out my first magazine in PageMaker. Version 1. What little manual paste-up I did was not very attractive.

Note to young people: The expression "cut and paste" is used because in the olden days, your parents used to use scissors ("cut") and glue ("paste") to move things around on a page layout. And "strippers" didn't always use poles. But I digress...

People who are paid to create technical content need to understand what user-generated content will and will not do. (Shameless plug: I'm doing a session on this topic at WritersUA in Portland, OR, this year.)

Global business
We have our fair share of customers in North America, but an increasing number of our clients are outside North America or have significant operations in multiple locations around the world. The implications for technical communicators are global audiences, global customers (internal and external), and a requirement to work well with people from all over the world.

This is an area where I believe that U.S. communicators face some significant challenges.

Flash
I expect Flash to become the next Next Big Thing. Flash technology enables the creation of interactive applications that run in a browser (or offline with AIR, which is also fascinating). Flash is widely used for games, but for our purposes, its role in e-learning applications is more important.

Traditional classroom training is effective (when you have a good trainer), but it's also expensive and it doesn't scale well -- the more people need training, the more costs rise. And furthermore, if the students are scattered literally all over the world, the costs of assembling them all in one location are astounding. I firmly believe that e-learning is less effective than a great classroom experience (of course, I'm biased since I am an instructor myself), but e-learning has some significant advantages -- like eliminating travel requirements and reducing overall cost.

Flash has almost nothing in common with the current Next Big Thing -- XML. XML is markup, text, human-readable, and geeky. Basic Flash is like Illustrator with an extra dimension (time). Advanced Flash is an application development environment.


So there you have my list of important developments for 2008. Do you agree? Disagree? Have additions?

Labels: analysis, dita, web 2.0

2:07 PM Permalink | |