 |
Does Size Matter?
Posted by javakiddy on September 15, 2006 at 02:34 AM | Comments (21)
There was an interesting exchange on the recent Java Posse pod cast about the Java Kernel project, and how important size is to the JRE download. (Hmm, that's the second JP plug in as many months -- I wonder if I qualify for a Posse t-shirt or something? :) They referenced Robert Cooper's thought provoking blog which compares download sizes for various products, thus:
JRE 1.5.0 Windows offline installation: 16.00 MB
Adobe Acrobat 7.0.8: 27.7 MB
Real Player 10.5: 13.5 MB
.NET 1.1: 23.1 MB
This got me thinking: is the problem more to do with Psychology than actual byte size?
In shops, products are regularly sold at a penny under the pound (dollar/whatever.) We get an awkward 19.99 rather than a nice round 20, because the discounted penny has some kind of strange mental trickery: we see only the 19 pounds and somehow subconsciously consider the product cheap(er).
It's very hard to tap your subconscious mind, to snapshot your true first reaction to something: that instinctive judge-a-book-by-its-cover response which we know we should ignore, but often find hard to shake off. But I've been giving a lot of thought to how I personally view download sizes...
Strange as it might seem, for some reason if I see a program with a small download size I tend to be lulled into a false sense of security. "Oh, it's only 50k in size. Probably 'mostly harmless'." For some reason larger downloads take a wee bit more bravery to install. "Wow, 190Mb! That must be some heavy duty software. I wonder if the installation will screw up anything else on my PC?"
Irrational, I know!
I remember reading somewhere -- although I can't for the life of me recall where -- that many average users consider computers to be very fragile. They have no idea how to configure their Windows desktop, they don't understand what the icons in the Control Panel are for, so they live with a constant nagging fear that something might change or stop working and they won't know how to fix it. Seen in that light, it would be entirely understandable if new software was seen as a threat -- something which could potentially change something on their PC, or worse still stop it from working at all! And the larger the download, the more heavyweight the software, and therefore the more chance it will mess something up or change something important.
But if that was the whole picture, nothing would ever get installed! Surely the truth is more complex than that?
Perhaps we are dealing with something more akin to a 'bang-for-your-buck' principle? You know how it goes: your eye is drawn to an item in a shop, and by the time you flip the price ticket over you've already subconsciously made a decision as to what you consider the price should be. The trick from a sales point of view is to make you expect a high price, and be pleasantly surprised by the 'reasonable' one on the label.
The Flash plugin may not be small, but its glossy eye candy appeal makes the users think that the download size 'on the label' is going to be bigger than it actually is. In bang-for-your-buck terms (impact versus megabytes) Flash looks like a real bargain.
Java, on the other hand, is a far more general purpose tool. Any given applet will only show off a fraction of the capabilities of the entire Java platform. The 'wow factor' usually isn't as strong, and Joe User doesn't really comprehend what Java is 'about' (unlike with Flash, which benefits from being very focuses on specific types of functionality.) As such the perceived bang-for-your-buck looks less favourable than Flash. "I have to download and install how big a plug-in to make your wavy lake applet work?!?!? Hmm... I don't think I'll bother!"
Perhaps there's another factor involved here too, which I'm going to call the 'necessary-evil' principle. It accounts for why some bloated oversized applications seem to become must-have installations.
Adobe Acrobat's download size (27.7Mb) is huge for what it apparently offers. In my opinion Acrobat's bang-for-your-buck rating is very very poor. But(!) the PDF format is frequently used for crucial data which Joe User from time to time really wants to read. Specs, government/business reports, product data, sample letters/forms, etc, etc. None of this has a particular 'wow' factor, but it is stuff which the end user typically considers important -- unlike Flash eye candy. And given that PDF is Adobe's own file format, they have a reasonably strong lock-in with their software products.
The user may not like the huge Acrobat download size -- but they realise that they need a good PDF viewer, and this is the most feature-complete one there is.
So where does this leave the JRE?
Reducing the JRE size is a worthy cause, but as a community we must also work hard to get Java associated with the most jaw-dropping, mind-boggling, awe-inspiring, must-have software on the desktop and browser. We really need to push Java to its limits and exploit all its best selling points. So when 'Joe User' is confronted with the "Please install the Java plugin" dialogue on his brand new virgin laptop, he immediately thinks of all the outstanding ground breaking (and/or indispensable) Java stuff he's seen, takes one look at the download size and says out loud "Wow! Now THAT'S cheap!"
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Interesting opinion, i personnaly think the size does not matter as long as it's 'instantaneous' to load an applet and it always works everywhere.
Posted by: liquid on September 15, 2006 at 03:59 AM
-
Great post - as usual from you!
As you have figured out, it's mostly about Marketing. Users need to get the feeling that they get a lot value for a reasonable price BEFORE they buy it and hence can actually value the product.
I've got no concerns that users will appreciate the value of the JRE once they are using some apps. So the issue is about overcoming their inhibitions. As you said, there must be some great expectations to be served with fine apps.
Despite this mostly Marketing stuff, there's another point I would like to highlight: Startup time and resources. Java apps really startup slowly and most of them consume a huge amount of memory.
One way to overcome the memory issue would be the MVM, but I wonder if there is any progress/committment on this topic. The other is better education of app developers: Wasting memory on collections is so easy in Java that Elvis as a programmer doesn't really care.
Now the most critical technical issue is the startup time. There are multiple approaches here. Again, there is some psychology to consider: A nice splash screen will make most users think the application is not loading so slowly, although there may be no difference, actually. I see we'll get this with Mustang (ah no, we are supposed to call it Java 6 this week :-).
Keep posting, always fun to read.
Regards,
Christian
Posted by: christian_schlichtherle on September 15, 2006 at 04:56 AM
-
My opinion is an outlier. Some of my machines don't have hard drives. "16.00 MB for a JVM? But I only get 32 MB of flash memory!"
Posted by: dwalend on September 15, 2006 at 05:14 AM
-
File size: 1,324 K
Download Time Estimate: 2 minutes @ 56K modem
against
File size: 15.74 MB
Download Time Estimate: impossible @ 56K modem
That's the competitor - that's the only correct comparison, that matters.
Posted by: malte_kosian on September 15, 2006 at 06:21 AM
-
Flash against JavaRuntime
Posted by: malte_kosian on September 15, 2006 at 06:22 AM
-
I think you have an excellent point here. Size is only one issue. The other issue is comfort level vs. threat level.
Installing Acrobat is no threat. The worst that can happen is that it screws up reading PDFs.
RealAudio is a little dicier. It is a smarmy client that tries to sell you stuff all the time and you wonder what else it does on your machine.
.NET? You just know it is going to screw up your machine in some way. It is a big, complex, hulking monster that interacts with your machine in a million ways. And you'll never be able to uninstall it. Of course, eventually you'll get it forced down your throat as a "security update".
Java is also kind of scary, but for a different reason. If I ask someone else to install Java on their machine, my fear is that there will be a conflict with some other version of Java that got there somehow, and that some things will fail mysteriously, showing spinning coffee cup logos, and I'll be called in for a lengthy troubleshooting session.
In other words, what needs work is a graceful update mechanism where enough consumers experience that installing and updating Java doesn't screw them up, so that the word spreads over time. That's a nasty task. It requires constant and unglamorous work, and the payback is several years out.
Posted by: cayhorstmann on September 15, 2006 at 06:37 AM
-
As far as I'm concerned it's not the download size, it's the time it takes to see something happening, which is related to the download time.
Posted by: trcorbin on September 15, 2006 at 07:04 AM
-
I agree with trcorbin. It's the time it takes to see something. Java competes with .NET and compared to that download size it's fine. However, Java also competes with Flash. Flash is a much smaller plugin and user's see something much sooner than a Java applet.
Also, the Java Kernel approach has the awesome side benefit of allowing me to distribute my Java application with a leaner JRE. So when someone is choosing between my cross-platform app written in Java and other cross-platform app written in C++/Qt, they don't think, "Hmmm... This Qt app only has a 2MB rutime (uncompressed), while Java has a massive runtime. I'll just download this C++/Qt app instead."
In a perfect world, everyone would have the latest Java pre-installed. But they don't. So I either have to have a note/link telling users to go download Sun Java version 6.x to get my app working, or bundle the full JSE with my app. For downloadable apps, that sucks compared to C++ apps (heck, even the base perl runtime is only ~6MB).
I'd much rather ship a JRE with my app so I know that things will work with a tested JRE version. However, this is a huge extra download for my users, and a separate install, and now the users gets yet another version of Java install on their system right next to the 3 copies of 1.3, and 2 copies of 1.4 -- yea! Sucks!
I want to bundle my app with the 3MB Java Kernel plus the 5MB of rt.jar and custom classes that my app actually uses. That makes for a small, acceptable download size compared to C++ alternatives. And with the Java Kernel model, the user who has my funky JRE is screwed when it comes to JSE compatibility. The other rt.jar files will get download on demand for other apps (or packaged with a different app).
Just because the Java download size doesn't bother you, doesn't mean it doesn't bother the end user. Java rules in corporate environments where you can manage the installation of the JRE everywhere, but it sucks for the home user. And just because .NET got it wrong (big downloads suck for end users -- period), doesn't mean that we don't need to get it right.
-Bryan
Posted by: prime21 on September 15, 2006 at 10:41 AM
-
You are absolutely right.
I always prefer not to install applications only if I must, I prefer to use web, applet, flash and remote based applications anything that will allow to work without installing software.
BTW regarding acrobat reader, I would recommend using Foxit reader (google it) it does not require any installation.
Posted by: zerobased on September 15, 2006 at 10:45 AM
-
This is a really bad comparison:
I wouldn't be surprised if as many people had Acrobat Reader, Real Player or .NET installed as the JRE simply because those other plugins suck.
If you're going to compare the JRE, why don't you compare it against Macromedia Flash since it is by far the most installed plugin. These other plugins are nonsense.
Posted by: cowwoc on September 15, 2006 at 12:01 PM
-
For once I have to disagree with you, Cowwoc. For a comparison of initial download and installation time, comparing the JRE to Acrobat Reader is a good comparison. Around here they're both plugins that are required at home and at work.I think Macromedia Flash is a good comparison for start up times vs. Java's web plugin.I support the idea of Java Kernel and a modular download, but I have to say...in the real world I've never heard anyone complain about the JRE's download size. It's only on java.net that I hear complaints about it.DB
Posted by: dblair on September 15, 2006 at 01:00 PM
-
I think this comparision is a little flawed. Comparing JRE with Flash and Acrobat is an apple-to-organges comparision. Flash provided an easy way to include vector imagens in web pages. PDF provides pretty-print for documets. Both provide things HTML alone can't and content provides (NOT software developers) think valuable.
If the JRE could in some way fill the niche Flash got, you'd see lots of web content as ActiveX components written using either VB or Visual C++, which by the way were much more popular among developers during the time Flash got its market. But you can see it's easier to find a web page with a Java applet than a web page with an ActiveX component. So Java Applets was a *huge* success, if you view the correct market niche. But the fact is that most of the web is about content, not custom programming logic.
People who though Java applets would provide multimedia and animation content for web pages forgot the main point: where was the Java Authoring Software? Showing them the JDK (or even current IDEs like Eclipse and IDEA) is guaranteed to make content authors look for other tools.
And you can also point to the distribution problem. Download sizes doesn't matter, because most users get Flash, Real Player and Acrobat Reader from other sources, usually pre-installed on their computers. Almost any device-driver CD comes with Acrobat. The JRE is the only of these most users actually have to download, and so they complain about download size. They would complain if they had to actually download Flash or PDF.
Compatibility is another problem. How many nice Java software runs on outdated JREs? Almost none. But It's common to get to a machine using an outdated release of Acrobat and Flash and in spite of that being able to view any web page.
Posted by: flozano on September 15, 2006 at 01:02 PM
-
I can't find anyone who has an updated .NET framework installed on his workstation. They have the same size / distribution / value perception problems as the JRE.
Posted by: flozano on September 15, 2006 at 01:37 PM
-
I agree the comparisons could be better. I stopped installing RealPlayer years ago, and as for Adobe Acrobat, is that the Acrobat Reader or the full install? I hesitated to install version 7 because it seemed to substancially increase in download size, so just my 2 cents. Not to mention Generally Acrobat is preinstalled with some other software, and thus, if I want to upgrade, it shouldnt interfere with my document reading while I am downloading the latest version.
Aaron
Posted by: aschiffman on September 15, 2006 at 04:30 PM
-
What is realy killing Java on client side is :
Speed up the startup time of applet's (make it as fast as starting a flash file) = improve WOW factor
Easy integration of vector designed art (SVG ? SWF ?) = improve the visual impact of applications easilly
Additional "must do" : bring a unified extension repository for all aplication (unified for applet and why do we need again and again to package Java's standard ext ? and why people will need to get , 4 5 ...times the same extension library !) = ease deployment & improve startup time
Posted by: bjb on September 16, 2006 at 06:08 AM
-
I think an important feature that has to be added is when a new JRE is requested that instead of the whole new JRE being downloaded only the new classes are downloaded. The fact is most computers already have a version of java installed so this will make downloading a new JRE feel quick for the user.
The JRE also needs an extension mechanism where the user can select optional packages at install time. Some packages already in the JRE could be made optional but I believe most should stay part of the JRE otherwise every time you view a new applet it you will have to download more of the JRE (this would almost certainly make Java look bad to users).
Packages like JAI, ImageIO, Java3D and JavaMail could also be added to this optional package mechanism.
Posted by: dutchiedave on September 16, 2006 at 02:15 PM
-
The JRE as a whole comes often bundled with the new computer, thanks to efforts of Sun.
The JRE could be broken up in several optional packages, loaded on demand, but a package mechanism is missing. Maybe if WebStart gets going, one can also come to something like abc.jar = a.jar + b.jar + c.jar. A bit scary on maintenance, and you might achieve only a 50% effect: the bare JRE (with GUI) seems large to me.
Posted by: joop_eggen on September 17, 2006 at 04:23 AM
-
As a developer I usually think of a Java download being the JDK. This is around 49.52Mb. I know it is the wrong size, but I tend not to download the JRE so have no idea how bit it is. I subconsciously think of the JDK size whrn thinking about users.
There are also licensing issues. Adobe Acrobat Reader is bundled with all sorts of software and also on free disks with computer magazines. Java is only available for download because you need to agree to the license before downloading!
Posted by: pbpanther on September 17, 2006 at 11:20 PM
-
After listening to the same Posse episode, I'm of the opinion that Java should probably get out of the browser plugin business.
Posted by: hifi78 on September 18, 2006 at 01:27 PM
-
The more complicated your application is and the more intensively it uses the standard library and various JVM features, the less user feedback it would take you to realize that .
My take is that Joe User would happily download and install a private JRE as part of each of those cool Java apps you are calling upon the community to produce, plus one public JRE for all those cool applets.
Posted by: dleskov on September 18, 2006 at 11:16 PM
-
Bold formatting in comments apparently means "invisible". what I typed was: "... the less user feedback it would take you to realize that a private JRE is the only way to ensure proper operation of your application on all end user systems."
Posted by: dleskov on September 18, 2006 at 11:19 PM
|
java.net RSS Feeds
