| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4651.1 | | teco.mro.dec.com::tecotoo.mro.dec.com::mayer | Danny Mayer | Tue May 06 1997 10:28 | 16 |
| None of this surprises me. You should be avoiding things like Java
for people who don't have Java on their system. You should be using Java
only where it's really useful. I have yet to see a really useful example
of where Java would actually be of benefit on a Web page. People are using
the technology because it's the IN thing to use rather than trying to figure
out what's best for the application that they are implementing. If you have
a hammer, must everything be a nail? You can try Javascript but again you
are dependant on the browers that people have. You can see an example of this
at URL:
http://www.ntmail.co.uk/
Has anyone bothered to analyse the Web log files to see what browsers
people are using?
Danny
|
| 4651.2 | Thought Java would be acceptable | MISTA2::EARLE | | Tue May 06 1997 13:24 | 28 |
| I agree with you about using the technology, in this Java only if
solves a problem. In this case we felt it did solve the problem of
navigating to information on our Web Site.
We have more than 10 Gigabytes of information. We recognize that users
are starting at different points (i.e. know the product not what
documents are avialable, know the document but not what products are
included in the document list, etc.).
The expandable/collapsible TOC seemed to address the navigation problem
quite nicely and it is easy to maintain. Our web site
http://cosmo.tay.dec.com currently uses this Java applet based TOC.
Our audience are Digital Technical Support people and certain Digital
Partners. So we felt that are user community would be more receptive to
the use of this technology if it helped.
We also look at using Javascript but were not satisfied because of the
need to refresh the screen everytime you expanded/collpased the TOC.
The Java applet did not do that.
So as you can see, it was an informed decision to go with the Java
applet approach.
One solution to the performance issue associated with loading applets
is to cache them. Does anyone know why that can't be done?
Ed
|
| 4651.3 | | BIGUN::nessus.cao.dec.com::Mayne | A wretched hive of scum and villainy | Tue May 06 1997 18:00 | 4 |
| You might also want to look at conforming with the DIGITAL branding guidelines
at http://www.imc.das.dec.com/brand/index.html.
PJDM
|
| 4651.4 | | XSTACY::imladris.ilo.dec.com::grainne | Grainne Ni Choiligh | Wed May 07 1997 07:53 | 5 |
|
Re: .3
A dirty big purple stripe down the side of his pages will stop users'
browsers from locking up ? Amazing.
|
| 4651.5 | | MRPTH1::16.121.160.249::slab | labounty@mail.dec.com | Wed May 07 1997 12:12 | 4 |
|
I'd rather have a co-worker give me a warning on a mistake like that than to
have corporate shut the page down.
|
| 4651.6 | | HYDRA::VANORDEN | | Wed May 07 1997 18:06 | 33 |
|
Ed,
>Using the Windows 95 System Monitor, we can see resources not being
>restored completely after loading the applet(any applet for that matter)
>or the large table HTML file.
The problem appears when loading any applet OR a large table HTML file?
(So it is not isolated to applets, but to large loads?)
Are you sure the problem is with Netscape? Have you tried another
browser (or ruled out other possible culprits?)
There is a known memory leak that occurs when opening and closing a
Socket using the Windows Sockets API, which might be the source of your
problem. The patch is at:
http://www.microsoft.com/windows/software/krnlupd.htm
Good luck.
re: >You might also want to look at conforming with the DIGITAL
>branding guidelines at http://www.imc.das.dec.com/brand/index.html.
I took a look. It seems to only address placement of logos, colors,
product names, etc. There is no mention of what language we can/cannot
use to get the job done. I'd be very disappointed if that decision was
not left to the developer.
Donna
|
| 4651.7 | Have you had occasion to use LiveLinks? | TWICK::PETTENGILL | mulp | Thu May 08 1997 02:10 | 9 |
| >I have yet to see a really useful example
> of where Java would actually be of benefit on a Web page.
I find the AltaVista search LiveLinks quite useful and the map, implemented
with Java, is able to convey a sense of the data that the two alternate
representations don't.
But I would argue that you should, like AltaVista, offer alternatives to
the Java implementation.
|
| 4651.8 | I actually like the page in question, though | LGP30::FLEISCHER | without vision the people perish (DTN 381-0426 ZKO1-1) | Thu May 08 1997 06:48 | 36 |
| re Note 4651.7 by TWICK::PETTENGILL:
> I find the AltaVista search LiveLinks quite useful and the map, implemented
> with Java, is able to convey a sense of the data that the two alternate
> representations don't.
Really, I've tried it numerous times, but have gotten far
more humor than enlightenment from it. I must not be asking
the right queries. :}
(Besides, for me, running browsers in beta, the use of Java
seems to mean consistently slower page loading, slower
browsing in other windows while the applet is running, and
most of the time the browser will crash sooner.)
> But I would argue that you should, like AltaVista, offer alternatives to
> the Java implementation.
Another problem for Java vs. HTML is that the content of HTML
pages is easily indexed (and thus searchable) by crawlers
such as AltaVista's, as well as links out of HTML pages are
easily found and followed. (You can overcome this on a page
by page basis by careful use of the META tag.)
(Also, I like having selectable text on pages I'm viewing --
most browsers make HTML text fully selectable/copyable,
whereas this does not seem to be true of the text displayed
by many Java applets. But, then, I prefer character cell
Notes for the same reason, so I'd warn you that I'm a
troglodyte.)
I personally would use Java only for interaction styles that
were absolutely essential to the application and which could
not even be approximated reasonably by HTML.
Bob
|