Re: [libreoffice-design] Re: Experimental new LibreOffice UI

Hi Mirek;

On Sat, Apr 20, 2013 at 8:15 AM, Mirek M. <mazelm@gmail.com> wrote:

> Hi guys,
> I find this discussion a bit misguided. The idea seems to be simply to do
> an all-encompassing, radical UI redesign without considering the pros and
> cons of the current one, platform and toolkit limitations, or a possible
> development plan. It seems as though you are trying to find solutions
> without first framing the problem(s).

I'm not going to lead a pros and cons discussion of radical UIs. My idea is
just that in Python we could very quickly prototype anything radical you
could draw. What exactly is better is above my pay grade. I'm here asking
if you've got anything.

I'm not interested in finalizing toolkit discussions. That is a dev issue
rather than a UX issue. I'm just going to document that there is no de
facto Python widget library and let the dev team figure out which is the
best for LibreOffice.

I'm not here asking for a development plan. I've got the first step figured
out which is just to create a totally empty Python toolbar / sidebar. After
that, anyone with Python knowledge could be involved to fill it in.


> Right now, the plan is to do iterative improvements rather than a one-go
> radical redesign, as we don't have the development power for one (we don't
> even have enough interested devs to work on our proposed easy hacks right
> now [1]), we want to test and refine as we go, and we want the transition
> to be as smooth as possible.

I think you should have plans for a radical redesign. Incremental
improvements are important for today's customers but it is also good to
think beyond that for excitement, strategic, and competitive reasons.

I understand that given you find the incremental improvement slow you don't
understand why it would make sense to spend any effort on anything very
different. But a key point of this proposal is that we could prototype
something radical in Python.

It doesn't surprise me that you find it hard to get people to work on Easy
Hacks, nearly all are C++, and require lots of knowledge beyond that. It is
like looking for supermodels, when there are plenty of regular models
(Python programmers) around. It is really not that hard to prototype
anything you could draw for Writer in a few months of one person fulltime.

Unless you know what you want, you don't know how smooth the transition
will be.


> However, I don't mind considering the big picture.
> Given that most UI redesign proposals stem from Microsoft Office's UI
> redesign, let's compare our current UI to Office's.
> The advantages of Office's UI, as I see it, are:
> * A single place to access commands. The user doesn't have to hunt for
> commands across menus, toolbars, dialogs, and sidebar panes to find the
> desired command.
> * Context. Irrelevant disabled commands are inaccessible and the most
> relevant commands are brought to the forefront, thereby making it much
> easier to find the desired command. Commands that are not relevant to
> editing the current document, like New, Open, Templates, or Print, are
> hidden away.
> * No dialogs. There's very little need to use dialogs, which speeds up the
> editing process and keeps the user focused on the document.
> * Previews. Changes are previewed instantly in the document. Whereas
> dialogs tend to have a preview area showing only the selection, using the
> ribbon, the user can see what the changes look like inside the document.
> * Better categorization. LibreOffice uses different categorization systems
> for menus, toolbars, panes, and even the "Customize..." dialog. All of them
> are unsatisfactory, with vague categories and oddities. Office has a single
> categorization system and while it also has vagueness and inconsistencies,
> it's a bit more logical.
> * Visual design. The icon theme and the skin in Office seem much more
> modern than our current look.
> * Less customization. It's much harder to mess up your installation in MS
> Office than in LibO with bad choices. Also, the Office Options screen is
> much easier to go through and use.
>
> The disadvantages:
> * Readability. It's much harder to read through the ribbon than a standard
> toolbar, as there is no clear path for the eyes to follow.
> * Complexity. The ribbon is much more complex than a standard toolbar.
> Therefore, it's harder to maintain and to make it adapt to changes.
> * Touch-friendliness. The ribbon is not suited to a touch-environment. Even
> under "Touch mode", it can be hard to target the commands shown with
> smaller icons.
> * Nonconformity. The ribbon is alien to all platforms except Windows. Mac
> OS requires a menu bar for each application.
> * Space usage. The ribbon takes up a ton of space. (Some propose putting it
> on the side, yet that could be a problem for people who need to have two
> documents side-by-side, e.g. translators.)
> * Inconsistencies. While I argued above that the categorization is better,
> it certainly has its quirks. For example, some commands cannot be found
> within the ribbon and are instead presented in a "Quick Access" toolbar or
> are not presented at all. The "Home" category is too vague.
>
> Notice that the advantages listed above don't require a ribbon-like UI and
> can be accomplished using toolbars while retaining all of the advantages of
> LibreOffice's current UI. Focusing on toolbars also allows a smoother
> change and less development effort. The proposed EasyHacks are a first
> step.

You could quickly prototype any kind of toolbar or ribbon in Python.

Do you have a better toolbar design? I'd update my wiki page with anything
radically better. For this task, I suggest you not worry about what is
doable and instead what you want.

-Keith

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted