incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Grignon <kevingrignon...@gmail.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 09:48:56 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message