Skip to main content

Feedback on new applet plugin

52 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

I've tried the plugin a few times over the past couple months and wanted to follow up on some unresolved issues now that we're approaching the final release.

1) Is this issue scheduled for resolution? http://forums.java.net/jive/thread.jspa?threadID=39519

2) Are there plans to replace the orange "applet loading" animation with behavior similar to Flash so that pages that contain applets do not distract users while they load? I believe there was an earlier post that made the point that "this isn't the place or time to advertise Java" and I tend to agree. I believe end-users don't want to be spammed with this ad. I appreciate the fact you want to inform developers that Java is being used but I believe this is better accomplished by publishing usage statistics for client-side Java. Sun should publish regular updates that show what percentage of end-users have Java installed and what percentage has what JRE version. I believe this would go a long way towards increasing client-side Java usage.

3) Are there plans to do away with the tray-icon when the plugin loads? I made the point in an earlier post that if your target audience are non-developers then this icon brings them no value (instead it degrades the UI)

4) Are there plans to improve the error message users get when an applet fails to load for some reason? I believe the current message is targeting developers while again I'm concerned about non-developer end-users. Maybe you should have a layman error message with an "advanced" tab to get a stack-trace.

5) Are sufficient number of people using the new plugin on a daily basis? I've only recently upgraded to FireFox3 myself and I consider myself to be an early adopted for most technologies. My concern is that only a handful of real developers will try the plugin ahead of the final release and as a result they will discover a lot of problem after the fact.

Technically-speaking, I am very happy with the new plugin but I believe there is a lot of outstanding UI work that should be taken (just as) seriously when considering a final release. In my view, client-side Java requires Sun to apply a very strong effort to improve the UI of the applet plugin, Webstart and JRE integration into the desktop. I haven't noticed much work being done in this area (again, from a UI point of view, not a technical point of view).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24

kbr,

Would it be possible to rename the parameter name to "center_image" or "CenterImage"? I imagine it's not easy for non-English readers to figure out how "boxborder" and "centerimage" segment.

demonduck
Offline
Joined: 2008-03-14

> kbr,
>
> Would it be possible to rename the parameter name to
> "center_image" or "CenterImage"? I imagine it's not
> easy for non-English readers to figure out how
> "boxborder" and "centerimage" segment.

Applet parameters are retrieved by the applet transformed to all lower case -- I think.

I always do a compareIgnoreCase comparison on them anyway.

In other words, you can write CeNtErImAgE if you really want to and the applet will still get centerimage as the parameter....

cowwoc
Offline
Joined: 2003-08-24

> Applet parameters are retrieved by the applet
> transformed to all lower case -- I think.

So is "center_image" and "box_border" possible instead of "centerimage" and "boxborder"?

Gili

demonduck
Offline
Joined: 2008-03-14

> > Applet parameters are retrieved by the applet
> > transformed to all lower case -- I think.
>
> So is "center_image" and "box_border" possible
> instead of "centerimage" and "boxborder"?
>
> Gili

I don't think so...

cowwoc
Offline
Joined: 2003-08-24

> > > Applet parameters are retrieved by the applet
> > > transformed to all lower case -- I think.
> >
> > So is "center_image" and "box_border" possible
> > instead of "centerimage" and "boxborder"?
> >
> > Gili
>
> I don't think so...

I didn't mean technically speaking if I enter "center_image" will it get translated into "centerimage". I meant I was asking kbr whether Sun can rename these parameters before shipping update 10 out the door.

Gili

kbr
Offline
Joined: 2003-06-16

Sorry, but the names were chosen for consistency with the preexisting image, boxbgcolor, and other attributes.

http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/special...

davester
Offline
Joined: 2007-01-26

No kidding, that's what URLConnection.setUseCaches(true) does?! That is a neat trick, I had no idea my cache abuse could extend to runtime as well. I learn something new every day.

Thanks for the explanation.

Cheers,
Dave Woldrich
http://CardMeeting.com

davester
Offline
Joined: 2007-01-26

> So I shouldn't have a 30k applet because someone
> wants
> a word processor embedded in a web page?
>
> I don't have a clue as to what you are asking for...

Sorry you thought my comment was flame bait. It wasn't. I wasn't asking for anything, just commenting.

> The Java cache is enabled by default. Once a
> panorama
> is downloaded, it stays in the cache until it is
> manually cleared
> from the cache. No download time the second time.

Ok, wait a sec, now I'm curious. How are you caching your panorama image asset? Is your panorama downloaded in a jar as part of your applet tag? I haven't been able to pull up your applet yet, so I can't answer my own question.

demonduck
Offline
Joined: 2008-03-14

Sorry about my website. I use BlueHost for hosting and it's been down all day. Don't know why. It has been up for the last year.

The panoramic images I show in my applet are not in the jar. That way I can show many different panoramas with the same invocation of the applet. I usually do that with a click on a thumbnail image. But FF has a problem with LiveConnect (JavaScript) that sort of screws this up.

About the Java cache. The Java JRE uses a cache that is different from the browser cache. Look in the Java control panel and under the General tab you will see Temporary Internet Files -> Settings and you will also see the location next to the Change button.

