P3
From Thorsten:
Let's take a step back here and think about what we're trying to accomplish and who the target customer is. Let's try to look at this through the eye of a mid-aged pogo.com player. That person does not know Java, does not know what a runtime environment is or why she would install one (actually she might not know what it means to install something on a computer). She will probably not have internalized the concept of a file system and it will not be 100% clear whether "accept", "decline"or "change..." is the right response to an installation request.
Second then think about the entire install process - including the web page that triggers it. You really get a 4 click experience:
1) Web page that points to the executable
2) Windows dialog asking if you really want to install
3) The dialog in your design
4) The installation complete dialog
Contrast that with Flash, where you have
1) Web page that points to the executable (http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&promoid=BIOW)
2) Windows dialog asking if you really want to install
and then you're done.
I'd like to challenge us to get to the same experience for Java (at least for the consumer):
We would rename the JRE into Java Player. There'd be one web page that describes what Java is in consumer oriented terms, provides a link to our license which you auto-accept by installing. It would also include any 3rd party offers we may make.
Once the end user selects install she gets the windows dialog and everything else happens silently in the background. We may actually get rid of the installer UI altogether and just show status updates in the tray icon. Completion could also be indicated in the tray icon.
A similar (web driven) user experience could potentially be used for auto-update as well enabling us to dynamically change sponsors. When the update is fully downloaded you'd get to a web page which allows you to accept and select 3rd party offers.
Let's take a step back here and think about what we're trying to accomplish and who the target customer is. Let's try to look at this through the eye of a mid-aged pogo.com player. That person does not know Java, does not know what a runtime environment is or why she would install one (actually she might not know what it means to install something on a computer). She will probably not have internalized the concept of a file system and it will not be 100% clear whether "accept", "decline"or "change..." is the right response to an installation request.
Second then think about the entire install process - including the web page that triggers it. You really get a 4 click experience:
1) Web page that points to the executable
2) Windows dialog asking if you really want to install
3) The dialog in your design
4) The installation complete dialog
Contrast that with Flash, where you have
1) Web page that points to the executable (http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&promoid=BIOW)
2) Windows dialog asking if you really want to install
and then you're done.
I'd like to challenge us to get to the same experience for Java (at least for the consumer):
We would rename the JRE into Java Player. There'd be one web page that describes what Java is in consumer oriented terms, provides a link to our license which you auto-accept by installing. It would also include any 3rd party offers we may make.
Once the end user selects install she gets the windows dialog and everything else happens silently in the background. We may actually get rid of the installer UI altogether and just show status updates in the tray icon. Completion could also be indicated in the tray icon.
A similar (web driven) user experience could potentially be used for auto-update as well enabling us to dynamically change sponsors. When the update is fully downloaded you'd get to a web page which allows you to accept and select 3rd party offers.