For AOO to achieve its full potential it must be possible to use it
while assuming "Java" refers to an island one of whose exports is coffee
beans.
However, in normal home and office environments, the people doing
installation are often more technically knowledgeable, and more likely
to RTFM if they hit a problem, than the end users. For example, many of
my friends know someone who is good at installing software who they ask
for help. Small offices may bring in a support service. Larger
businesses have a department that keeps office workstations up to date.
A reasonable first step would be to ensure that when the installation
finishes successfully AOO is ready for use by any end user with minimal
keyboard and office skills.
On 10/29/2015 10:44 AM, Dennis E. Hamilton wrote:
The Java dependency problem keeps coming up buried in other threads.
I am redirecting the most recent case so we can put light on this
situation.
Before the dependencies on Java are increased/improved, I think there
is a crucial usability matter.
1. Currently users are trap-doored by exercising a feature or dialog
that suddenly raises a Java dependency, sometimes for which there is
no escape other than finding a way to shut down AOO that is not a
normally-required skill.
2. The fact that full functioning of AOO is buried in the system
requirements in a way that users can easily overlook (or never
examine) is a problem. We can fix that page, even providing (or
linking to) specific details of what the dependencies are. That would
be useful so developers and power-users have the details. However,
the system requirements are probably not read by most who download
the software (based on over 40 million downloads of 4.1.1,
overwhelmingly on systems designed for casual users).
3. If the installer required presence of Java, that would be a clear
indication that it is required for operation. It would also be
helpful if the installer provided an usable link for installing a
workable Java if one is not present.
4. If the presence of Java is indeed optional, and the user does not
have it or elects not to use it, AOO should not even offer functions
for which Java is required. That is another way to improve the
usability and at least avoid users falling through trap-doors.
5. Shouldn't we do this better? Or are we to decree that AOO is only
intended for power-users who have strong skills with regard to
managing their configurations, managing the install of dependencies,
trouble-shooting and being able to work around the not-dependable way
things work now?
Three paths come to mind.
A. Remove the Java dependencies.
B. Adjust the Java dependencies, 1. So that the dependencies are
clear and the situation around failures to find a suitable JRE is
made workable for casual users. This could involve the above (2-4)
remedies. 2. Only then consider increasing the dependencies on Java
for full-function operation in some controllable way.
C. Make AOO a Java application that has C++ components, rather than
the reverse.
These are all serious. Probably on the way to either A or C, one
must address B.
We also need to consider what the project's capacity for any of these
cases happens to be.
Thoughts?
- Dennis
PS: There is a bigger question about platform presence in here.
There are distributions for which Java dependency is not particularly
attractive and we may be cutting ourselves off from those. That
might not matter if we are talking about the small percentage of the
downloads that are for neither Windows nor Macintosh desktop PCs.
-----Original Message----- From: Pedro Giffuni
[mailto:p...@apache.org] Sent: Thursday, October 29, 2015 08:07 To:
Apache OO <dev@openoffice.apache.org> Subject: Re: Thinking of
joining OpenOffice as a developer
Hello;
First of all, a warm welcome to Patricia. Java developers are
particularly welcome at this stage!
Just IMHO, the C++ side of AOO is either under-control or
too-ugly-to care-about, so we would do good focus more on the Java
parts, which are also somewhat ugly but still promising.
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
