I don't get pissed off THAT easily. No, just concerned that you will have a lot more email when people start getting the "big yellow screen" on pages that used to work just fine. I haven't done enough with this to care, personally.

But you are putting up the yellow screen, then, right?

Suggestion:

1. Only put up the yellow screen if the source is local-- file:/// not http://

Developers will see it, but it won't break any web page.

2. Make it friendlier:

   Developer alert!

This applet does not include a progress bar. If this page is intended for a web site, please include
the following between the <applet> and </applet> tags:


   <param name="ProgressBar" value="true">

   Otherwise users will have no indication that the applet
   is loading and may be confused or frustrated.

   (This message is appearing because the page is loading
   from your local machine; it will not appear if the page
   is loaded from a website using the http:// protocol.)


Can that be done?

Bob

SourceForge.net wrote:

Bugs item #976336, was opened at 2004-06-20 19:55
Message generated for change (Comment added) made by michaelthoward
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=976336&group_id=23629


Category: Applet
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: progress bar required

Initial Comment:
Please explain the justification for making the
progress bar not just a default but a required aspect
of the coding that "breaks" the installation if not
present. Surely this is going to annoy any
user-developer who has based their pages on earlier
versions of Jmol only to find now that they have to go
back in and change every single page if they are to use
the upgraded applet. This just seems to me to be poor
developer relations. I know Miguel said it would be
required; but now that I've seen it in action, I have
to say that the "big yellow screen" upon rotation is
highly unexpected and rather offensive.


I guess somehow I read "required" as "default" so now I
am suggesting that instead of being required, it be
listed as "default TRUE" with just the option to turn
it off for whatever reason--or just not even allow that
option if you think it is that important. Furthermore,
the reality is that only the one line is required:

<param name="progressbar"   value="true" />

but that is not being related to the user yet.

My suggestion: Just turn it on by default. Don't
require any extra param lines.

Thanks,

Bob Hanson



----------------------------------------------------------------------

Comment By: Miguel (michaelthoward)
Date: 2004-06-21 12:32

Message:
Logged In: YES user_id=608250


Hmmm ... you sound a little pissed off. But then again, I
think I pissed off almost everybody.


Here is the problem:
* I cannot put up the progressbar ... the html page coder
has to do it

* It is very important to give feedback to users

* nobody was using it. People would send me urls and ask me
questions, and I would question wether or not the applet was
loading properly. 30 seconds later I the thing would appear.


* If I questioned whether or not it was going to appear
then certainly most users would question it.


* My initial implementation only put up the error message.
Then I decided that showing the applet as well would let
people know that things were not broken completely. Hence
the flip-flop between the error screen and the molecule.


* We are still in test phase. That means we still have a
little more liberty to introduce radical changes. And it
means that we get feedback about those changes ... like the
feedback that you have submitted.


The better solution is as follows ...

We need to encapsulate the applet parameters into a
javascript function. That way, the javascript function can
hide this stuff from the web page author.


This will serve another purpose as well ... I fear that we
need to start generating different <applet ...> code
depending upon the browser/JVM that the user has installed.
In order to do this, we *must* wrap this up in a relatively
simple library call.



Miguel


----------------------------------------------------------------------

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=976336&group_id=23629


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers



--

-- Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr




------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to