Jars and things that are down loaded like images are kept there.

In the applet code, you can turn caching on or off. It's on by default. Here's a snippet:

URLConnection urlConnection = imageURL.openConnection();
//urlConnection.setConnectTimeout(8000);
if(canvas != null)
{
canvas.paintCachingIndicator("Loading.", FIRSTIMAGELOADED);
}
if(cache)
urlConnection.setUseCaches(true);
else
urlConnection.setUseCaches(false);
//urlConnection.setReadTimeout(8000);
size = urlConnection.getContentLength();

In addition, I cache some data and information that allows the user to page flip the browser and come back to the applet and find in in the same state as he left it even though most browsers will issue a call to the destroy() method on page flip.

I store this data in a static variable because the JVM is alive until the browser session is ended.

Sounds more complicated than it is. The Java cache is a real nice thing to know about.

cowwoc
Offline
Joined: 2003-08-24

Your website is back up so I did some timings.

The first time I hit the page (nothing is cached) the applets takes two seconds to download and begin running. I then see "Loading" for another 8 seconds and then the picture comes up. So your total load-time is 10 seconds.

The second time I hit the page (after a browser restart) your applet and its photo was cached. This time took two seconds for the applet *and* the photo to load up. Much nicer, to be sure.

The third time I hit different pages containing your applet *without* a browser restart, it starts running instantaneously. The images still download for a while but your applet is up and running right away.

In the first two cases, the two seconds really bugged me. My personal pet peeve is that I expect responsiveness to within 300ms. When the website is fully loaded except for a big black rectangle that just sits there for two seconds it feels really awful.

Why is there a two second delay between scenario 2 and 3? Why does restarting the browser incur this extra delay the first time the applet is hit? Can someone from Sun comment on this?

demonduck
Offline
Joined: 2008-03-14

> If your Applet.start() method has been called, then
> the job of keeping the user entertained, erm, I mean,
> abreast of progress, is your responsibility.
>

I think that this discussion is giving way to much attention to
a less than 30 second interval. I don't see the need to keep
people "entertained" In fact all the glitz and fluff that Flash programmers
seem to think important is only irritating to me.

But I guess some people need glitter on their ipods...

> The chance of having a business case that only
> requires 30K for an applet jar sounds increasingly
> rare to me, especially when we talk about thrusting
> Java into scenarios that Flash currently works well

So I shouldn't have a 30k applet because someone wants
a word processor embedded in a web page?

I don't have a clue as to what you are asking for...

> in. For example, web games, or vector graphics
> cartoons. In both of those cases, Flash as a
> technology is super helpful because it makes it
> trivial for the developer to throw up a splash screen
> that shows download progress for all of the code
> [b]and[/b] assets the code needs. This would be
> equivalent to being able to splash both the second
> and third start phases that my applet goes through.
>
> You know, in your panoramic view case, it might be
> interesting to dynamically jar up your teensy applet
> with the assets and then dynamically write your
> tag such that some jsp or other server side
> technology can build that all-in-one jar. If you do
> this, you'll get some performance bennies when users
> call up a panorama they've already seen - it'll
> already be available in their applet cache. I love
> abusing caches. :) :) :)

The Java cache is enabled by default. Once a panorama
is downloaded, it stays in the cache until it is manually cleared
from the cache. No download time the second time.

And I also cache information necessary to restart the applet
on page turns.

Seems like this discussion is going no where fast so I'm out...

mthornton
Offline
Joined: 2003-06-10

> a less than 30 second interval. I don't see the need
> to keep
> people "entertained" In fact all the glitz and fluff
> that Flash programmers
> seem to think important is only irritating to me.

It often irritates me too, but I suspect I am in a small minority of users.

davester
Offline
Joined: 2007-01-26

> Detailed breakdown of applet loading???
>
> There's nothing to break down. Standard applet tag.
> 30kb applet. Load speed depends on computer and
> internet connection speed. What takes time is
> downloading a panoramic image which generally are
> over .5meg some as large as 2meg.

If your Applet.start() method has been called, then the job of keeping the user entertained, erm, I mean, abreast of progress, is your responsibility.

The chance of having a business case that only requires 30K for an applet jar sounds increasingly rare to me, especially when we talk about thrusting Java into scenarios that Flash currently works well in. For example, web games, or vector graphics cartoons. In both of those cases, Flash as a technology is super helpful because it makes it trivial for the developer to throw up a splash screen that shows download progress for all of the code [b]and[/b] assets the code needs. This would be equivalent to being able to splash both the second and third start phases that my applet goes through.

You know, in your panoramic view case, it might be interesting to dynamically jar up your teensy applet with the assets and then dynamically write your tag such that some jsp or other server side technology can build that all-in-one jar. If you do this, you'll get some performance bennies when users call up a panorama they've already seen - it'll already be available in their applet cache. I love abusing caches. :) :) :)

Cheers,
Dave Woldrich
http://CardMeeting.com

cowwoc
Offline
Joined: 2003-08-24

