Date: prev next · Thread: first prev next last
December 2012 Archives by date, by thread · List index


Hi Olivier,

On Thu, Dec 13, 2012 at 7:55 PM, Olivier R. <olivier.noreply@gmail.com>wrote:

Hi mirek,


mirek2 wrote
The original idea was to not have a static size for the overlay, but
rather
have its size detemined by its contents

But it was static. Only half the space was used. And I have many templates
and it was unpractical with this tiny place.


Sure, I understand.
I'm just saying this is something that can be changed about the overlay and
it's not a reason to get rid of them altogether.


mirek2 wrote
, in the same way it works on
Android (and as was designed for our Android port), and similar also to
iOS/new Mac OS X behavior.

Why such priority for Android? Be consistent with Android, ok, but not
being
consistent with the desktop is a mistake. LO is mostly a application to
work
on desktop. So to being consistent on PC is important too. This is still a
productive application.


The idea is to be consistent across all platforms, including Android.

If we're talking about consistency on the desktop, things get murky,
because the file management paradigms are shifting.
Mac OS X is shifting to a new document management model and UI [1], much
like that on iOS and on Android. It's not switching to be touch-compatible
(Macs don't feature touch screens), it's switching to them because the old
model and UI is dissatisfactory.
Windows 8 and Gnome are undergoing a similar file management renaissance.
As this template manager will not change drastically in the next few years,
it makes sense to design for the new document model (which has basically
solidified on mobile operating systems and is gradually being incorporated
into desktop ones) rather than stick with the old flawed document model.


mirek2 wrote
It was imagined that there would only be one level of hierarchy (as is
standard on Android and iOS), as it makes browsing templates much simpler
and will be necessary if/when there is sync functionality between Android
and desktop LibreOffice.

Why limitating other users with such restrictions?
Other users may have more than one level.


Here are a few reasons:
1) From [1]: "Folders tend to grow deeper and deeper. As soon as we have
more than a handful of notions, or (beware!) more than one hierarchical
level of notions, it gets hard for most brains to build a mental model of
that information architecture. While it is common to have several hierarchy
levels in applications and file systems, they actually don’t work very
well. We are just not smart enough to deal with notional pyramids. Trying
to picture notional systems with several levels is like thinking three
moves ahead in chess. Everybody believes that they can, but only a few
skilled people really can do it. If you doubt this, prove me wrong by
telling me what is in each file menu in your browser…
2) From the same link: "Folders-in-folders are hard to deal with. Just as
physical folders-in-folders are prone to creating a mess, digital
folders-in-folders represent a steep mental hurdle for most of us. Most
people don’t want to bother with folder structures. They get confused when
they’re forced to deal with settings in a text editing application. People
expect things to just work."
3) Synchronization of folders across platforms, like Android and iOS, where
single-level hierarchy is standard.

[1] http://informationarchitects.net/blog/mountain-lions-new-file-system/

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.