incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Date Fri, 18 May 2012 12:18:24 GMT
To know how this should impact our planning, it would be wise to understand the respective
app stores better. I only know the Apple store from a user perspective so I wouldn't know
how much magic you can do during install or if it's just a plain copy of the .app bundle.
And I don't know anything tech about Windows store in Win8.

Jan

Den 18. mai 2012 kl. 11:48 skrev Kevin Grignon <kevingrignon.oo@gmail.com>:

> Well said.
> 
> 
> 
> On Fri, May 18, 2012 at 5:45 PM, Jan Høydahl <jan.asf@cominvent.com> wrote:
> 
>>> This is an important issue. Single click installation is expectation of
>> the
>>> market place that cannot be ignored.
>> +1
>> 
>> Also keep in mind that both Apple and Microsoft are moving towards 1-click
>> installs from App stores as the new default, so in a few years new PC/Mac
>> users (such as students) will never even look outside of the app store when
>> looking for programs.
>> 
>> This calls for a single multi lingual AOO installer which "does the right
>> thing" without user input. That "thing" would be looking up users default
>> language, download the corresponding lang pack (remember that user is
>> necessarily connected to Internet when installing from app store) and
>> install it. Next time user starts the app he can be prompted for additional
>> langs.
>> 
>> Jan
>> 
>> Den 17. mai 2012 kl. 05:24 skrev Kevin Grignon <kevingrignon.oo@gmail.com
>>> :
>> 
>>> Hello All,
>>> 
>>> This is an important issue. Single click installation is expectation of
>> the
>>> market place that cannot be ignored.
>>> 
>>> That said, we are not an mobile app, and desktop applications require
>>> additional installation configuration by the end user.
>>> 
>>> With regards to language pack, I'll leave the back end to the development
>>> folks.
>>> 
>>> From a UX perspective, we might consider the following:
>>> 
>>> - allow the users to single click to install the application using smart
>>> default configuration (install location, default language pack, default
>>> values, etc.)
>>> - progressively disclose secondary installation requirements, such as
>>> language packs
>>> 
>>> There are two paths we could explore here:
>>> 
>>> 1 - have language selection as part of install
>>> - the user could select the languages they want, and we download and
>>> install in background
>>> - we should not send people to find installation files for a second,
>> manual
>>> install
>>> 
>>> 2 -  prompt for additional languages when the user opens the app for the
>>> first time
>>> - again, download and install in the background
>>> 
>>> Finally, a user should be able to manage the languages from within the
>>> product itself. Here again, we take care of downloads, unpacking and
>>> installation behind the scenes. Yes, we support many languages and
>>> platforms, this is our choice and we should not burden our end users with
>>> this complexity. I suspect most user just want to install their platform,
>>> select their language pack, and get to work. Let's help them do jsut
>> that.
>>> 
>>> Some thoughts...
>>> 
>>> Regards,
>>> Kevin
>>> 
>>> 
>>> On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rbircher@apache.org
>>> wrote:
>>> 
>>>> Am 16.05.12 21:53, schrieb Andrew Rist:
>>>>> see idea #5 below
>>>>> 
>>>>> On 5/16/2012 12:06 PM, Rob Weir wrote:
>>>>>> Release = Size * Platforms * Languages
>>>>>> 
>>>>>> That's the basic math we're dealing with now.  Let's ignore SKD and
>>>>>> langpacks since they are much smaller.
>>>>>> 
>>>>>> An AOO install is around 150MB.
>>>>>> 
>>>>>> We currently support 6 platforms (taking into account different Linux
>>>>>> packaging models), and 15 languages.
>>>>>> 
>>>>>> So Release = 150MB * 6 * 15 = 13.5 GB.
>>>>>> 
>>>>>> Let's look at AOO 3.4.1 where we will probably add Finnish, UK
>>>>>> English, Norwegian and Hebrew.
>>>>>> 
>>>>>> So Release = 150MB * 6 * 19 = 17.1 GB.  This gets added to the
>>>>>> previous 13.5 GB, since we keep older releases around, or at least
we
>>>>>> do currently.
>>>>>> 
>>>>>> Imagine then future growth.  Maybe Windows 64-bit, OS/2, OpenIndiana.
>>>>>> Imagine we get back to 44 languages supported via full installers.
>>>>>> Then what?
>>>>>> 
>>>>>> Release = 150 MB * 9 * 44 = 59.4 GB.
>>>>>> 
>>>>>> So we're not talking TB's here. But it does add up, if we want
>>>>>> preserve the release artifacts for earlier releases.
>>>>>> 
>>>>>> Aside from storage, this is complexity for build a release.  It is
>>>>>> more stuff to build, more stuff to schlep around people.apache.orgfor
>>>>>> release candidates, more complexity in download scripts, more stuff
to
>>>>>> sign, more places to make mistake.  Someone could make a full time
job
>>>>>> just managing the builds and releases of this full matrix.
>>>>>> 
>>>>>> Now to be fair, this matrix is optimal for the end user.  99% of
the
>>>>>> users can download a single file and it has everything they need.
 No