> You know, in your panoramic view case, it might be
> interesting to dynamically jar up your teensy applet
> with the assets and then dynamically write your
> tag such that some jsp or other server side
> technology can build that all-in-one jar. If you do
> this, you'll get some performance bennies when users
> call up a panorama they've already seen - it'll
> already be available in their applet cache. I love
> abusing caches. :) :) :)

This is precisely why I asked for a breakdown of the applet delay time. I am not convinced that having one JAR instead of multiple ones would necessarily produce a noticeable time savings. It will, however, require a noticeable engineering effort and make packaging more difficult (especially if you have optional components).

Let's profile first, decide what to do second.

BTW: As a test of your proposal try downloading a single 1MB file versus a 10k file followed by a 990k file. Time this using a high-precision timer and report the difference. I suspect the difference will be under 50ms (especially if HTTP pipelining is enabled)

demonduck
Offline
Joined: 2008-03-14

I think that this focus on "...keeping the user entertained while the applet loads ..." is backward thinking and certainly not KISS.

My applets to display 360 panoramas are less than 35kb. And you want to load something that is 4-5kb to entertain while the applet loads. My applet loads in milliseconds. It's the data for the applet -- the image -- that takes time. And the applet is already loaded by then so I keep the user informed as to the progress loading the image.

And this concern is dial up thinking. Think ahead 3-5 years. Applet load times even for a megabyte applet (!!!!! WHAT ???) will be less than a second.

The most important issues are interface issues -- not load time issues confused as UI issues.

cowwoc
Offline
Joined: 2003-08-24

Guys,

It sounds to me like there are certain things we all agree on and other things we do not. So let's first all work to identify where the delay is coming for and only *then* decide on what we want to do about it :)

demonduck, can you please provide us with a more detailed breakdown of your applet loading time as others have done above?

If an applet loads in 3 seconds I would suggest one way of fixing it. If it loads in 30 seconds I would suggest another.

If the load time is 3 seconds I would suggest something as simple as taking a screenshot of your application's initial screen, plaster "loading" on top of it, then use that as your splash-screen GIF. When the applet finishes loading, the "loading" will appear to go away but the rest of the screen will remain. You can even omit "loading" from your GIF. By the time the user moves the mouse over to click on it it will have been fully loaded.

If the load time is 30 seconds I would advocate the two-phase loading scheme I outlined above using download="background".

I think the entire sandbox discussion might be best left out at this time because clearly different people hold different views and it's not the primary problem we are trying to solve here.

demonduck
Offline
Joined: 2008-03-14

Detailed breakdown of applet loading???

There's nothing to break down. Standard applet tag. 30kb applet. Load speed depends on computer and internet connection speed. What takes time is downloading a panoramic image which generally are over .5meg some as large as 2meg.

http://pancyl.com/

Try it yourself.

cowwoc
Offline
Joined: 2003-08-24

The page seems to be down now (for me at least) so I'll try it again in a bit.

demonduck
Offline
Joined: 2008-03-14

Yup, it's down. First time that's happened since I got my web site.

Oh well...

mbien
Offline
Joined: 2007-04-29

> On the other end of the spectrum from the unsigned
> applet is this new JNLPAppletLauncher. That thing is
> a total evil dead horror show because it allows
> developers to load DLL's with their applet jars. It
> turns Java into ActiveX! Sorry kbr, I know you are
> in love with the idea of JOGL loading up in the
> browser, but loading native code directly from the
> web into a running browser is just WRONG! I don't
> care how much signing and trusting and certifying you
> do, this is somehow going to turn the Java Plugin
> into a vector for virus writers and malware. JOGL
> isn't worth my trust in Java getting exploited.

I really don't understand your concern. Native lib loading in applets has always been possible (JNLPAppletLauncher is just a utility) and is used in many aps/apis not just JOGL (see the counterpart LWJGL). When you are able to convince the user to trust _unsigned_ applets than this will be always a open door for viruses (and jogl/lwjgl jars are signed). But this is the case for any kind of untrusted binary (like .exe). You ignore the security warning in your own risk.

nothing changed since JOGL or the JNLPAppletLauncher

davester
Offline
Joined: 2007-01-26

Hmm, you're right. A signed applet that users trust can be made to do anything.

I guess I was a little shocked by how easy JNLPAppletLauncher made it to load .dll's/.so's for multiple platforms. It's like a cross-platform malware factory in the making. :(

davester
Offline
Joined: 2007-01-26

> How do you test this? Here is what I did:

I did my tests on XP, not Vista, so no Superfetch to worry about here, and I do my cold boot tests by flushing the Applet cache using the Java Control Panel. Then, I launch a new FF3 browser instance after everything settles down after boot and hit my applet. I suspect my computer is in a class similar to your older computer, which probably explains much of the 8 second upper bound I see (My disk is a sluggy laptop HD.)

The applets were on my local network, so network latency should not be a factor in my times.

> I don't think these times matter for two reasons:
>
> 1) JQS will be enabled by default
> 2) Flash hard drives are making gains in the
> marketplace

I don't design for future Java's, I design for legacy ones, so I have to worry about user experience on old-school VM's. Plugin2 allows my old school code to keep more in memory and turn on more whirligigs.

