Don’t say I didn’t tell you about this coming up… Clearly IE8 and Silverlight is a triple threat when looking towards adoption of RIA.

From The Register:

TechEd 2008 Bill Gates has announced the next betas of Internet Explorer 8 and Silverlight 2 while outlining plans from Microsoft on development services…

The second beta of Microsoft Silverlight cross-browser media player and development platform will be released by the end of this week under a Go Live license. 

A Go Live license lets developers use pre-release code in real-world applications, but without the safety net of Microsoft support.

The second beta had been promised for the second half of 2008, so it’s… early!

As for Bill Gates’ last day, this YouTube video is pretty good with some great celeb cameos.

FWIW, GoLive is pretty cool. I’ve been working on a review for some time updating us on Silverlight and GoLive. With all the hubbub going on for me we’ll see how that looks for later this week.

Related Articles:

Rich Internet Applications War Is Brewing

Adobe FLEX vs Microsoft Silverlight Part 1

More about Silverlight - Microsoft’s Flex / Flash Competitor

How to convert 60 million users to Silverlight quickly

My LMS / eLearning Disruptive Technology Concept

Halo 3, XBox and Technical Communication? (Part 5)

Microsoft Releases Silverlight, Extends Support to Linux

CharlesJeter.com Category: Rich Internet Applications

Great roundup of Rich Internet Application authoring technologies from Emerging Technologies - Application Development - RIA War Is Brewing

There’s a war brewing on the Web today–a war to decide how Web applications and content will be developed and how users will consume the content of the future Web.

But this isn’t the latest round in the browser wars. No, the war I’m talking about is over the RIA (rich Internet application), a type of Web application that can run independently of browsers, can run on any operating system and, in many ways, works like a traditional desktop application.

Of course, RIAs aren’t new. They can be traced back to earlier efforts such as Macromedia’s Shockwave, Java applets and the ubiquitous Flash format.

Analysis of RIA and Wireless Data

When I was in the wireless data game, one of the main questions that people were trying to answer back in 2000 and 2001 was, how do we earn revenue streams from the broadband wireless market we’re about to implement?

The hierarchy for web and internet usage at the time was:

1) email

2) search

Since email and search were text-based, attracting rich internet users across the bandwidth was difficult to make a business case for.

As Yoram Baltinester, NVTL’s Business Development guru stated in a meeting back then, people look towards their desktops for the rich experience for a lot of reasons. They didn’t look at their mobile devices for the same rich content, primarily due to battery life and the form factor of the screen size.

As the Apple iPhone has demonstrated, there’s a good platform for display. Slingbox and other content middleware distribution hardware shows that there’s a need for content to be pushed out.

RIA Content Delivery

What’s known as a Content Delivery Network (CDN) plays a part in this as well.

One blogpost, Full-length shows, even movies, growing on cellular challenges the validity of providing multiple content for multiple viewing platforms:

The question I have is, are we ready to take it to this level? It doesn’t change what’s required much on the CDN side. In fact, it probably increases our capacity since we’re dealing with smaller files of lower resolution. Now we have to maintain separate environments though for HD and mobile.

So this is a valid point. Are we ready? I think the overall answer remains can profit be made on this? Here we are eight years later, and it’s not really a significant portion of the market. You’re stuck with obtaining either rich, HD-ready content or low-resolution mobile deliverable content.

The cellular carriers have now developed the bandwidth, but everyone’s not so sold on the money to be made. And the bandwidth is sketchy at best for full capacity voice and data. I could care less what the marketing people say, there’s a point of saturation that nobody likes to talk about, where you’re not going to be able to keep a call because there’s too many bits dropping off.

That means wireless data is scalable only to a certain point. Let’s face it, providers don’t make more money putting up more towers. They make more money by cutting operating costs. Whether it’s in powering down the towers during offpeak hours or through chopping bandwidth hogs who have all you can eat accounts (like yours truly) they have to save time and bandwidth on the digital phone networks. Who gets priority reads like a conspiracy theory since that’s a tightly guarded secret.