>>>>>> extra things to download. And their download is as small as it can
be.
>>>>>> It is perfect for them.
>>>>>> 
>>>>>> But I wonder if we can make a radical simplification while still
>>>>>> making it really easy for the user?  Unless of course, someone wants
>>>>>> to volunteer to be a full-time build engineer?
>>>>>> 
>>>>>> ==Idea #1==
>>>>>> 
>>>>>> Factor out the translations for the install program versus the AOO
>>>>>> program itself.  Make the installer support all languages.
>>>>>> 
>>>>>> Make core installer only have en_US resources.  Everything else is
>>>>>> provided via language packs.
>>>>>> 
>>>>>> Make the language pack be platform-neutral, e.g., resources only.
>>>>>> Rely on the installer that you've already downloaded for the logic
to
>>>>>> install the language pack.
>>>>>> 
>>>>>> Have the installer prompt the user at the end of the install to
>>>>>> install a language pack and then take them to the right webpage to
>>>>>> download.
>>>>>> 
>>>>>> Have the installer look in the current directory for any language
>>>>>> packs and automatically install them at the end of the install. 
This
>>>>>> would support install fro or other places where additional downloads
>>>>>> are not possible.
>>>>>> 
>>>>>> Pro: A full release size then becomes 150 MB x Platforms + 20MB *
>>>>>> Languages.  So the monster case that was 59.4 GB above now becomes
2.3
>>>>>> GB.
>>>>>> 
>>>>>> Con:  A lot of Dev work.
>>>>>> 
>>>>>> ==Idea #2==
>>>>>> 
>>>>>> Create a single multi-language install that covers whatever languages
>>>>>> are needed to support 99% of our users.  I've heard this idea
>>>>>> suggested, but it doesn't really work.  We have "long tail" effect
>>>>>> here.  Even if you bundle the top 20 languages it is still only a
>>>>>> little over 80% of our users.
>>>>>> 
>>>>>> ==Idea #3==
>>>>>> 
>>>>>> Create language installs on-demand via a cgi script.  An MRU cache
>>>>>> would make the most common ones already ready.
>>>>>> 
>>>>>> Pro:  Can essentially dial in whatever space you want to allocate
for
>>>>>> the cache.  Is efficient with respect to bursty traffic, e.g., we
get
>>>>>> a sudden appearance on the evening news in Kazakhstan.
>>>>>> 
>>>>>> Con: Security aspects of cgi, and low likelihood that mirror operators
>>>>>> are willing to donate more CPU cycles as well.
>>>>>> 
>>>>>> ==Idea #4==
>>>>>> 
>>>>>> Chill.  Relax.   Disk space is cheap and dropping.
>>>>>> 
>>>>>> Con:  It is not just disk space.  It is complexity as well, especially
>>>>>> for our release process.
>>>>>> 
>>>>>> ==Idea #5==
>>>>> 
>>>>> Two changes
>>>>> - create an installer that works from a local file system (or CD)
>>>>> that installs all of the signed and well formed artifacts in the fs.
>>>>> This means that it will install base AOO, language packs, extensions
>>>>> (dictionaries) , and templates.
>>>>> - create a bootstrap installer that will download the appropriate
>>>>> bits from the interwebs to your local fs and then kick off the install.
>>>>> 
>>>>> Pro:
>>>>> - has lower disk footprint in archives and limits download bandwidth
>>>>> to required bits
>>>>> - provides seamless install experience for user whether from web,
>>>>> local fs, or cd.
>>>>> - improved install experience, as extensions, templates, extra
>>>>> languages, etc can be added into the base install seamlessly.
>>>>> - allows for value add downstream packaging - with dictionaries,
>>>>> extensions, etc.  Once the file structure is created it can easily be
>>>>> written to media, thus custom install on a cd.
>>>>> - with proper design on bootstrap installer, the download can be
>>>>> optimized (compression, restartability, etc)
>>>>> 
>>>>> Cons:
>>>>> - it is only ideaware at the moment
>>>> You need internet or you have a ugly puzzle.
>>>> 
>>>> Sure, it's the easyest way, but i beleve not the best.
>>>>> 
>>>>> 
>>>>>> 
>>>>>> <Insert your idea here>
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> -Rob
>>>>> 
>>>> 
>>>> 
>> 

Mime
View raw message