> This leads me to conclude that:
>
> - FireFox3 is downloading the JAR file, not the
> plugin.
> - The first time FireFox3 hits the website to check
> whether the JAR file has been changed. The second
> time I uses its cache without checking.

I suspect the browser might do the fetching for the plugin since Java Applets run in a sandbox and there's a contract that the plugin and the browser agree to with regards to security.

What I was getting at when I gave you my times was to convey that there are three distinct startup periods that my (and I suspect many other) applets progress through. The first two, plugin startup and time to Applet.start() getting called, really need the Flash treatment. Plugin startup and VM launch are getting the optimized on many fronts. And in the time to Applet.start() getting called something like a mini applet, or a JavaFX animation, or a Flash animation needs to run that gives the user something to look at while the main Applet jar loads.

Beyond those two startup periods, it's really the applet developer's job to keep the user occupied while additional data is downloaded since at that point we're past the splash screen.

> Another thing I noticed is that the plugin tray icon
> displays almost immediately after the JPG renders,
> but the applet renders a second later. This leads me
> to believe that the JRE is fully loaded and we're
> waiting on *something* for the remaining second.

I think what you're seeing is the huge "ka-CHONK" of the JRE loading up a big swath of its rt.jar to give us stuff like Swing and java.net. That's a spicy meatball. :)

> I suspect that if the 4k JPG loads instantaneously we
> should be able to do the same thing for a cached
> applet. I look forward to your feedback.

Java is huge, there's a lotta .dll and .class stuff that has to get link-loaded before the applet fires up. Not sure what can be done about it, but the scientists at Sun seem hellbent on quashing the "Java is slow" meme. I think they will ultimately prevail, and not just because hardware gets faster.

Cheers,
Dave Woldrich
http://CardMeeting.com

mthornton
Offline
Joined: 2003-06-10

No, I'm just extrapolating from the merging of WebStart and Applet functionality. WebStart has the javax.jnlp.DownloadService which allows you to test for the presence of 'optional' components. You can also request their download and monitor progress.

cowwoc
Offline
Joined: 2003-08-24

kbr,

Thank you for the detailed response. I appreciate your point that the community needs to show its interest by filing RFEs and voting for them. I will try doing exactly that in the coming days.

I believe I might have found a bug just now, but I'm not sure whether the problem lies in FireFox3 or the new plugin engine.

1) Go to http://java.sun.com/applets/jdk/1.4/demo/applets/DitherTest/example1.html
2) Hit the back button
3) Hit the forward button
4) Applet does not render (page is empty). I am expecting steps 1 and 3 to display the same page.

Gili

kbr
Offline
Joined: 2003-06-16

I can not reproduce this with the current code. Please test with the forthcoming build 23 and if it is reproducible with that build then file a bug.

davester
Offline
Joined: 2007-01-26

Hi cowwoc,

I did some tests to determine what the startup times are for me. I run with Java Quick Starter turned off so I can see what worst case times look like. With nothing loaded after cold boot, I see 4-8 secs to get the plugin/VM started. I think there can be wide gaps in that time because the plugin or the jre is doing applet cache management or is competing with the browser for CPU time or disk I/O or something. After the JRE dll's have been loaded at least once, I see the 1-ish second times you are seeing.

There are two more time periods that affect user experiences in my app though: time for the applet jar to download and get its start() method called, and time for the applet to get all if its resources from the server and make itself available to the user. To get to start(), there appears to be an additional 1-2 seconds. If the applet jar is not yet cached, add another 12 seconds, which is the average download time for my applet jar.

Then, once the applet is started, it takes my app at least 2 seconds to load its resources from the server. This can vary with the current load on the server and network latencies and the size of the CardMeetings, but 2 seconds seems to be the best case for me.

So the best and worst cases I see on my app look something like --

Best: plugin load 1 seconds + start() 2 seconds + app gets data from server 2 seconds = total time ~5 seconds. Takes ~3 seconds before user sees any of my Java code running.

Worst: plugin load 8 seconds + download applet jar 12 seconds + start() 2 seconds + app gets data from server 2 seconds = total time ~24 seconds. Takes ~22 seconds before user sees any of my code running.

Obviously the worst times I see are the WORST WORST because I don't run Java Quick Start. Still, there is some distance to go to get the user experience as great as what Flash has. I'd call Java "seamless" if my 3 seconds lower bound to start() getting called was more like Flash's sub-second start times. Having better splash options or being able to run Java code for a splash would be gravy.

Cheers,
Dave Woldrich
http://CardMeeting.com

cowwoc
Offline
Joined: 2003-08-24

> I did some tests to determine what the startup times
> are for me. I run with Java Quick Starter turned off
> so I can see what worst case times look like. With
> nothing loaded after cold boot, I see 4-8 secs to get
> the plugin/VM started.

How do you test this? Here is what I did:

1) Disable JQS and Superfetch
2) Flushed the browser cache and Java cache (javaws -uninstall)
3) Rebooted the machine, waited for the hard drive to go completely idle
4) Timed how long it took the applet to render from the time I hit http://www.iumsc.indiana.edu/graphics/rotate3dDemo.html

On my new machine (6 months old) that cold boot took ~3 seconds while on my older machine (4 years old) which it used to take 8 seconds when I tried it sometime last year. I no longer have my older machine so I can't recheck the timings.

