Strange project sizes

Hi Matt,

For my own stuff, I use MediaWiki ( http://www.mediawiki.org/wiki/MediaWiki). On a huge scale, it's the software Wikipedia runs on. The 43Folders wiki is a good example of how it might be used for this sort of more specialized application with minimal tweaking; see http://wiki.43folders.com/index.php/Main_Page

I use TWiki ( http://twiki.org/) at work (maintained by others) so yes it works, but it doesn't appear to have the same sort of per-page "discussion" that MediaWiki does. It can definitely be tweaked though; lots of internal "plugins" coded up to link to other resources and databases.

Haven't played with Joomla ( http://www.joomla.org/), so you're in a better position to comment on what it can and can't do "out of the box".

Hope this helps!

Andrew.

Hi matturley,

Have you considered implementing your proposed resource as a wiki instead of as just another forum?

Forums are good for linear, chronological discussions, but not so good at non-linear information management. My experience has been that wikis are better suited for collecting, managing and inter-linking information. Most wikis also allow for page-specific discussions when and where needed, but the emphasis is on wiki-as-resource more than wiki-as-discussion.

Keep the train-of-thought discussions here in this forum, but use a wiki to build up the lists of bugs, feature requests, tutorials, FAQs, etc. Thoughts?

Andrew.

Oh boy, take a day off and so much happens while you're gone!

I'd like to put in a word on behalf of those of us who don't live in areas with a lot of local peer support. Software manufacturer supported forums are an essential source of information for us and anything that might weaken their strength is more discouraging than helpful.

That said, additional Internet-based resources are always welcome, particularly if they specialize in features seldom available on company sites, such as the samples, techniques, and best practices mentioned in this thread. A good example of the value of such sites is the raisingaimee.co.uk site often referenced in these forums (many thanks for that useful reference). Product-based periodic newsletters, such as the one offered on Rick's site, I also find extremely useful. I wouldn't, however, really want to get involved in more than one set of forum communications since the on-going nature of forum exchanges can be time consuming itself ... and I need to keep that time free for copying my Captivate projects into blank ones and reformatting. ;O)

Something mattturley mentioned, however:

*****
Here is a scenario - by collecting feature request lists, I could run a simple query to look for common requests. I'd then publish, say the 25 most common requests, to a public ranking page where members of the community could indicate how useful/critical they feel these features are and comment on them. This list can then be presented to Adobe - with the underlying data so that they know that their user base supports this. This isn’t a single-voice approach. It is a community driven approach.
*****

struck me as a very interesting approach to providing numerical support without duplicating requests. Actually, although the notion of supporting feature requests is interesting and I'd love to see it implemented, I could see it as being even more helpful for bug reports ... if implemented by Adobe itself!

If they asked us to provide a title for our bug report and then provided an automated list of titles (linked to the full report as not all titles can be understood without details) accompanied by a kind of checkbox, it would allow us to not only know which bugs had already been reported and to what extent but to simply check the box to indicate it is a bug we have also encountered and that is of concern to us in our use of the product. It would, of course, require automated verification of the user to be sure we could check only once (hmmm ... it would be nice if when viewing they could provide a grayed-out check in the bugs we had already supported) but I'm pretty sure the effort involved in setting up and maintaining such a list would be a lot less than having someone read through and process countless similar bug reports.

If Adobe took this approach, I truly believe it would be a win/win solution, saving both themselves and ourselves a huge amount of time and frustration.

Gail

Understand and agree, OutOnALimb.

Until we at least see public acknowledgement of the issue (let alone a timeline for the fix) in a Technical Bulletin (at the least), then I'm not going to be comfortable suggesting Captivate v2 as a primary tool if the project is either large or has a very short timeline.

Captivate 2 is in the lead as far as features are concerned, but it's become overly tiresome and expensive to run back and forth through project files applying "workarounds" to keep each one optimized and functional.

We're entering the fifth month since Captivate 2 was released (back in October), and that's plenty of time to get a clue that the user base is seriously hamstrung by the senseless "file bloat" issue.

Hi Rick,

Just a few points. You said:

*****
Ummm, correct me if I'm wrong here, but the sheer volume you are hoping to achieve in order to gain Adobe's ear would mean that you secretly hope droves of users will abandon the Adobe forums in favor of yours, no?
*****
I have no secret motive of stopping people from using this forum. I want to create another group that supports the user community. In fact, I will most certainly point users to this resource and, when collecting information on bugs and feature requests I will direct them to the official form provided by Adobe.

Why would I do this and why is this not duplicative of the efforts Adobe has provided? Simple, really. I want feature requests and bugs PUBLISHED and easily accessible through simple searches. I want people considering using this product to understand it more fully, and I want those who are experiencing the frustrations to have a voice that is PUBLIC and PUBLISHED. That is the key to why I want to do this, and that is how you get even very large corporations to take note and enter into a dialog.

I understand your role as a community expert, and appreciate it greatly. You have helped a lot of users, including me solve some major issues. Let me ask you this - can you query the submissions to the Bug Report/Feature Request form? I'd be greatly surprised if you could, and as far as I know, I can't.

Here is a scenario - by collecting feature request lists, I could run a simple query to look for common requests. I'd then publish, say the 25 most common requests, to a public ranking page where members of the community could indicate how useful/critical they feel these features are and comment on them. This list can then be presented to Adobe - with the underlying data so that they know that their user base supports this. This isn’t a single-voice approach. It is a community driven approach.

I don't want to get hung up on only opening a dialog - while it is a primary factor for my spending the money and time to create the site - it isn't the only reason. I want to also provide a groupware type system that allows for the creation of topical or geographic groups that share many of the same resources but are also able to dive in to the weeds on the issues that concern them. Off the top of my head, groups I would like to see are a Washington D.C. regional group, 508 compliance, LMS specific groups, etc. And I don't want to create all of the groups - I simply want to support them with common resources in a more organic and community driven approach.

As a professional learning consultant, I use Captivate on a near daily basis – in fact I have developed over a quarter of a million dollars in courseware using the tool. I feel it is the strongest product of it's kind. I also feel that it has some major short comings that need to be addressed publicly, rather than through a closed system.

I will continue to build the site, and would love help from others interested in starting geographic or topical groups – or from any Moodle experts out there. If it works out, great - the community of users and hopefully the product will benefit from it in the long run. If it doesn't meet all of my initial hopes for this type of group, it will still be an available resource.

Agreed, Rory - an accurate summary of the usual scenario.

And by the way, Gail -- if your timelines are extremely tight and you plan to use full narration and closed captioning in combination with branching, the file size issues will be greatly magnified. The "workaround" of copying/pasting to a new project file becomes a huge drain on your workflow because, in the process, your branching settings are lost and your closed captions are lost. You'll need to go back through the project and put all of that back - at the risk of introducing mistakes/errors.

If one is a casual user working solo to produce one or two 50-slide projects a week, then the situation is manageable. But it becomes much tougher to maintain order and sanity when teams of developers need to share files and are forced to cope with shuttling 30...50...150MB source files across the Internet -- while producing 2- or 3-dozen such projects per week.

The issue is certainly not a small one, and is magnified exponentially in high-volume production environments.

I agree with Gail on this - please let them know this needs fixed sooner rather than later.

Just a quick comment on your file size reduction. Try a 50 slide propject with a few objects imported in from another Captivate project (no full slide imported just text captions and text entry boxes). Progressively went from approx. 3.6MB to 33.6MB to a whopping 65.5MB.

The problem is, this happened progressively but not consistantly from save to save. It may hover around a particular size for a couple of saves, then suddenly rocket off into the wild blue yonder - I just never can tell until Captivate suddenly takes 10 minutes to save instead of seconds.

Oh, and that whopping 65.5MB file became a 3.68MB file after doing the copy and paste dance.

Rory

You're welcome ... but I feel I should specify that although I'm frustrated with some fairly important bugs that affect my ability to work efficiently and would hope for a bit more transparency from the Adobe team, I'm definitely not knocking Captivate!

Since the last time I worked with demo-creating software goes back almost ten years, I've gotta tell you that I'm really impressed with what Captivate CAN do ... and very well. It's proving to be an important tool for us in providing careful and clear demos for use by our software's clients. As the Adobe bug list team can attest, there's still more I'd like to see it do in terms of making our jobs easier when creating projects and standardizing the look of the output, but the results we are achieving (though sometimes laboriously) are great. Of course, we haven't gone to audio yet, so I might have a whole new set of peeves when we eventually need that. ;O)

As a user group, it is clearly up to us to make our voices heard, however, and I can personally assure everyone who hesitates to log a bug or a suggestion that the process is not really painful (in fact, they force you to keep your pain under 2,000 characters ;o). So everyone get out there and make your needs heard!

Gail

Kudo's for taking the time to expound on the issue, Chovansky -- specifically for defending the rights and interests of business consumers who embraced Captivate (v2) with the assumption that "it's an Adobe product - how bad could it be."

Thank you also for making it easy for the "masses" to petition Adobe via the Bug Report Form for some honest, well-deserved answers regarding an issue that quite literally cripples development teams who use it heavily. Producing good quality, well-compressed content in a rapid development environment does indeed become a "crap shoot" as another poster commented. You can either use the product as intended -- and end up with huge files -- or you can diligently employ complicated, messy, unintuitive workarounds and sacrifice time for the sake of getting reasonably-sized source (.CP) and object (.SWF) files. You can't have your cake and it it too, with Captivate 2.

Thanks Rick,

I've taken that advice numerous times in the few months we've been using Captivate ... they're probably starting to dread seeing my name pop up on their bug/wish lists. ;O)

Well, I've just slightly revised my original post to fit into the size restriction on the bug report and have sent it off!

But since volume apparently counts a lot, come on everybody who is frustrated by this issue and join me in reporting this. To save you time formatting a report, feel free to just copy my own message (Shwon below with the added "This is a problem for me too." statement I've added at the front) and paste it into your own bug report and somebody will just HAVE to notice that it's an issue irritating a LOT of customers!

Gail

Message:
This is a problem for me too:

In an effort to resolve caption-related problems, I created a series of blank projects in which to copy/paste existing projects.

Before I even got to the copy-and-paste stage, however, I noted really strange behaviour with my blank project sizes. At first, I created a project (Step5, and somewhat later Step5_skin for the blank project with the custom skin) ... then I thought to simply "Save As" the blank project to several names as a shortcut rather than creating each from scratch. I also wanted to apply our custom skin to the blank projects before copying and pasting but I forgot to do so for the first "Save As" I did. The following summarizes the results for each blank project file, including their sizes:

Step5 = 125KB, new blank project with current skin, one default slide

Step5a = 235KB, simply a Save As of Step5, with no additions, no changes to the project whatsoever
(110KB increase due to Save As)

Step5a_skin = 241KB, Save As of Step5a after having added our custom skin to the project
(6KB increase due to either skin or Save As)

Step5a_2 = 240KB, reopened Step5 and did another Save As (just exactly as when creating Step5a)
(5KB more than doing the Save As from the original creation of Step5)

Step5x_skin = 125KB, reopened Step5a_skin and did a Save As without changing anything in the project
(reduction of 116KB!)

Step5xx_skin = 240KB, reopened Step5x_skin and did a Save As without changing anything in the project
(increase of 115KB)

Step5xxx_skin = 240KB, kept newly created Step5xx_skin open without changes and did a Save As
(same size as source .cp but the Step5xx_skin .cp file reduced size to 235KB as soon as this new file was saved from it! Then tried creating yet another Save As from this file and the new one created at 240KB while this one then reduced to 236.)

This behaviour is extremely confusing and contributes to the on-going problem of excessive .cp file sizes.