Hi Brian,
thank you very much for the detailed information. Bad to hear that it did not work for you like said.
I tried Skoffer on Windows, Mac and Linux and so far it is only usable on Windows. This makes it unsuitable for user in our lab, which consists mostly of Mac and Linux users. Here are my bugs and notes:
I'm confused over most of your point because I considered all well tested. And since it should be a cross platform solution it was tested on Windows, Mac and Linux with Internet Explorer, Firefox, Safari, Opera, etc. with Sun Java, OpenJDK etc. In the first 24 hours after releasing Skoffer.com and the plugins I have seen more than 100 screencasts by my self and got a lot of mails saying that it works great.
*General issues*
- Special:Version does not work with the extension installed. It's just
blank.
That's weird because I would not expect the few functions in the plugin to cause that. The plugin is installed on MediaWiki based http://www.skoffer.com/Special:Version too, which work. Could you please tell me your MediaWiki's version number?
- I notice in the screencast of Skoffer that you close the
'screen-recorder initiator' popup as it is only used for launching. This should happen automatically. Get rid of as many steps as possible.
I do not close it- I minimize it. The applet runs in this popup, if it's closed the applet closes too. If you want to know what's the popup for you can read the commented code example at http://www.skoffer.com/Php_api_example
- You have to grant Skoffer special java permission to use the /tmp
directory, and the only thing written there is /tmp/cache/http/ api.skoffer.com/v1/{skoffer.jarhttp://api.skoffer.com/v1/%7Bskoffer.jar, skoffer.jar.info}. This looks avoidable and should be avoided if possible.
The Java permissions are needed to be able to take screenshots of the PC screen (Java class "java.awt.Robot"), which is oviously needed. This is not possible with an applet that runs in the normal Java sandbox. The operating system's tmp folder is used to store the recorded video and audio if needed (some PCs dont't have much RAM).
- The general method of inserting the <skoffer> tag into the page does
not work across platforms and browsers. Some other way must be found.
Again, weird, since it was tested with all major browsers. (but this point and the two after the next are caused by the same issue)
- Integration with mediawiki is poor and the interface lacks basic
features, such as the ability to download the movie, or embed it in another site.
The goal was to be able to record and insert screencasts as easy as possible. The plugin was not designed for the tasks you mentioned. It is a basic implementation of the simple Skoffer "API" from http://www.skoffer.com/The_skoffer_api (on this page you can find infos how to embed the screencasts in other sites, if wanted).
- Regarding "This screencast will be available shortly," how long is
"shortly," and how will the user know when it is now available? They have to continue refreshing the page? For how long?
This time should be round about as long as the screencasts lasts. A screencast that's a few seconds short should be ready in seconds.
*Linux - *Ubuntu Inrepid Ibex with Firefox 3.0.4 and Java 1.6.0 - Core 2 duo @ 3GHz w/ 8GB ram
- I get to "Uploading your screencast", it spins for a minute, and then
all evidence of Skoffer goes away. It does not insert anything into the edit box
That's because of the issue below.
- If I leave the 'screen-recorder initiator' popup, after the "Uploading
your screencast" popup goes away, this popup gets redirected to ' mydomain.com/extensions/skoffer/<insert 3-4 random unicode characters>', which is naturally a 404 error. The characters are different every time. bizarre.
The popup 'screen-recorder initiator' is loaded from http://domain.tld/extensions/skoffer/skoffer_insert.php?new When the "skoffer_insert.php" is started without the GET variable "skofferid" it starts the Java applet ( the screen recorder). The Java applet checks from which URL it was started and redirects the user to this address + "&skofferid=<screencast ID> after saving the screencast. Now the "skoffer_insert.php" is loaded with the GET variable "skofferid" (for example http://domain.tld/extensions/skoffer/skoffer_insert.php?new&skofferid=12...) and inserts the ID to the text form (in this example it would insert <skoffer>123456789</skoffer>). This is explained at http://www.skoffer.com/Php_api_example , too, if you are interested.
You said the popup gets a 404 error because it trys to load http://mydomain.com/extensions/skoffer/<insert 3-4 random unicode characters> I'm confused about the 3-4 unicode characters (if it were 32, then it could be the video ID). If you can do more tests with the new information (which I wrote above) it would be great. I guess the the applet is not able to detect on which URL it is loaded and forwards the popup to the wrong URL (like you said: a 404 error)
- If I click 'Finish this screencast' before 'Pause recording' then the
recording timer keeps counting. Small things like this are very confusing to users.
This is not the normal behaviour of the applet. It seems the applet did not run correctly after an exception. Please clear your Java cache, and close all browsers. Please test it only in one instance at once (not in two browsers on the same machine). After an error please restart the browser and clear the browser's and Java's cache. You can see in the Java console if the applet outputs exceptions. The issue with the time shows that there was an exception, which could have caused the issue that the applet was not able to redirect the popup correctly, too.
- There are several windows that show up in my linux taskbar that are
apparantly used to draw the recording interface. Can't these be consolidated into one?
This aesthetic thing will maybe changed in a newer version of the screen recorder, because you are right it's confusing, even it does not impact the screencast recording process per se.
*Mac - *OSX Leopard with Safari 3.1.2 and Java 1.5 - Core 2 duo @ 3GHz w/ 4GB ram
- The <skoffer> tags are only inserted into the textarea if I bring it
into focus with my mouse after telling it to upload the screencast. If I don't click in the edit box, the behavior is just like linux, e.g., it doesn't work at all. - I was never able to get it to insert the <skoffer> tags again after this attempt
- The red line you are supposed to move your mouse over is totally
occluded by the main OSX navigation bar which resides at the top of the screen. I found this feature to be very confusing and suggest it be dropped. I suggest making the only way to stop a recording be to click the finish recording button.
You are right. OSX seems to cover the red line which can be used stop the recording. Thanks. Maybe the red line is moved to the left or right side instead of the top. The ability to stop the recording with the red line instead of a button is considered helpful because the red line is not visible in the resulting screencast. A button to stop the fullscreen recording would be visible during the whole screencast.
Windows - Windows XP with Internet Explorer 8 beta - P4 @ 3GHz w/ 512MB ram
- It appeared to work as advertised, but I don't know how long the "This
screencast will be available shortly" screen will be up. I still haven't seen an actual recorded video.
The "This screencast will be available shorty" message is actually a flv file which is placed at the screencasts URL in the moment where the encoding process starts (that the user knows that the screencasts was send correctly). Maybe your browser doen´t check on a page refresh if the flv video file changed (and displays a cached version).
I think Skoffer is close to being usable, but right now it is a Windows-only app and I don't know anyone who uses Windows. I just tried it on my development Windows machine to check.
I will check. I successfully tested it on Ubuntu and Xubuntu where I added Java support to Firefox with
"sudo apt-get install sun-java5-plugin" or "sudo apt-get install sun-java6-plugin"
Cheers, Brian
Thanks, Stefan