I don't think these times matter for two reasons:

1) JQS will be enabled by default
2) Flash hard drives are making gains in the marketplace

> Best: plugin load 1 seconds + start() 2 seconds +
> app gets data from server 2 seconds = total time ~5
> seconds. Takes ~3 seconds before user sees any of my
> Java code running.
>
> Worst: plugin load 8 seconds + download applet jar
> 12 seconds + start() 2 seconds + app gets data from
> server 2 seconds = total time ~24 seconds. Takes ~22
> seconds before user sees any of my code running.

That looks really bad. I personally consider anything over a second to be "poor" and anything over three seconds to be "unacceptable". Ideally I'd like to see applets loading in 300ms (this could be just a splash screen while the real thing loads).

Here are some interesting findings:

- Make sure the JAR file cached by FireFox3 and Plugin
\-> The first time I hit the applet it takes 1.5 seconds to load (!!)
\-> The second time I hit the applet (I push CTRL-F5) it loads instantaneously

This leads me to conclude that:

- FireFox3 is downloading the JAR file, not the plugin.
- The first time FireFox3 hits the website to check whether the JAR file has been changed. The second time I uses its cache without checking.

Questions:

1) Why is FireFox doing the downloading instead of the plugin?
2) If the cached JAR file has not expired, couldn't we use it without polling the server first? Yes you might run an out-of-date entry but startup times would be a lot faster. As a bonus you could spawn off a thread to poll the server in the background and update the cache for future invocations.

However I found something else that contradicted my findings. Note that the top-left corner of the page contains http://www.iumsc.indiana.edu/images/iumsc-logo8.jpg (4k) and this loads a lot faster than the applet (whose JAR file is 9k). Why would that be? I would expect the same caching behavior out of FireFox3 for both resources.

Another thing I noticed is that the plugin tray icon displays almost immediately after the JPG renders, but the applet renders a second later. This leads me to believe that the JRE is fully loaded and we're waiting on *something* for the remaining second.

I suspect that if the 4k JPG loads instantaneously we should be able to do the same thing for a cached applet. I look forward to your feedback.

Thanks,
Gili

demonduck
Offline
Joined: 2008-03-14

There's the browser cache and then there's the Java cache. Two different caches accessed by two different programs. I'm sure that jars go into the Java cache along with things that the applet downloads like jpg's. If the applet turns on caching (or is it on by default) then downloaded stuff is cached in the Java cache.

When the browser starts to load the JVM which starts to load an applet the JVM will retrieve and use the jar in the Java cache else it will download a new jar if that jar is missing or the jar on the server is newer.

If the JVM is running then reloading the jar file is very fast else the JVM has to start first.

I believe -- but don't know for sure -- that the JVM uses browser lib's to do downloading so the boundary seems kind of fuzzy to me.

Perhaps we could get a clear and complete explanation of what does what and in what order.

demonduck
Offline
Joined: 2008-03-14

Certainly the Java Dev Group should be proud. But the mature programmer knows that if people don't even notice all the work he/she's done, then he/she's done the best possible design and implementation.

RE: Splash screen.

No splash screen unless the person who deploys the applet sets the (now non-existant) splash parameter to a file on the server. Initial color is the color specified by boxbgcolor.
We can talk about other optional parameters like splash text etc.

If none of those are specified then white. The current orange splash screen is gross and cheap.

carcour
Offline
Joined: 2003-06-18

Just because you want to be able to debug the applet for a few users doesn't mean all of them should suffer from having Java in the tray icon. Java should be as silent as possible. Users do not need to know what they're using is an applet. Imagine if Flash did the same and Silverlight too you would have three different icons in your tray!

davester
Offline
Joined: 2007-01-26

I also vote for the Java systray icon to be [b]disabled[/b] by default in the JRE install, but it can be enabled in the Java control panel. Developers will enable the icon to get access to the console if they need it, and a properly functioning plugin will characterize normal applet loading problems in the browser window proper. I agree that multiple icons in the systray looks insane and shouldn't appear in the plugin2 final release.

Further, I request that the final plugin2 [b]not[/b] show a systray notification bubble on the first run after the JRE install. The Java loading splash serves the purpose of telling the user about Java/Sun. Those XP notification bubbles are WAY too alarming, telling you that you're out of hard disk space and there was a write through error on the disk...

In my opinion, any developer who is telling his users to look at the applet console is acting lazy with System.out.println() and not harnessing the power of Java in the browser to interact with his users. We're addressing applet usability issues now with plugin2, RIGHT? Let's pretend like we care about user experience here, people! :)

Cheers,
Dave Woldrich
http://CardMeeting.com

cowwoc
Offline
Joined: 2003-08-24

Your point seems to be that end-users should be able to open the Debugging Console if developers ask them for information. Fair enough. I simply disagree that the tray-icon is the best way to accomplish that and I assert (as demonduck did) that this use-case is extremely rare for end-users.

Still, I agree that there is value in accomplishing what you're asking for, so let's ask: what does Flash, Silverlight and other similar technologies do? How do their developers debug applications in the field?