XBox Live customers can download HD content relatively easily from their home network, but it’s currently trapped in the device.

Analysis of RIA and Technical Communication

TechComm is not always tailored for instruction, however breaking down the modules of a device or software program can make instructional content which could be repurposed.

I would think that dropping in a spinning 3D picture of a component might help identify it conceptually, however the time and expense of placing that picture in from scratch is prohibitive. 

eLearning - tremendous advantages with a native RIA developed application. Here are a couple related articles, mainly about the Silverlight entry into RIA:

How to convert 60 million users to Silverlight quickly

My LMS / eLearning Disruptive Technology Concept

Halo 3, XBox and Technical Communication? (Part 5)

Microsoft Releases Silverlight, Extends Support to Linux

Technical Writing - Adobe has added Acrobat 3D to their Technical Communication Suite for a reason; a picture is worth a thousand words, as long as the picture is understood well enough.

However, it’s not been enough to impress industry power users: Adobe’s Technical Communication Suite Panned By TechComm Bloggers 

I’m still searching for where exactly RIA will fit within the future of Technical Communication. Adobe’s had some product evangelists segue into Technical Communication being rich media, less written word, more universally understood documentation.

I’m not so sure I’m buying that though.

Are we really going to want our instructions in podcast or YouTube format?

From what I recall from the 1990s and NT, SP3’s the charm it seems… From Foul Writers World | Windows XP Service Pack 3 goes GOLD:

Earlier today Microsoft confirmed that the source code has been released to manufacturers for testing and implementation.

It has been almost 4 years in the making, and Microsoft has taken their time to ensure that end users don’t have the same problems as the previous SP.

Testing for the SP has revealed a streamlined and greatly reduced install process. A big improvement on the install process comes in the form that the actual download package is a lot smaller than the previous SP and installation took a measly 15 minutes.

I’ll be checking it out this week. It’s supposed to have some cool security updates.

Continuing from eDMS Roshambo Part 4 | Feedback with the wiki versus the MadPak with Feedback Service.

Wikis clobber eDMS when it comes to collaboration. Wikis are great but getting the end result into a user manual format still requires an external tool.

Rock Paper Scissors (RoShamBo): Wiki vs the MadPak, Analyzer, and Feedback Service

There are strengths to not having a Wiki model introduced right away into a corporation. Dan Ortega mentions corporate policy holding back the anarchy, however it helps considerably when there is a gradual move towards the Wiki model. 

MadCap is halfway through the Wiki model already with just the MadPak. Add to that the Analyzer and Feedback Server/Service’s Web 2.0 features, you’ve got yourself a good step past Wiki as far as maintaining positive control over the content.

With Analyzer you’re looking at a Documentation Manager’s dream package.

I think the key element is… how much time would this all save each role a Technical Communicator has. Let alone the workflow’s editing search and correction time.

Cost - $1200 for the MadPak and $400/quarter for the Feedback Service ($1600/year) so you don’t even need to host a server and stress the IIS configuration. No pricing on Analyzer is yet available. I really should get some sort of Amazon Buy-now button for this stuff.

As far as the industry tools are currently set, MadCap Analyzer could save upwards of $50k - $80k a year in tech writer time and other software. That’s pretty hefty, although at the time I’m writing this MadCap hasn’t set a price for the Analyzer.

Note: Pricing for Analyzer is pretty cheap, as I edit this article I find that it’s only about $200 or so to upgrade.

Adobe is never going to live down the naming convention issue with RoboHelp. Maybe after they pass the new/old RoboHelp 9… I think of the naming SNAFU  like the Sierra Club thinks about a spotted owl. You know, the indicator species for an entire ecosystem.

If Adobe couldn’t get the name right, how much could they have cared for the entire ecosystem?

As for the reason that RoboHelp’s naming convention became a SNAFU, I’m just as much on the outside of that as the rest of you are. There has never been an official reason given by an Adobe employee.

