Deployment

[Dr. Michael Paus]

Hi, here are my 2 €ent on this issue.

I'll concentrate on option 1 because I think this is the most critical 
but also the most interesting option.
In addition I will only concentrate on the normal installation 
procedure, i.e. when the correct Java is
already available on the system.

What I would like to see then is an installation with as few dialogs as 
possible but the most important
thing is to be able to run every app in a sandbox with only the 
privileges that the app has asked
for and the user has granted. At the moment we only have an 
all-or-nothing option which is simply
not acceptable. If I install something directly form the internet I am 
not willing to grant this software
all rights especially when there is no apparent reason why it should 
have these privileges. On the
other hand an app with almost no rights is in general quite useless. In 
swing-based apps this situation
can be improved a bit by using the JNLP Services but the deployment 
guide of JavaFX does not even
mention this option so my feeling is that using them is currently not 
supported.

The comparison made by Dan with the installation process of a smartphone 
app is a good one but
I think we even might do better with JavaFX. When I click on a link 
somewhere then the corresponding
app should be installed immediately without asking me anything but 
should provide me with some
installation progress information and possibly an option to abort the 
installation. After that the
application should run in a sandbox without any privileges. Only when I 
trigger some action which
requires more privileges, there should be a dialog which asks me to 
confirm the privileges needed for
this action. This dialog should also provide an option to see all 
privileges that this app might ever
ask for and confirm them all right now, so that this dialog does not pop 
up for every new privilege.

I also think it is important that the user can explicitly deny certain 
privileges and the app continues
and certain features are then just not activated. It should also be 
possible to re-enter this dialog
at any time to make changes to the current settings.

One further improvement would be if the programmer
would be forced to give an explanation why a certain privilege is 
needed. This information could
then be provided in the selection dialog and would help to build up some 
trust in the app. With
smartphone apps I often wonder why a certain privilege is asked for and 
what it actually means.

Michael


Am 20.04.2012 17:21, schrieb Daniel Zwolenski:
> Perhaps we could collectively try and define what the ideal user experience would be in this area and then Igor and Richard can tell us the hurdles that prevent this experience from happening?
>
> Below are the three major deployment scenarios I believe we'd like to have in our arsenal. Please add/correct based on your opinions.
>
> 1. Web-based install of desktop app
> 2. Web-based launch of Applet
> 3. Offline distributable of desktop app
>
> For all of these I believe we want a single, minimal-click, minimal-dialog process that installs (if needed), the JRE, JavaFX and the custom app being run. It is not three installs or even two to the user, they are installing one thing only - my custom app. The fact that Java or JFX is needed is not something they want to be overly bothered with. One, end-to-end, simple seamless flow is what the users want.
>
> I'll get the ball rolling with my view of the ultimate flow for option 1. In this scenario we are trying to achieve a pretty similar experience to what you get when installing an app on a smart phone. Currently webstart is the closest thing to this but it has the flaw that Java needs to be manually installed first. I suggest a plugin that does a smart install of everything. This plugin may well need to be different to the 'applet' plugin, I'm not sure. If it does however, so be it.
>
> As with normal webstart (and smart phones), option 1 is not so much a webapp as a web-based 'install' of a desktop app - once locally installed it can run offline.
>
> Here's the sort of flow I'd like to see if the user doesn't have java installed:
>
> - User navigates to the URL for the app in their favorite browser
> - Browser Plugin is triggered
> - Dialog 1: browser's standard, "do you want to install plugin"
> - Plugin is installed and runs
> - Plugin searches for existing JRE, finds none
> - Dialog 2: says:
>
>      Installing "Daniel's cool application"
>      Developed by Zen Java (more info...)
>      Java will be installed to run this application (more info...)
>      This program requires the following permissions:
>          * Read and write files on your computer
>          * Make network connections
>      [x] Add shortcut to start menu
>      [x] Add shortcut to desktop
>
> - User hits 'Install' (or 'Cancel' to abort)
>
> - Dialog 3: Combined T&C page for Java + JRE + my custom T&C (preferably one dialog with sections, or as close-to as legals will allow)
>
> - Plugin detects system (not browser) OS and 32 vs 64bit (don't ask user, 90% don't know)
> - JRE+JFX is downloaded and installed (no further input dialogs shown, just a progress indicator)
> - My custom jars (and any relevant bundled native files) are downloaded (same progress indicator as when installing jre)
> - Shortcuts are added to the relevant places
> - Final dialog: Daniel's cool application is now installed. Would you like to launch it now?
>
>  From this point on, the user can launch the app from the start menu. A browser is no longer needed (or wanted). Ideally when the app is run it first checks for a new version of Java, JFX, or the custom app online and gives the user the option to upgrade (I feel they should be able to decline). This check is done now by a local pre-launcher, ie the browser/plugin is not involved from here in.
>
> As far as signing/permissions, I think it needs to be simple. Permissions should be selected by the developer and listed for the user in the same simple approach that smart phones use (eg "write to files on your computer"). Getting a digital certificate is a pain so if there was a way to avoid this or an easier way to do this it would be great - bonus points.
>
> I would very much prefer it if the automatic Java updates weren't going on all the time in the background. It would be best if the version was just checked on app startup and the user given the option to upgrade. Then they have context. The random 'update your java now' dialog that pops up add-hoc freaks out most users and makes the others angry (including me!)
>
> If in the above flow, a suitable version of java or jfx was found, then the flow would be the same. The difference would be only that on the second dialog, instead of saying "Java will be installed" it says "Using already installed Java" and the 'more info' link then shows details on where it's installed, etc. Then the T&C section would just leave out the Terms for the already installed stuff. Similar if the JRE/JFX needs to be upgraded.
>
> That would be the optimal UE for option 1 for me. I'll stop there to see what kind of response this gets but options 2 and 3 would take similar tacts.
>
> I'm interested in hearing from the JFX guys what would prevent this from being implemented. Why cant we have this? Are there technical limitations, do you disagree that this is important or would be a better flow, or is it just too much effort?
>
> Just as importantly I'm interested in hearing from all the developers out there. Is this your ideal scenario, is this important to you etc? I raised this issue months ago and the response from the jfx guys was that non-applet, seamless install was too small a use case to warrant the effort needed. I didn't hear anyone chime in to the contrary back then so I don't blame the JFX guys for not moving much in this space.
>
> Get vocal (on solutions, not just problems). If you want something like the above, say so loud and clear. If you want something different, say that even louder so the rest of us can consider that too and back it if appropriate. There's a top notch team and community at the ready here and for my money this is a make-or-break issue. Let's work this one out together.
>
> Cheers,
> Dan
>
>
>
>
>
>
>
>
>
> On 20/04/2012, at 2:32 PM, Igor Nekrestyanov<igor.nekrestyanov at oracle.com>  wrote:
>
>> On 4/19/12 11:03 PM, Tom Eugelink wrote:
>>> Ok. How about the "there is no standard way to distribute a stand alone JavaFX application"? Create a JIRA issue?
>> Could you please be more specific?
>>
>> What is "standard way" and how do you expect to distribute this package?
>> Is it different problem from distributing java application (especially once javafx runtime will be part of the JRE)?
>> Do you expect to application "install" on the user system or run from the package?
>> Are you thinking about shipping your application to the App Store?
>>
>> We might have related feature request already:
>> http://javafx-jira.kenai.com/browse/RT-19446
>>     "Add ability to co-bundle Java + JavaFX + App into a single native executable"
>>
>> It is on 2.2 list right now but it is not clear if we can support other native packages for platforms other than Mac yet
>> (see discussion in the JIRA).
>>
>> -igor
>>


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.