Would it be possible to automate the bug reporting process instead of displaying the console? For example, "an error has occured, would you like to send a bug report to the author?" if the user clicks yes the console emails all stack-traces, thread-dumps and other relevant information to the author. The author's email would be provided as some parameter of the tag, or better yet embedded in the applet itself to avoid spam.

I also think there are two separate use-cases here:

1) Developers should be able to debug their application as easily as possible. dutchiedave's parameter idea would solve this by enabling developers to configure the applet to open the Java Console immediately upon launching (I would argue for this instead of just making the tray icon visible).

2) End-users want to be able to send error reports to developers but have no understanding of the Java Console (nor should they). Ideally this process should be as automated and non-intrusive as possible. The approach I pitched above would only be offered to the end-user if the developer explicitly asks for such reports by providing an email tag.

mikaelgrev
Offline
Joined: 2006-09-27

Regarding 2) .. You are thinking of Power End Users. 90% are just people that don't want to be bothered when surfing the net. They just want it to work and not be in the way. If it does not work, they sure are going to know that it was Java that made it not work, since it is in their face. If it does work, they have no idea why and that is what they want it.

Too many think of "normal users" like "power users". Which is why we see so many crappy user interfaces. Except on Mac. :)

cowwoc
Offline
Joined: 2003-08-24

You're probably right. When users visit a page with a broken link the vast majority of them don't want to know why, they just move on. I would almost suggest the bug report be sent back to the author automatically (silently) but you'd need to check whether there is a security/privacy concern there.

Thinking about it from a different perspective, maybe we shouldn't be reporting bugs at all. If the user was running a desktop application the developer wouldn't get any report if it crashed, unless the user reported it (and the vast majority would not). The more I think about it, the more I agree with your approach: be as non-intrusive as possible and only report bugs back to the author if it doesn't negatively affect the user.

carcour
Offline
Joined: 2003-06-18

The tray icon should go away. I went through the new plugin examples on IE7 with build 24 and I had 2 Java icons in my tray. This is just unacceptable. If we want a compelling user experience for applets the tray should be removed. Imagine having 2-3 applets on a page and then cluttering all your tray with multiple Java icons. Can someone give valid reasons apart from debugging for not removing it.

Carl

cowwoc
Offline
Joined: 2003-08-24

I filed a RFE for hiding the tray icon by default: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6694710

Vote for it if you agree.

kbr
Offline
Joined: 2003-06-16

> 1) Is this issue scheduled for resolution?
> http://forums.java.net/jive/thread.jspa?threadID=39519

I don't think this is on our radar at this point. Feel free to file an RFE.

> 2) Are there plans to replace the orange "applet
> loading" animation with behavior similar to Flash so
> that pages that contain applets do not distract users
> while they load? I believe there was an earlier post
> that made the point that "this isn't the place or
> time to advertise Java" and I tend to agree. I
> believe end-users don't want to be spammed with this
> ad. I appreciate the fact you want to inform
> developers that Java is being used but I believe this
> is better accomplished by publishing usage statistics
> for client-side Java. Sun should publish regular
> updates that show what percentage of end-users have
> Java installed and what percentage has what JRE
> version. I believe this would go a long way towards
> increasing client-side Java usage.

This is a topic that has been debated at length on this forum. With the new plug-in and its animated GIF support you can get rid of the orange logo animation. I expect that many developers will want to do so. The decision of whether to get rid of the orange logo animation is not in the hands of the engineering team. With our current workload we do not have the cycles to initiate this discussion within the company. Your best bet would be to file a bug and encourage the community to vote for it.

> 3) Are there plans to do away with the tray-icon when
> the plugin loads? I made the point in an earlier post
> that if your target audience are non-developers then
> this icon brings them no value (instead it degrades
> the UI)

No, this issue is not on our radar. At this point we are concerned solely with robustness and feature completeness. You can feel free to file an RFE, but removing the tray icon is again a decision that is not solely in the hands of the engineering team. Even if it were, I personally would probably not support doing so. (This is configurable in the Java Control Panel, BTW.)

> 4) Are there plans to improve the error message users
> get when an applet fails to load for some reason? I
> believe the current message is targeting developers
> while again I'm concerned about non-developer
> end-users. Maybe you should have a layman error
> message with an "advanced" tab to get a stack-trace.

The current error message ("Error. Click for details...") should basically already be handling this. If you feel it is not then please file a bug or RFE and provide a test case.

> 5) Are sufficient number of people using the new
> plugin on a daily basis? I've only recently upgraded
> to FireFox3 myself and I consider myself to be an
> early adopted for most technologies. My concern is
> that only a handful of real developers will try the
> plugin ahead of the final release and as a result
> they will discover a lot of problem after the fact.

For the past several months we have ramped up testing of the new plug-in both internally at Sun as well as externally. Many partners as well as the general public have tested it and provided feedback. While testing coverage is not as high as it will be when it is distributed via java.com, I believe it is being exercised pretty thoroughly at this point.

> Technically-speaking, I am very happy with the new
> plugin but I believe there is a lot of outstanding UI
> work that should be taken (just as) seriously when
> considering a final release. In my view, client-side
> Java requires Sun to apply a very strong effort to
> improve the UI of the applet plugin, Webstart and JRE
> integration into the desktop. I haven't noticed much
> work being done in this area (again, from a UI point
> of view, not a technical point of view).