So it comes down to Occam’s Razor between two theories. First, the Emperor’s new clothes weren’t worth someone losing their job over or second, the Product Manager didn’t see fit to ask.

From one poor soul on the HATT:

I was looking in Amazon.com for a book on RoboHelp 7. They listed a used copy of RoboHelp 7 for Dummies from the year 1999. Is this an error?

Rick Stone answered. I responded, not without a little tongue in cheek and a link to the RoboHelp Dead-again post. Please understand that I totally dig Rick Stone’s RoboHelp experience and his site is the best resource for RH users anywhere. He asked me to change the subject and talk about my time with eHelp…

I believe you used to be an official eHelp employee at one point didn’t you? Seems I recall you worked in the support center. Why was it you left?

Of course you can read that here on my About page… The rest of the conversation is on the HATT list…

Rick why not ask RJ Jacquez why he never brought up the name change; he’s been with eHelp, MACR, MadCap, and ADBE plus he is the RoboHelp Product Evangelist. If anyone should have been in the loop it should have been him.

Maybe he was working for MadCap at the time and wasn’t around. You know, before he went back to Adobe.

Updating Any Content Effectively Requires Feedback Data

Wiki strength is that anyone can provide feedback or edit content. The passive feedback of viewed pages falls under another product’s reporting (AWStats or WebTrends to name a couple).

Let’s examine the potential benefits that usage statistics and feedback could make to eDMS and/or wiki content. The two we’ll look at are Adobe RoboServer and MadCap’s Feedback Server.

Both provide feedback about page usage and search terms. This allows content creators and technical writers to evaluate which areas to focus their attention on, sort of like a triage, but MadCap’s goes a step or two farther and adds a Web 2.0 aspect with the addition of Comments pages within the web interface.

Understanding the origins of the RoboServer and Feedback Server comes in handy when comparing their technologies.

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.

eContent Magazine reports the shifting change in the Help Authoring Tool / content authoring market:

In 18 months, use of Flare has grown to 25% of the content authoring market, according to the 2007 WritersUA Skills and Technologies Survey, while usage of RoboHelp declined from 63% in November 2006 to 56% a year later. The company [MadCap] reports being profitable since its first month shipping the Flare product.

There are some graphs from the 2007 WritersUA conference which confirm this. Mike Hamilton and I discussed their growth in the December Podcast as well.

Sustainability? Innovation!

We’ve discussed their Web 2.0 Tech Support as a major competitive edge. Now they have the office space to expand, they have the budget to expand… What’s going to be next?

I’ve seen the new announcement for an upcoming workflow process that looks like it encompasses even more than Blaze by itself.

If MadCap is profitable now and still launching new products by the crateload does that itself qualify as a competitive edge?

I think that MadCap’s core focus on software development rather than expanding cubicles and their tight control of middle management has been key to the past two years of success. There’s one competitive edge.

Anthony Olivier, CEO, at one time was the eHelp CFO prior to his eHelp CEO position. He knows how to flip a dime about four times. The relocation to the 7777 Fay office was a coup as well; I’ve never heard of someone being able to MAKE money on an office move.

Where do you see the tipping point coming? Or will Adobe (NASD: ADBE) reverse the defections and keep selling its product in increasing volume?

After all, according to Vivek Jain, TCS Group Product Manager, Quality IS Innovation. :p

Here’s a small but simple tip to speed up your workflow for those who must capture custom window sizes without the browser address bar.

From Microsoft Windows | Customizing the Links bar

To enable the Links bar in Windows XP SP2 and Windows Vista

Right-click on the Windows Taskbar. Click on Toolbars, and then click Links to select it (a checkmark will be displayed beside it)

You will now see “Links” added just to the left of the system tray on the taskbar.

My addition to this is to hyperlink all your working windows within this small box, then just page through them capturing the screens you need. I found it worked well when reviewing a process with the SME.

Hope this helps reduce some time readjusting windows and pasting addresses into screen capture target browser windows.

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 »