From: Tamas E. G. <tg...@pu...> - 2005-02-28 15:34:34
|
After the creation of many Chime pages in the past I've made several Jmol test pages - I intend to write some new tutorial pages in organic chemistry and before doing so I wanted to test Jmol. An important point in my eyes is that the use of the pages must be as user friendly as possibe: my experience is that 9 out of 10 people is in a hopeless situation, if instead of normal start-up the system displayes a broken pipe icon, or pops up a message window demanding to download and install something, or simply crashes or freezes. In a classroom environment the situation is far more easier because all of the computers can be set up the same way by an advanced user or system administrator. Nevertheless, when the pages are put to an open web site and are intended for general use between Rio de Janeiro and Stockholm, the situation is more pessimistic. Chime plugin: the user has to download and install it him/herself - but even the simple installment under IE or Netscape is problematic for many of them. In the case of Mozilla/Firefox the npchime.dll file is to be copied manually form the IE plugin folder into that of Firefox - again, problematic for many users. However, if it is done, Chime works quite reliably (apart from a few advanced method under Mozilla, but usually there is a roundabout). Jmol applet: In theory it is beautiful: nothing to be installed by the user, everything is downloaded on-the-fly. In fact, when I tested my test pages and those found in the Jmol site in several PCs around the results gave a very mixed impression. Even the WinXP - IE combination is uncertain: it is known that WinXP SP2 and SP1 (after February 3, 2003) do not contain the Microsoft Java Virtual Machine, so in PCs with a brand new WinXP installment the applet did not work, however, when the WinXP was upgraded from an older version it worked. The applet in Firefox or Mozilla with the 1.4.x Sun java RE never worked (the browser crashed), but after upgrading to java 1.5.0 it worked. Opera with java 1.4.x worked (I haven't too much experiences with the Opera browser, anyway). To summarize, I am in dilemma - which is the better solution? To make everything in double? The presence of Chime is easy to test, and if ok, lets use it. However, the check of the Jmol applet is not so straightforward, as its functionality heavily depends upon the actual JRE. If the browser hangs up (as in the case of JRE 1.4 and Firefox) nothing helps and the user will probably avoid to visit such pages again. Tamas E. Gunda ================== Prof. Tamas E. Gunda University of Debrecen Medical and Health Science Center Dept. of Pharmaceutical Chemistry e-mail: tgunda *.AT.* puma.unideb.hu |
From: timothy d. <mol...@ma...> - 2005-02-28 16:21:15
|
On 2005-02-28 (16:34) Tamas E. Gunda wrote: > >After the creation of many Chime pages in the past I've made several >Jmol test pages - I intend to write some new tutorial pages in >organic chemistry and before doing so I wanted to test Jmol. An >important point in my eyes is that the use of the pages must be as >user friendly as possibe: my experience is that 9 out of 10 people >is in a hopeless situation, if instead of normal start-up the system >displayes a broken pipe icon, or pops up a message window demanding >to download and install something, or simply crashes or freezes. > hi Tamas, I'm not sure here - are you referring to what happens with the Jmol applet,= or Chime, or just in general? >In a classroom environment the situation is far more easier because >all of the computers can be set up the same way by an advanced user >or system administrator. Nevertheless, when the pages are put to an >open web site and are intended for general use between Rio de >Janeiro and Stockholm, the situation is more pessimistic. > again, not sure if you are referring to a specific software package here, s= o it is hard to respond with anything useful. >Chime plugin: the user has to download and install it him/herself - >but even the simple installment under IE or Netscape is problematic >for many of them. In the case of Mozilla/Firefox the npchime.dll >file is to be copied manually form the IE plugin folder into that of >Firefox - again, problematic for many users. However, if it is done, >Chime works quite reliably (apart from a few advanced method under >Mozilla, but usually there is a roundabout). > please let's not forget the vocal minorities out there - Mac and *nix users= =2E Chime does not run in OSX, being practically limited to Netscape 4.x = in OS9. I don't think Chime runs at all in *nix. Chime is no longer being developed by MDL, so what you see now is the best = you will ever see. IOW, it's all downhill from here :-(. >Jmol applet: In theory it is beautiful: nothing to be installed by >the user, everything is downloaded on-the-fly. In fact, when I >tested my test pages and those found in the Jmol site in several PCs >around the results gave a very mixed impression.=20 > can you provide URLs to your test pages? sometimes even a master craftsman= tends to blame his tools... ;-) there is a lot more than just Jmol involv= ed here; let's work out exactly what and where is the problem. also, what = version of Jmol are you using, and in what context? (local or server, Jmol= =2Ejs, etc?) >Even the WinXP - IE combination is uncertain: it is known that WinXP >SP2 and SP1 (after February 3, 2003) do not contain the Microsoft Java >Virtual Machine, so in PCs with a brand new WinXP installment the >applet did not work, however, when the WinXP was upgraded from an >older version it worked. The applet in Firefox or Mozilla with the >1.4.x Sun java RE never worked (the browser crashed), but after >upgrading to java 1.5.0 it worked. Opera with java 1.4.x worked (I >haven't too much experiences with the Opera browser, anyway). > I can not really comment on these specific problems except to say that if y= ou download and install the Sun JVM, your applets (including Jmol) should w= ork. My Dell came with XP and the Sun JVM pre-installed, and I have never = crashed a browser with Jmol on this machine. >To summarize, I am in dilemma - which is the better solution? To >make everything in double? The presence of Chime is easy to test, >and if ok, lets use it. However, the check of the Jmol applet is not >so straightforward, as its functionality heavily depends upon the >actual JRE. If the browser hangs up (as in the case of JRE 1.4 and >Firefox) nothing helps and the user will probably avoid to visit >such pages again. > IMHO, Jmol and Chime represent 'advanced' functionality of the Web. so I w= ould argue against putting a visible, active Jmol on your home page, for ex= ample, until you can run some basic compatibility checks. that should hand= le users with incompatible combinations. then you can explain what your us= er needs to do to use Jmol, provide links to necessary components, and be a= s helpful as possible with troubleshooting problematic installations. this= is the standard way to handle such functionality. it is easy to look at well-established 'browser helpers' like Flash and use= them as a comparison. that is not exactly fair; these packages have been = around for a long time and have a lot of time and $$ invested in developmen= t. it is also easy to expect something like Jmol to work fine out of the b= ox for all users on all browser and platforms, and that is not really fair = either. it is hard enough to account for the systems that *do* want to pla= y nice with Java, to say nothing of certain companies that have decided to = actively undermine Java. and finally, it is easy to overlook that Jmol or = Chime is not the only player here - you also have browsers, JVMs, and opera= ting systems all changing at the same time. personally, I would use Jmol. it is in active development, open-source, an= d supported by dedicated developers and a wide user base, and has a bright = future. it has given me the greatest return on fewer problems so far. "There's too much blood in my caffeine system." |
From: Bob H. <ha...@st...> - 2005-02-28 17:01:49
|
timothy driscoll wrote: > > > so I would argue against putting a visible, active Jmol on your home page, for example >, until you can run some basic compatibility checks. I worry about this on the new Jmol test page. Is that page set up to detect the absense of capability to run the applet? Or does it just look bad when the capability isn't there? Bob -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: timothy d. <mol...@ma...> - 2005-02-28 17:31:36
|
On 2005-02-28 (11:01) Bob Hanson wrote: > > >timothy driscoll wrote: > >> >> >>so I would argue against putting a visible, active Jmol on your >>home=20 >page, for example >>, until you can run some basic compatibility checks. > >I worry about this on the new Jmol test page. Is that page set up to >detect the absense of capability to run the applet? Or does it just >look bad when the capability isn't there? > the capability exists in Jmol.js to test all aspects of the user system (br= owser, system, various functionality). I don't know whether these tests ar= e enabled by default at the Jmol home pages. tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "A debugged program is one for which you have not yet found the conditions = that make it fail." - Jerry Ogdin |
From: Bob H. <ha...@st...> - 2005-02-28 16:56:57
|
Tamas E. Gunda wrote: > > To summarize, I am in dilemma - which is the better solution? To make everything in double? The presence of Chime is easy to test, > and if ok, lets use it. However, the check of the Jmol applet is not so straightforward, as its functionality heavily depends upon > the actual JRE. If the browser hangs up (as in the case of JRE 1.4 and Firefox) nothing helps and the user will probably avoid to > visit such pages again. > I think you will find that everyone on THIS list has concluded that Jmol is the better solution. For those who need to upgrade or install Java, they upgrade. That's better than downloading a plugin, because it's a more general fix and will give their computer more capability in other situations as well. It's a bigger "fix" than just installing the molecular viewer software. HOWEVER, it would be nice -- I'll bet Henry Rzepa knows how to do this -- if when Java is not there they at least get a GIF or something that points them to how to proceed. Would that be <object> code? For example, jmol.js could be modified to detect IE (can it detect whether Java is there? or the right java?) and, if so, display a standard gif from the Jmol website or a link to that page explaining the issue. Bob Hanson -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Frieda S. R. <fr...@ns...> - 2005-02-28 17:03:50
|
On Feb 28, 2005, at 11:56 AM, Bob Hanson wrote: > > HOWEVER, it would be nice -- I'll bet Henry Rzepa knows how to do this > -- if when Java is not there they at least get a GIF or something that > points them to how to proceed. Would that be <object> code? For > example, jmol.js could be modified to detect IE (can it detect whether > Java is there? or the right java?) and, if so, display a standard gif > from the Jmol website or a link to that page explaining the issue. It was my impression that this already happens when one uses jmol.js to invoke an applet. At least it did on our machine running XP SP2, visiting a site I built on my Mac using jmol.js. An explanation appeared, one click to the Sun website, another to download/install, then reload the page with the applet, and it runs. Frieda ************************************* Frieda S. Reichsman, PhD Molecules in Motion Interactive Molecular Structures http://www.MoleculesInMotion.com Shutesbury, MA ************************************* |
From: <rg...@el...> - 2005-02-28 17:08:31
|
On Mon, February 28, 2005 11:56 am, Bob Hanson said: [snip] > > HOWEVER, it would be nice -- I'll bet Henry Rzepa knows how to do this > -- if when Java is not there they at least get a GIF or something that > points them to how to proceed. Would that be <object> code? For example, > jmol.js could be modified to detect IE (can it detect whether Java is > there? or the right java?) and, if so, display a standard gif from the > Jmol website or a link to that page explaining the issue. I wouldn't like to see this as the default behaviour for jmol.js. An explicit determination would be fine when it might be needed but, if you have control over the audience I wouldn't want to slow down the loading/display for something that I know is always going to be correct. Rich |
From: Bob H. <ha...@st...> - 2005-02-28 17:11:28
|
Didn't say it would be default. Could certainly be an option. rg...@el... wrote: > On Mon, February 28, 2005 11:56 am, Bob Hanson said: > [snip] > >>HOWEVER, it would be nice -- I'll bet Henry Rzepa knows how to do this >>-- if when Java is not there they at least get a GIF or something that >>points them to how to proceed. Would that be <object> code? For example, >>jmol.js could be modified to detect IE (can it detect whether Java is >>there? or the right java?) and, if so, display a standard gif from the >>Jmol website or a link to that page explaining the issue. > > > I wouldn't like to see this as the default behaviour for jmol.js. An > explicit determination would be fine when it might be needed but, if you > have control over the audience I wouldn't want to slow down the > loading/display for something that I know is always going to be correct. > > Rich > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: timothy d. <mol...@ma...> - 2005-02-28 17:34:37
|
On 2005-02-28 (11:11) Bob Hanson wrote: >rg...@el... wrote: > >>On Mon, February 28, 2005 11:56 am, Bob Hanson said: [snip] >> >>>HOWEVER, it would be nice -- I'll bet Henry Rzepa knows how to do >>>this -- if when Java is not there they at least get a GIF or >>>something that points them to how to proceed. Would that be <object> >>>code? For example, jmol.js could be modified to detect IE (can it >>>detect whether Java is there? or the right java?) and, if so, >>>display a standard gif from the Jmol website or a link to that page >>>explaining the issue. >> >>I wouldn't like to see this as the default behaviour for jmol.js. An >>explicit determination would be fine when it might be needed but, if >>you have control over the audience I wouldn't want to slow down the >>loading/display for something that I know is always going to be >>correct. >> >>Rich >> >Didn't say it would be default. Could certainly be an option. > if they are working correctly, the compatibility checks should not add any = overhead to Jmol operations as long as the system passes the checks. so I = see no downside to using them, unless I am misunderstanding your comments. regards, tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "I've had a perfectly wonderful evening. But this wasn't it." - Groucho Mar= x |
From: <rg...@el...> - 2005-02-28 17:52:39
|
On Mon, February 28, 2005 12:34 pm, timothy driscoll said: > > if they are working correctly, the compatibility checks should not add any > overhead to Jmol operations as long as the system passes the checks. Maybe not to operations but there would be some overhead to do the checks in the first place. I don't have any experience doing this so I can't say if this would take any noticeable time (assuming a worst-case) over the applet loading itself but, if it does, I would want to be able to opt-out of doing the checks for the environemnt in which I run. Rich |
From: Bob H. <ha...@st...> - 2005-02-28 18:14:18
|
rg...@el... wrote: > On Mon, February 28, 2005 12:34 pm, timothy driscoll said: > > >>if they are working correctly, the compatibility checks should not add any >>overhead to Jmol operations as long as the system passes the checks. > > > Maybe not to operations but there would be some overhead to do the checks > in the first place. I don't have any experience doing this so I can't say > if this would take any noticeable time (assuming a worst-case) over the > applet loading itself but, if it does, I would want to be able to opt-out > of doing the checks for the environemnt in which I run. From my experience, on the order of 5-10 milliseconds, top. Overhead in terms of raw bytes transmitted: almost nothing. Remember, it's once per load. Not a big deal. Bob > > Rich > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: timothy d. <mol...@ma...> - 2005-02-28 18:32:37
|
On 2005-02-28 (12:52) rg...@el... wrote: >On Mon, February 28, 2005 12:34 pm, timothy driscoll said: > >> >>if they are working correctly, the compatibility checks should not >>add any overhead to Jmol operations as long as the system passes the >>checks. > >Maybe not to operations but there would be some overhead to do the >checks in the first place. I don't have any experience doing this so >I can't say if this would take any noticeable time (assuming a >worst-case) over the applet loading itself=20 > hi Rich, there is no noticeable overhead, unless you are checking for the ability of= Jmol to utilize callbacks. >but, if it does, I would want to be able to opt-out of doing the >checks for the environemnt in which I run. > I heartily agree. as a developer, you should always be able to opt out of = this kind of thing, if only to simplify bug-fixing. I believe that the cur= rent Jmol.js *enables* these functions, but does not actually run them by d= efault (i.e., via JmolInit or anything else). so one could write a JmolChe= ck.js file that actually runs the checks - then comment it out when you wan= t to bypass. this should not be difficult IMHO. regards, tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "Who, my friend, can scale heaven?" - Sumer (from Gilgamesh) |
From: timothy d. <mol...@ma...> - 2005-02-28 17:25:23
|
On 2005-02-28 (10:56) Bob Hanson wrote: > >Tamas E. Gunda wrote: > >> >>To summarize, I am in dilemma - which is the better solution? To make >>everything in double? The presence of Chime is easy to test, and if >>ok, lets use it. However, the check of the Jmol applet is not so >>straightforward, as its functionality heavily depends upon the actual >>JRE. If the browser hangs up (as in the case of JRE 1.4 and Firefox) >>nothing helps and the user will probably avoid to visit such pages >>again. >> > >code? For example, jmol.js could be modified to detect IE (can it >detect whether Java is there? or the right java?) and, if so, > it is possible to detect if Java is working (off the top of my head - javaE= nabled? somthing like that). and browser identity is an accessible proper= ty, though easily spoofed by browsers these days. I don't know if you can = query for JVM version, though you can query for required functionality. fo= r example, I use the Jmol messageCallBack to determine if Jmol is loaded an= d can respond at this level. I also use document.getElementById in a like = manner. regards, tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "A debugged program is one for which you have not yet found the conditions = that make it fail." - Jerry Ogdin |
From: Eric M. <em...@mi...> - 2005-02-28 17:53:01
|
Hi, Tamas, I agree with your assessment that there is a dilemma right now (thanks largely to Microsoft having removed java from Windows). However, there is no question in my mind that jmol is the answer for the future, because it is under active development, has open source, and already works better than Chime/RasMol in some areas thanks to Miguel Howard's efforts. Chime in contrast has had no significant development for years, will apparently never be open source, and MDL has announced their intention to phase it out around 2007 in favor of something that may not have a free version. Nevertheless, for 2005, I am continuing to develop Protein Explorer with Chime for several reasons. The main reason is that there is too much code involved to make a quick switch. I do intend to try to implement PE with jmol starting in 2006, but once I start that, it is unclear what big problems I may encounter, and how long there will be an eclipse with no released product. I am also hoping that some of the browser compatibility issues and limitations of jmol will be resolved before I start. In particular, it would be very useful to have the ability to render rolling-probe surfaces at least as well as Chime. Also I hope there will be a standard, well-tested and smooth solution to detecting the absence of java and guiding the user through java installation. For new projects, unless there is a specific need that jmol does not and will not support soon, surely jmol is a safer bet. For upgrading existing Chime-based resources, I have no general recommendation since I have not yet worked with jmol myself and so have no experience to go on. For teaching, I think the best solution for 2005 is to be open minded and to use the best resources available, regardless of whether they use Chime, jmol, or some other underlying technology. Although they will complain, students need to learn how to install Chime and java and how to use Chime and jmol. -Eric /* - - - - - - - - - - - - - - - - - - - - - - - - - - - Protein Explorer - 3D Visualization: http://proteinexplorer.org Workshops: http://www.umass.edu/molvis/workshop Biochem Structure Tutorials http://MolviZ.org World Index of Molecular Visualization Resources: http://molvisindex.org ConSurf - Find Conserved Patches in Proteins: http://consurf.tau.ac.il Atlas of Macromolecules: http://molvis.sdsc.edu/atlas/atlas.htm PDB Lite Macromolecule Finder: http://pdblite.org Molecular Visualization EMail List (molvis-list): http://bioinformatics.org/mailman/listinfo/molvis-list Eric Martz, Professor Emeritus, Dept Microbiology U Mass, Amherst MA US 413-545-2325/FAX 413-545-2532 http://www.umass.edu/molvis/martz - - - - - - - - - - - - - - - - - - - - - - - - - - - */ |
From: Vladimir P. <vla...@we...> - 2005-02-28 19:42:41
|
Eric Martz wrote: >... > I agree with your assessment that there is a dilemma right now (thanks > largely to Microsoft having removed java from Windows). >... Sun Microsystems (which controls Java) sued Microsoft to force the software giant to conform to Sun's Java standard. That Microsoft would then decide to make Java optional in Windows is, well, not surprising :) Regards, Vladimir Potapov |
From: Eric M. <em...@mi...> - 2005-02-28 17:57:35
|
At 2/28/05, Tim Driscoll wrote: >please let's not forget the vocal minorities out there - Mac and *nix >users. Chime does not run in OSX, being practically limited to Netscape >4.x in OS9. I don't think Chime runs at all in *nix. For the record: There is no Chime for native *nix, just as there is none for OSX. However, there are several solutions (of varying costs) to running Chime in a Windows-subsystem, including one that involves no Microsoft code. I have seen these work exceedingly well. The information I had a few years ago is summarized here: http://www.umass.edu/microbio/chime/pe/protexpl/platform.htm ---- Eric Martz, Professor Emeritus, Dept Microbiology University of Massachusetts, Amherst MA US http://www.umass.edu/molvis/martz |
From: William R. <whr...@ms...> - 2005-03-01 15:01:23
|
Hi Tamas, I faced the same problems you raised last year with respect to molecular visualization displays in my virtual text of organic chemistry. After comparing the two displays, I decided to offer the user a choice and at the cost of considerable effort, and with Miguel's help, two versions of the text were made available at: http://www.cem.msu.edu/~reusch/vtxtindex.htm <http://www.cem.msu.edu/%7Ereusch/vtxtindex.htm> Each version has a test page that allows the user to examine the compatibility of his/her system with the viewer as well as with Peter Ertl's molecular editor applet. Because I started this conversion early, I did not use the Jmol.js library, electing to use applet generated buttons exclusively. I believe that Jmol is the superior viewer for all the reasons cited by Eric, and as a Mac user I make use of it. However, I am informed by the supervisors of our servers that our site receives over 90% more hits on the Chime version than on the Jmol version. This undoubtedly reflects the overwhelming dominance of Wintel platforms and the good behavior of Chime with their I.E. browser. Bill > > |
From: timothy d. <mol...@ma...> - 2005-03-01 16:00:52
|
On 2005-03-01 (09:55) William Reusch wrote: ><http://www.cem.msu.edu/~reusch/vtxtindex.htm> > <snip> >I believe that Jmol is the superior viewer for all the reasons cited by=20 >Eric, and as a Mac user I make use of it. However, I am informed by the=20 >supervisors of our servers that our site receives over 90% more hits on=20 >the Chime version than on the Jmol version. This undoubtedly reflects=20 >the overwhelming dominance of Wintel platforms and the good behavior of=20 >Chime with their I.E. browser. > hi Bill, I just added a few ticks to the hit count on your Jmol site ;-). (I run OS= X here.) you have a very nice site! I am interested in the details of your hit statistics. for example, how ma= ny total unique hits do you see? how long do users stay at the Chime site = vs. the Jmol site? are you factoring out repeat hits from the same IP? do= you know the platform breakdown for Chime vs. Jmol? IOW, are most Win use= rs at Chime and most non-Win users at Jmol? just curious; I think it would be very illuminating to be able to track Chi= me vs Jmol use across different sites. regards, tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "There's too much blood in my caffeine system." |
From: William R. <whr...@ms...> - 2005-03-01 18:36:17
|
Hi Tim, You raise some interesting points, and I will try to obtain the information pertaining to them. The data I cited came from a brief (ca. 2 week period) in early January. Repeat hits were not factored out. MSIE was far and away the most used browser, followed by Firefox and Netscape. Safari use was 30% of Netscape. I need to work with our computer techs to improve the kind of information they are collecting. When I have more useful data from a longer time period I will report it. Thanks for your interest. Bill > > |
From: timothy d. <mol...@ma...> - 2005-03-01 19:37:50
|
On 2005-03-01 (13:38) William Reusch wrote: >Hi Tim, >You raise some interesting points, and I will try to obtain the >information pertaining to them. The data I cited came from a brief >(ca. 2 week period) in early January. Repeat hits were not factored >out. MSIE was far and away the most used browser, followed by Firefox >and Netscape. Safari use was 30% of Netscape. I need to work with our >computer techs to improve the kind of information they are collecting. >When I have more useful data from a longer time period I will report >it. >Thanks for your interest. >Bill > that would be great; thanks Bill! tim --=20 Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> usa:north carolina:wake forest "As flies to wanton boys are we to the gods. They kill us for their sport."= - William Shakespeare |