I appreciate your feedback. However, at this point we still have some outstanding bugs in areas like the Java/JavaScript bridge that are our top priority, and we are very pressed for time. Beyond the enhancements that have already been made, such as the ability to use animated GIFs in the loading screen, I think UI-related enhancements are going to have to wait for a subsequent update release.

demonduck
Offline
Joined: 2008-03-14

I really like that there is now animated gif support for the applet splash image.

I really hope it is centered automatically or better yet a bounds parameter.

RE: your comment about some things being beyond the control of the dev team.

Company politics are interesting aren't they? Say no more...nudge, nudge, wink wink...

kbr
Offline
Joined: 2003-06-16

> I really hope it is centered automatically or better yet a bounds parameter.

It didn't seem to be a good idea to change the default behavior but you can use

See https://jdk6.dev.java.net/plugin2/#LOADING_SCREEN .

demonduck
Offline
Joined: 2008-03-14

> > I really hope it is centered automatically or
> better yet a bounds parameter.
>
> It didn't seem to be a good idea to change the
> default behavior but you can use
>
>
>
> See https://jdk6.dev.java.net/plugin2/#LOADING_SCREEN
> .

Good enough!!!

davester
Offline
Joined: 2007-01-26

My $0.02 on the orange Java splash is that it needs to stay until the Java plugin/VM achieves imperceptible load times -AND- there is a way for the developer to quickly throw up a fancy mini-applet or loading screen similar to the ones flash animations have.

If you paint all white where the applet goes while it loads, people will think the browser is hung, which is a step backwards. I think the orange animation looks pretty slick, although I'd be happier with it if it were centered in the applet region and handled oblong shaped regions, like the swinglabs iris demo has, better.

Perhaps the final "goto Java.com if you want to learn more about Java" message on the splash is a bit over the top, but I can't really blame Sun for being proud of their unique tech.

Cheers,
Dave Woldrich
http://CardMeeting.com

cowwoc
Offline
Joined: 2003-08-24

Hey Dave,

What does Flash do? They don't have a splash screen. Also, have you tried the new plugin (in Firefox3)? On *my* machine load times are approximately a second, what are they on yours?

Gili

davester
Offline
Joined: 2007-01-26

Hi cowwoc,

I am not a Flash authority by any means, but from what I can tell, the flash format supports the display of content before the entire .swt file has been downloaded. So, what creators do is to setup a very "flash"-y splash screen that requires minimal resources to actually download to the client. This mini-flash intro can load very rapidly relative to the rest of the flash file and gives the user instant feedback on download status, play some loading music, etc. It's actually shocking how big some of those Flash downloads actually are, but the splashes are so sophisticated and flash-y, users don't even bat an eye.

The immediate problem translating this pattern to Java Applet is the VM spin-up time. Assuming that gets fixed, the longer term problem is getting tools into the hands of content creators to make custom splash screens that have a Java-y feel similar to what users can expect to see inside their applications. I think just how close "Java-y" needs to get to "Flash-y" depends on the application. JavaFX is supposed to supply those content creation tools and scripting. I'm looking forward to seeing how much traction Sun gets with that. IMHO, the content creation tools that Adobe has for Flash are so refined, it will be tough to grab mindshare.

Might make more sense effort-wise for Sun to support using Flash animations as Java's loading splash screens. (Just fill the applet region with Flash and then remove it when the applet starts). I think Adobe has been embracing Sun and Java lately, might be nice to return the favor and throw an optional new flashsplash="blahblah.swt" attribute in the tag for plugin2 and send the applet loading status percentage value to some named javascript variable in the dom so that the flash animation can display the loading progress. Then again, having the JavaFX strategy play out will be interesting and healthy for the marketplace, so perhaps I shouldn't even make such a suggestion.

For my CardMeeting application, I went through some nasty JavaScript hell to make an applet jar loading "waiting room". Once I notice the applet has fired up, I show the applet and display my own loading bar for the meeting contents using Swing. Having a Flash animation to unify both of those loading effects into one would be so much better from a user experience standpoint. I don't personally own Flash studio nor have the artistic abilities to make a flash animation, but in the future I hope to have the money to hire artists. So having the ability to show something like a Flash splash during applet loading would really rock for me in a year or two. Of course, I could always make more JavaScript hell for myself and make a Flash splash happen myself without Sun's help, and I think I just might! ;)

@demonduck: I agree that the orange splash isn't very useful from a message standpoint, and that anyone who really cares about their brand and their user's experience will throw something else up in front of the user while the applet is loading. My point with the orange splash is that something must ALWAYS show up during the loading process, there can never be blank screens for seconds at a time. So, in that sense, I think the orange splash is good and necessary as a default until better splash options come along.

It would be nice if Java code could be running to display a custom splash today, but it seems that the entire applet jar must be loaded before applet code can run. Maybe there is a trick I am unaware of here. Again, I think JavaFX will fill that gap.

Cheers,
Dave Woldrich
http://CardMeeting.com

