adobe has abandoned authorware users

There, I’ve said it.

IE7 shipped yesterday and among the many changes is one that has caused Authoware Web Player calls to JavaScript in the embedding HTML to fail. (The bug ticket in Microsoft Connect was here). This is a significant issue as e-learning content delivered in the Authorware Web Player is commonly accessed through SCORM Learning Management Systems (LMS), and SCORM requires that content communicate across a JavaScript API.

There does seem to be a workaround which involves loading the page that embeds the Authorware content as either a frame or iframe element. While tests indicate this is a successful workaround, it is a disconcerting one as I haven’t been able to track down why it works. Depending upon various LMS environments it can also be a difficult, or at the very least, time consuming workaround to implement.

This has been a known issue since the early IE7 beta releases and was reported to both Microsoft and Adobe. After a last ditch campaign by members of the AWARE list and some persistent questioning during the October IE7 Expert’s Chat the significance of the problem was brought to the IE7 team’s attention. As I both suspected and feared, Microsoft seemed to indicate that this was a problem that would need to be resolved by the Authorware Web Player.

Where was Adobe through all of this? Good question. As I mentioned, the bug was communicated through official channels sometime ago (May 2006 to be exact) and was also discussed on mailing lists and in forums (on at least one of those lists members have an expectation of monitoring and participation from Adobe representatives). All has resulted in deafening silence.

As things currently stand I have lost confidence in Adobe’s commitment to the Authorware community. Authorware developers, like developers everywhere, are a resourceful and independent lot and have grown used to “fending for themselves” (perhaps more so that other developers) but now Adobe needs to stand up and support them.

Comments (7)

ie activex update

Hello Eolas my old friend.

Microsoft have a new (circa last week) knowledge base article posted that describes some of the Eolas inspired changes to the way IE will handle ActiveX controls. The piece is short on detail, however it seems that this time around they’re planning on a “click to enable” type of functionality.

Of course, spinning through the Five Ws I notice that when gets missed. Seems kind of odd to document a bunch of known issues and avoid talking about a timeline for unleashing ‘em.

Via JD (who mentions that Adobe will likely be making some material available on the topic).

Comments (0)

ie7 links and ugly blog behaviour

Shaun Inman has a big list of IE7 beta links.

Included is a link to the Register piece that seems to have ignited a huge pile of blog belligerence. The important part of this seems to have gotten lost in the squabbling – IE7 beta may or may not cause some browser toolbars (such as the Google Toolbar) to stop working. The IE team plan to work it out and will continue to support the toolbar API.

Comments (2)

the acid2 challenge

Eric Mayer has some interesting thoughts concerning the focus the Acid2 browser challenge has on Internet Explorer over other browsers.

The Acid2 test, issued last week by the CTO of Opera, is a challenge to Microsoft to improve support of CSS2 standards in the upcoming IE7. Apparently, it will be sponsored by the Web Standards Project and will consist of a test page (to be built) that will …”use features Web designers crave, such as fixed positioning of elements“.
That test page will be hosted here:
http://webstandards.org/testsuites/acid2/

Slashdot had its perspective too.

Comments (1)

macromedia yahoo! toolbar offer opt-out toolbar

With tongue in cheek I put together a toolbar button for Internet Explorer that unselects the Yahoo toolbar checkbox on the Flash Player download page. That’s right, it’s a toolbar that helps you to opt-out of the Yahoo! toolbar offer from Macromedia. Call it statement-ware. Basically, it runs a bit of javascript on the page to set the checked state of the “also install” checkbox to false when the IE toolbar button is clicked. Really this provides no added functionality to the page (nor removes any).

What’s the point you ask? There is no point except to make a statement. I’ve followed (and participated in) the Yahoo! toolbar debate that has recently been waged and while I feel encouraged by the way Macromedia have reacted to the developer community feedback I continue to disagree with the offer’s opt-in status. Of course, the absurdity of a toolbar item to deselect an option to install a toolbar is also part of the point. As another explanation I’d suggest that perhaps I have too much time on my hands but that really is far from the truth.

I’ve assembled the files in a zip here. It contains the following:
y_opt_out.ico – the toolbar button’s icon (a rather lame effort…).
y_opt_out.js – the script file that is executed when the toolbar button is clicked.
y_opt_out.reg – a reg file to assist in the toolbar button installation (direct linking a reg file just seemed wrong). Basically it adds a registry key in
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Extensions\
Before merging it you’ll need to edit the directory location for the values it contains to point to the location on your pc where the above files will be located (currently pointing to D:\y_opt_out\).

Here’s a screengrab of the toolbar in IE6:
Yahoo! toolbar opt-out toolbar button

And this is a link to the MSDN docs for Internet Explorer browser extensions:
http://msdn.microsoft.com/workshop/browser/ext/extensions.asp

Comments (2)