Bug 73889 - GUI improvements with little code change
Summary: GUI improvements with little code change
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-21 18:18 UTC by Armandos
Modified: 2015-01-24 12:38 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Issues with resizing window and sidebar. (738.64 KB, image/jpeg)
2014-01-21 18:18 UTC, Armandos
Details
2 windows open with modified UI (738.64 KB, image/jpeg)
2014-01-21 18:21 UTC, Armandos
Details
Modified UI to match mockup (109.37 KB, image/jpeg)
2014-01-21 18:22 UTC, Armandos
Details
Mock-up from deviantart (271.12 KB, image/png)
2014-01-21 18:23 UTC, Armandos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Armandos 2014-01-21 18:18:48 UTC
Created attachment 92533 [details]
Issues with resizing window and sidebar.

Checking out one of the most popular UI mockups (by pauloup on deviantart), I noticed that the implementation of the OOo sidebar was brought LibreOffice the closest to achieving a new GUI yet.

I also noticed that with only a little tinkering, I could replicate the mockup to a great extent. The result was not without its problems but I believe it can allow a reconsideration of how the default GUI materialises upon installing LibreOffice.

Reasons why this suggestion should be considered:
* UIs are important to the average end-user. Period.
* Kingsoft Office is being ported to Linux. I have used it for months and the only setbacks, when compared to LO, were speed (port is still in Alpha) and open document filetype support (easily fixable).
* The mockup is popular and easily replicable.
* End users may be able to replicate the mockup, but the one issue with FOSS and widespread adoption is that users are expected to tamper and spend time on customization.

Issues with current, manual process of changing the interface:
* The sidebar has too much dead space. Boxes under indent do not come closer together when resizing the window. As such, resizing the window to a smaller size results in the sidebar taking up most of the space.
* An extension of the above issue, working on one document while viewing another results in even more dead space, taken up by the sidebar.
* Find toolbar closes easily. An always open option would be useful.
* Using firefox themes option allowed for a nicer, slightly gradient solid background for the top toolbar. End users should not be expected to spend time customizing, they are interested in out-of-the-box experience (hence the term "productivity" suite). Default gradient colour background?
* Zoom settings could be moved to the top toolbar, as per the mockup.
* Sidebar could be *always on* once it is stable, appearing at the left side.
* So far, the top toolbar experience has users used to all options being next to each other. Too much dead space between bold/italics/underline and increase/decrease font size.

Other issues/suggestions that may require additional coding:
* The ability to have more than one document open within one instance of LO Writer, would help alleviate the sidebar resizing issue.
* GUI selector. I can't stress it enough how my experience with trying to get people to switch to FOSS and LO has failed, due to the archaic look and the non-ease of use. A GUI selector will also allow users satisfied with the current UI keep it that way, but also attract new users.
Comment 1 Armandos 2014-01-21 18:21:13 UTC
Created attachment 92534 [details]
2 windows open with modified UI
Comment 2 Armandos 2014-01-21 18:22:19 UTC
Created attachment 92535 [details]
Modified UI to match mockup
Comment 3 Armandos 2014-01-21 18:23:07 UTC
Created attachment 92536 [details]
Mock-up from deviantart
Comment 4 Armandos 2014-01-21 18:26:03 UTC
I only mentioned the sidebar to be *always on* and on the left side. I meant to say that the UI, as shown in the attachments, should be the default.
Comment 5 tommy27 2014-01-23 20:27:24 UTC
I mark this as INVALID. too many requests into a single report are difficult to manage. the policy here is one request per report.

you should split all those requests into single reports and then link them to a common meta-bug.
Comment 6 tommy27 2014-01-23 20:28:33 UTC
your requests are legitimate and I agree with some of them, but as said before, you have to file separate reports for each of them.
Comment 7 tommy27 2014-01-23 20:40:13 UTC
example of a meta-bug collecting multiple request is Bug 42082