mthornton
Offline
Joined: 2003-06-10

> Hi cowwoc,
>
> I am not a Flash authority by any means, but from
> what I can tell, the flash format supports the
> display of content before the entire .swt file has
> been downloaded. So, what creators do is to setup a
> very "flash"-y splash screen that requires minimal
You could probably do that in Java too. In WebStart you can split you application into several jar files, with all but the first (small) jar file 'optional' (downloaded later). So the application can show what ever you can fit into that first jar file, while the rest of the application is being downloaded.

davester
Offline
Joined: 2007-01-26

Hey mthornton,

Have you actually done this? I knew that feature existed, but I didn't see much utility in it. For example, how do you test whether the optional jars have loaded already or not. There's only one way, to classload from them, and that's got to hang things up pretty badly.

I just don't feel like applets were designed for this kind of progressive loading.

Cheers,
Dave Woldrich
http://CardMeeting.com

cowwoc
Offline
Joined: 2003-08-24

Sounds to me we need two categories of optional JARs:

1) Download on-demand (when undefined class file is requested)
2) Download immediately after the applet begins running (new) similar to Java Kernel

So you'd have:

download="eager" (files required before applet may begin running)
download="lazy" (files downloaded when class file is accessed)
download="background" (files downloaded after applet begins running)

I wish we could rename the existing attributes from "eager" and "lazy" to "required" and "on-demand" but I guess it's too late for that :( Anyway, what do you think of this proposal?

davester
Offline
Joined: 2007-01-26

I don't know all of the issues, but I think the applet sandbox follows the KISS principle. In your

or tags, you setup the codebase for the applet, and that's it. You can't load additional jars other than what's available in the user's system classpath, and I think you wouldn't want to. Here's my funny mindset about the whole thing. I feel like there is a particular beauty to unsigned applets. They've got you in this sandbox ringed with electrified barbed wire. You get good 2D graphics, you get wave out, you even get sockets back to the originating server! Otherwise, the applet sandbox is a complete house of pain. If you're willing to live there in the sandbox and live by the rules, the massive upside is you get to load code without having a security dialog box popup for the user to grant or deny. And it's that Deny Always button is the real deal breaker for me: it blackballs your code on that computer, talk about a negative user experience. And believe me, plenty of dumb users press that hated button on purpose or on accident... On the other end of the spectrum from the unsigned applet is this new JNLPAppletLauncher. That thing is a total evil dead horror show because it allows developers to load DLL's with their applet jars. It turns Java into ActiveX! Sorry kbr, I know you are in love with the idea of JOGL loading up in the browser, but loading native code directly from the web into a running browser is just WRONG! I don't care how much signing and trusting and certifying you do, this is somehow going to turn the Java Plugin into a vector for virus writers and malware. JOGL isn't worth my trust in Java getting exploited. I say, if you want JOGL, then why not start shipping that as a 1st class module with the JRE? Or, even better, distribute it as an extension that can be requested on the tag and that gets downloaded into the JRE from Sun.com by plugin2? In any case, the less native code, the better. Let's write everything in Java. :D Cheers, Dave Woldrich http://CardMeeting.com
mthornton
Offline
Joined: 2003-06-10

> I don't know all of the issues, but I think the
> applet sandbox follows the KISS principle. In your
>

or tags, you setup the codebase for > the applet, and that's it. You can't load additional > jars other than what's available in the user's system > classpath, and I think you wouldn't want to. Except for wanting to entertain the user while the rest of the applet is downloaded. JNLP should provide a way of doing this with a tiny (say 4K) entertain.jar, followed by your 1MB+ jar which contains the real thing.
davester
Offline
Joined: 2007-01-26

I agree, a small applet serving as a foray to a larger applet would be really great.

But I'd prefer that we didn't have to split the resources into two separate jars, or rather, I'd prefer that we had some resource format containing multiple jars that could be streamed and could be read by the plugin progressively.

For example, the plugin opens one socket to the server and starts downloading a big bundle containing our jars. The first 4K arrives, and that gets instantly loaded into the JVM as our entertainment jar. The entertainment applet watches some system property the plugin gives us for the download progress of the larger applet jar, and it displays a fancy ticker for our user to drool over. Once the larger applet is done loading, the entertainment applet shuts down and the real applet start() gets called. In any case, you wanna transmit all your data in one big shot if possible because then you get the PowerBoosts of the world to kick in for your transfers.

An applet that could load up like that would gain all the performance bennies that Flash enjoys when it loads large animations. JavaFX may already have this progressive loading feature, I dunno, I need to download the tools and take a look.

Cheers,
Dave Woldrich
http://CardMeeting.com

andrewherron
Offline
Joined: 2008-04-03

I've seen a few posts on the Java tray icon, and I want to add my vote for keeping it.

The icon is an easy cross-browser method for end users to open the Java console, an absolute necessity when trying to provide customer support. Instead of messing around with a list of ways to open the console based on the browser they're using, we simply tell them to right click the coffee cup in the system tray and open the console that way.

I don't see how a little icon in the tray counts as degrading the UI, sure the little bubble popup is annoying but it only appears once. I doubt most people notice it after that.