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.jar<http://api.skoffer.com/v1/%7Bskoffer.jar…ar>,
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=1…)
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