Bug 91781 (Writer-Menus) - [META] Reorganization of the menu bar for Writer
Summary: [META] Reorganization of the menu bar for Writer
Status: ASSIGNED
Alias: Writer-Menus
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Yousuf Philips (jay)
URL:
Whiteboard: target:5.1.0 target:5.2.0 target:5.1...
Keywords:
Depends on: 78371 Writer-Toolbar-PrintPreview Help-Menu-Updates 104332 108224 83054 94095 95280 95489 96253 96573 97467 99016 103733 104151 107573 108763 108967
Blocks: Main-Menu Writer-UX
  Show dependency treegraph
 
Reported: 2015-05-31 17:21 UTC by Yousuf Philips (jay)
Modified: 2017-10-30 17:39 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
writer menubar screenshots (242.28 KB, image/png)
2015-06-02 15:07 UTC, Yousuf Philips (jay)
Details
Writer's tools menu stats (226.22 KB, image/png)
2015-06-03 05:51 UTC, Yousuf Philips (jay)
Details
writer menu bar from 4.3 (217.80 KB, image/png)
2015-06-03 23:48 UTC, Yousuf Philips (jay)
Details
Separate menu for direct formatting (20.27 KB, image/png)
2015-06-06 09:57 UTC, Heiko Tietze
Details
Separate menu for direct formatting - menu tweak (25.84 KB, text/xml)
2015-06-06 09:58 UTC, Heiko Tietze
Details
Separate menu for Styles (11.12 KB, image/png)
2015-06-07 10:22 UTC, Heiko Tietze
Details
Separate menu for Styles - menu tweak (25.67 KB, text/xml)
2015-06-07 10:23 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2015-05-31 17:21:45 UTC
I had done reorganization of the file menu in bug 85945, as well as minor tweaks here and there, so now its time to completely overhaul Writer's menubar, taking into consideration our new HIG for the menu ( https://wiki.documentfoundation.org/Design/MenuBar ).

I have already completed the reorganization with the help of the OOo user stats, as well as analyzing a number of competing word processors, and will be pushing the changes into master, so i look forward to your suggestions once you've had a chance to go over it.
Comment 1 Commit Notification 2015-05-31 22:21:31 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c189a1eb90012789692344aa7dc418c7ec7f032

tdf#91781 Reorganize writer's menu bar

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 2 Adolfo Jayme 2015-05-31 23:58:33 UTC
Hey!

If you’re going to push a radical change without letting us comment on it, why do you pretend you welcome comments? I interpret this as you wanting us to be excluded of the design team.
Comment 3 Yousuf Philips (jay) 2015-06-01 14:53:04 UTC
I was primarily looking for comments on the reorganization of the menubar, so for many users, they would only see this in a built version, so i pushed it in which of course doesnt mean it cant be fixed again with another commit.
Comment 4 Cor Nouws 2015-06-02 13:41:36 UTC
(In reply to Adolfo Jayme from comment #2)
> Hey!
> 
> If you’re going to push a radical change without letting us comment on it,
> why do you pretend you welcome comments? I interpret this as you wanting us
> to be excluded of the design team.

Jay and me spent a lots of time last year on discussing UI changes. But IMO it was hard to always find common ground on objective data - many parts went really well. But apart from that, it was killing at least _my_ agenda..
So Jay takes a different approach now. Surprise to see what comes out of it .. :D
But OTOH, a screenshot before and after proposed change, would make looking at it earlier easy, I agree.
Comment 5 Yousuf Philips (jay) 2015-06-02 15:07:02 UTC
Created attachment 116240 [details]
writer menubar screenshots

(In reply to Cor Nouws from comment #4)
> Jay and me spent a lots of time last year on discussing UI changes. But IMO
> it was hard to always find common ground on objective data - many parts went
> really well. But apart from that, it was killing at least _my_ agenda..
> So Jay takes a different approach now. Surprise to see what comes out of it
> .. :D

Yes the good old days. :D

> But OTOH, a screenshot before and after proposed change, would make looking
> at it earlier easy, I agree.

Just grab a recent daily build and you can easily see it in action, else here is a screenshot.
Comment 6 Heiko Tietze 2015-06-02 15:20:49 UTC
I like it in general. Maybe we can strip down the menus a little bit further; at least the Insert menu is quite large. But what becomes obvious here is the missing guideline for captions. Wait, it isn't missing :-). "Use a verb-action combination for the label (e.g. Show ruler, Format image) but adopt this rule for localization."

The issue pops up for '??? comments' and 'Hide images'.
Comment 7 Yousuf Philips (jay) 2015-06-02 15:34:32 UTC
(In reply to Heiko Tietze from comment #6)
> I like it in general. Maybe we can strip down the menus a little bit
> further; at least the Insert menu is quite large. But what becomes obvious
> here is the missing guideline for captions. Wait, it isn't missing :-). "Use
> a verb-action combination for the label (e.g. Show ruler, Format image) but
> adopt this rule for localization."

Not sure how well the verb-action will work in all menus, as you'd have Insert before every entry in the insert menu.

> The issue pops up for '??? comments' and 'Hide images'.

View > Comments = View Comments
View > Hide Images has been turned into View > Images and Charts (bug 91783)

I've tried to keep changing the strings down to a minimum and focused primarily about reorganization based on importance and adding entries not previously found in the menus.
Comment 8 Cor Nouws 2015-06-02 23:07:35 UTC
(In reply to Yousuf (Jay) Philips from comment #5)
> Created attachment 116240 [details]
> writer menubar screenshots

thanks.

> (In reply to Cor Nouws from comment #4)
> Yes the good old days. :D

I'm sure you would like to do that again :)

> Just grab a recent daily build and you can easily see it in action, else
> here is a screenshot.

Quite much to grab and hold track. So service much appreciated :)
Comment 9 Cor Nouws 2015-06-02 23:13:05 UTC
Hi Jay,

Question: what is the work based on, comments, experience, study, comparing
with other software, ...?
I see a interesting change ahead for users, writers, documentation teams,
trainers..

Some comments:

Edit
Merge document is a function limited to documents with tracked changes. It must
be in that sub menu.

What happened to Edit > Fields / Footnote/Endnote / Index entry / Bibilograohy entry / Hyperlink? I don't see them.


View

Pls keep print preview with File > Print.

Tools
What more is on Tools > AutoCorrect? Prolly is now in Format > AutoCorrent? Is OK for me.

thanks a lot,
Cor
Comment 10 Joel Madero 2015-06-03 01:13:59 UTC
I would also like to know *why* the changes were made. What actual proof do we have that this is better other than personal opinions? There have been complaints by users and developers that things "change just for change sake" and that these changes are made without thinking of the consequences for other teams (including documentation which was already mentioned).

@Jay - are you willing to clean documentation to match all of these changes?
Comment 11 Yousuf Philips (jay) 2015-06-03 02:33:08 UTC
(In reply to Cor Nouws from comment #9)
> Question: what is the work based on, comments, experience, study, comparing
> with other software, ...?

As stated in the description, "I have already completed the reorganization with the help of the OOo user stats, as well as analyzing a number of competing word processors". So basically i've used the same method i've used to improve the toolbar and context menus.

> I see a interesting change ahead for users, writers, documentation teams,
> trainers..

Yes i think that users who are new to menus (e.g. Benjamin) will appreciate that items are logically grouped together and well labelled. I also think that users who regularly use the menus (e.g. Eve) will benefit by having more frequently used entries closer to the top of the menu, as well as possibly learn shortcuts for newly added entries that they frequently use.

> Some comments:
> 
> Edit
> Merge document is a function limited to documents with tracked changes. It
> must
> be in that sub menu.

All three entries - Track Changes, Compare Document and Merge Document - are track change related and are grouped together. All entries that are related to making track changes to the current document are in the submenu and all entries that deal with track changes by using separate files are outside of the submenu.

> What happened to Edit > Fields / Footnote/Endnote / Index entry /
> Bibilograohy entry / Hyperlink? I don't see them.

Those were removed as their functionality is easily accessible in the context menu and they clutter up the Edit menu. Is there an important reason to have them their that you are aware of?

> View
> 
> Pls keep print preview with File > Print.

Print Preview is a view of looking at a document, basically viewing a document similar to how it will be printed without the ability to modify its contents in that view.

> Tools
> What more is on Tools > AutoCorrect? Prolly is now in Format > AutoCorrent?
> Is OK for me.

Yes the Tools > AutoCorrect Options... entry was replace by the Format > AutoCorrect submenu, which contains AutoCorrect Options in it.

(In reply to Joel Madero from comment #10)
> I would also like to know *why* the changes were made. What actual proof do
> we have that this is better other than personal opinions?

See above.

> There have been
> complaints by users and developers that things "change just for change sake"
> and that these changes are made without thinking of the consequences for
> other teams (including documentation which was already mentioned).

These changes are not just for change sake, they are to improve usability. I do take into consideration the translation team when i make changes to strings, as i also work in translation, so i dont change strings unless there is a very good reason to do so.

> @Jay - are you willing to clean documentation to match all of these changes?

No it isnt my intent to go through the documentation to match up these changes, but i'd be happy to work with the documentation team to make their work easier.
Comment 12 Joel Madero 2015-06-03 03:09:48 UTC
In that response I didn't really see any proof - can you raise this at your next design call? I'm just interested in what others think about the mass changes that result in work for other teams that are being pushed (apparently) without a lot of input. I had assumed that design team was discussing these changes but with the comments here, it seems like that is not the case.
Comment 13 Commit Notification 2015-06-03 05:46:10 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=21a6b99748db8a970ef7dc90d40e07901135b89a

tdf#91781 Fix some entry headings

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Yousuf Philips (jay) 2015-06-03 05:51:31 UTC
Created attachment 116249 [details]
Writer's tools menu stats

(In reply to Joel Madero from comment #12)
> In that response I didn't really see any proof - can you raise this at your
> next design call?

What type of proof are you looking for? I have been analyzing the OOo user stats and have spreadsheets per application, similar to what can be seen in the attachment of Writer's tools menu. These spreadsheets are not fully complete yet, but i plan to publish them.

I had discussed this issue previously in a design call with Kendy after going through numerous bug reports with Cor, Andy and the gang about other menu bar submenus and context menus (bug 85945, bug 86048, bug 86048, etc). I will bring up the issue again today at the design call.

> I had assumed that design team was
> discussing these changes but with the comments here, it seems like that is
> not the case.

The design team are discussing these changes, which is why i opened this bug report. They wouldnt be able to fully evaluate these changes if it wasnt available in a daily master build and them taking the new menus for a spin.
Comment 15 Cor Nouws 2015-06-03 06:55:52 UTC
for now: At the moment there are approximately 80-100 million people that will benefit from improvements.
OTOH, in our own community, hundreds of people will have to do a _lot_ of work in documentation. Outside the community prolly thousand will see the same task.
And above all 80-100 million people will have to learn changes. In my experience for a major part that is hard, not to say a PITA.
So improvements for good reasons: yes.

In our past discussions, IMHO part of the changes are such good improvements.
OTOH, for part of the changes I've not been convinced for the rationale. Different logic and considerations are used in a mix and lead to IMO not rationale results.

I've brought into discussion in the past that a change in one go, would IMO be preferable. For all people involved. OTOH, that is not easy to organize. But we've already had changes in the menu before..
(Now I see a proposed change from the past, that has been reverted because it was based on wrong understanding, is introduced again..)

So good times ahead for discussion.
The people that follow my comments know that I'm not against changes. But indeed rather critical. For good reasons, IMO.
Comment 16 Stanislav Horacek 2015-06-03 10:08:22 UTC
My comment as from a person who updates the Help occasionally:
I really welcome UI changes that are *reasonable* and *discussed*. We've seen a lot of them that were not (e.g. still unfinished Picture → Image, including silly Graphic Styles → Image Styles → Drawing Object Styles → Graphic Styles etc.), but I think the design team now discuss things and does great changes which makes sense, e.g. I like a lot the recent toolbar improvements.

For documenters, it would be helpful to collect the changes on this page (I think no one cares about it nowadays):
https://wiki.documentfoundation.org/Documentation/RecentStringChanges
(Before and after screenshots for the menus would be enough.)

(Btw. the Help is getting more and more outdated and only a systematic change - i.e. conversion to a wiki system - can resurrect it.)

One more point: when I see some removed items mentioned, do you consider that menus can be used also by searching items, like in Ubuntu's HUD? This is a fast and efficient way, regardless how cluttered menus are.
Comment 17 V Stuart Foote 2015-06-03 12:28:16 UTC
None of this is "change-for-changes" sake, and release of 5.0 _is_ the perfect time to be grinding through these UI items in the cause of a better UX.

Jay and Heiko have put a lot of effort and rational thought into all of the menu shuffles--both useability and logical layout.

The amount of work on the UI is daunting, but Jay and Adolfo grind through it, with occasional heavy lifting from one of the devs.

We've known this has major impacts on documentation and built-in help work--but made conscious decision to push on with appropriate UI changes and allow the documentation to lag.

Stanislav is right to mention the Documentation/Recent String changes Wiki -- we've been lax in adding changes there for the Documentation team to pickup. Oliver H's bug 80430 "LOCALHELP: Features x Documentation gap meta issue" is the other where substantive issues need to be cross posted.

That said, we press on trusting that the most impacted l10n/i18n efforts remain on track--and would ask that folks spend at least a few cycles on issues affecting the built-in Help and its HTML delivery.

Unfortunately the folks who get shafted are the dedicated few working the Documentation side--sorry for them, but it has always been so with LO timed releases.
Comment 18 Heiko Tietze 2015-06-03 13:45:20 UTC
Terrific work, Jay! And a lot of nitpicking from my side for both https://bugs.documentfoundation.org/show_bug.cgi?id=91820 and Writer here.

Summary: 

The menu would become easier to understand if groups had a caption, just as suggested for the toolbar. Since that's not possible yet we should discuss to improve the lengthy Writer>Insert by splitting stuff into an extra menu similar to the suggested Sheet for Calc. 
For some items the icon isn't helpful others could benefit if one is added. 
And finally I'd recommend to have the meta discussion whether or not to update menus in an umbrella ticket. 

En detail:

File
* perhaps Wizard and Templates without separator as part of the section above
* Reload and Version downto Properties (places Export closer to Save); all four items could be moved into a submenu 'Advanced'
* Isn't „Save a copy“ similar to „Save as...“?
* Preview in Browser to View preview section

Edit
* Select All always on top of the section (→ writer toolbar)
* Is 'Merge Documents…' really that important to have it on the first level?
* 'Select Text': is that 'Select Text Area Only'? (double checked the LO wiki); could go into the  mode submenu with a separator to the actual modes
* 'Exchange database' doesn't it belongs to bibliography?
* 'Plug in' rather 'Allow to edit plugins' is a toogle item but with the icon the state is not clear; I'd remove the icon here and make it a check menu item (cf. View menu); it could be placed next to the edit mode item
* Object is disabled but as a container of subitems it shouldn't
* ImageMap – no idea about the function and camel case; wiki „Allows you to attach URLs to specific areas, called hotspots, on a graphic or a group of graphics.„ So why not have a submenu links that contains of 'Hyperlink' (the current Link) plus 'Arealink' (the ImageMap stuff)
* (Insert) Hyperlink and Edit > Link use the same dialog – we could also remove it here

View
* both calc and writer have exclusive views/layouts but you show checkboxes and icons; should be a radio menu item without icons
* sequence of items at the Calc toolbar should be equal to Writer (-> Status Bar)
* Toogle items for Writer (field stuff) have icons that again makes reading of the state difficult; Navigator and Data Sources have own frames so the icon is okay there (needs to be added to the guideline)
* Table boundaries has a duplicate at Table; remove it here
* Comments could go to the Edit > (changes section) or below Insert > Comment
* Hide images reverts the usual view functions; [x] Show images is better
* 'Sidebar' should get a real name and an icon (toggle button) to align it with the other items in this section
* 100% Zoom at the top level perhaps

Insert (Writer)
* Formatting marks belong to the same section as page and manual break
* Document is not that important; move it below Object
* Section… - never heard about ;-) - and the envelope are something like a textbox
* All together I'm a little bit lost here since naming/classification the sections is not easy; this menu is too large
Insert (Calc)
* Hyperlink is part of the section with text box; should get aligned
* Names one level down under Objects

Format
* Looks like a heavy multipurpose menu (I'm looking onto the screenshots only) – no idea what's below Text - but is there a difference between Number Format and Lists?
* I wonder if users do Insert object and Edit or Format it later; As a working hypothesis, Edit seems to be somehow related to operations/functions and Format to the content → double check content
* Anchor is an important function that could be supported by an icon just like for Alignment

Format (Calc)
* Character, Paragraph, Page: Are those needed on the top level or can they get moved below Text, for instance
* Where are the Wrap and Rotate submenus?
Sheet (Calc)
* Link to External Data is somewhat lost between the Sheet options; Isn't it better located at Data > streams, source?
* I would place the sheet handling functions (move, hide, rename, protect etc.) into a submenu; separation looks artificial
* For Writer this menu would be Page and could clean up the Insert menu

Table (Writer)
* Single Table Properties could be moved up to the first section; otherwise it's kind of a pattern (or could become that) to have access to the generic property dialog at the menu footer (cf. Edit)

Data (Calc)
* I use Pivot a lot and would like to start it directly from an extra section (but ignore individual wishes)
* Statistics are shortcuts to functions (Insert menu)
* Consolidate (never used that) seems to be something like Pivot tables

Tools (Calc)
* Protect and Share sheets into the Sheets menu
* Solver is similar to Consolidate, IMHO
Tools (Writer)
* Footnote and Endnote are frequently used and better placed under Insert (or a new Page menu); Insert contains of such a submenu in your proposal
* Sort, Calculate – if those belong to tables move it there
* Update is a again something I'd look for at the objects; not sure what to do here
Comment 19 Heiko Tietze 2015-06-03 13:54:03 UTC
+Summary: Noticeable is that we use the top level menus for actions not objects. For instance, Insert image, View images, and Edit/Format image (e.g. rotate). Not sure if users understand this, neither if any other structure would be better.
Comment 20 Joel Madero 2015-06-03 14:55:31 UTC
The last thing I want to do is stand in the way of the people who do - but I *do* want to protect the people downstream who have to do a bunch of work every time a change is made and these menu changes seem to be a weekly occurrence these days. I know there's another one planned for calc (I was poked by Jay about it for my feedback).

So this is not a rant against Jay (or any other person doing work), instead it's an attempt to find some middle ground so we're not pushing weekly changes that result in a ton of work on other teams.

Is *anyone* willing to help documentation team with these things? I was a bit confused about Jay just saying absolutely not....as these are his changes I'm not sure what the big deal about him helping documentation would be. 

As a last word, you all know how much I appreciate your work, even if I poke holes in efforts some times it's only because you guys are the heavy lifters doing a lot of the work so of course some of the "blame" (not really blame, but complaints) are going to go your way. Hopefully you take it as a compliment and my sincere appreciation :-b
Comment 21 Yousuf Philips (jay) 2015-06-03 21:42:16 UTC
Just to clarify, when you are referring to the documentation team, they are the team involved in updating the libreoffice user guides ( http://www.libreoffice.org/get-help/documentation/ ) or are they the team that work on the help.
Comment 22 Yousuf Philips (jay) 2015-06-03 23:48:21 UTC
Created attachment 116268 [details]
writer menu bar from 4.3

For those who arent running master, here is the 4.3 menu bar as a before comparison as i had made changes to the menu bar in 4.4.

The issue was brought up during the design meeting today and kendy invited me to tomorrow's ESC meeting to discuss it further.
Comment 23 Joel Madero 2015-06-04 00:33:55 UTC
I mean any and all documentation that needs to be updated because of these changes. As far as I know when developers implement something (which this is development) they are responsible for documenting those implementations. I could be wrong - but I'm going to remove myself from CC on this one as the changes were made and it's outside of my area. I'm just concerned that mass UX changes are happening without input (Cor, Adolfo, and even Heiko seemed to be unaware of this pretty significant change) which creates work for others....worries me. That's about all I can say though - you did the work, as the doer, you can continue "doing" ;)
Comment 24 sophie 2015-06-04 06:29:36 UTC
Hi all, 
I will not discussed the menu right now because I didn't check the changes. My concern and it is a deep one is about the help files. If nobody cares about it, why do we provide help files at all. It's easy to say that it's the documentation team problem, when I have repeatedly said it's the implementer job and the reality is that at no moment someone discuss it with the Doc team. We are killing a big part of our product quality by just ignoring it. 
This problem is not related only to the Design team work, but Design is part of it however.
Comment 25 Cor Nouws 2015-06-04 07:10:30 UTC
Just as an example of how difficult it is to find a balanced rationale mix of all arguments:

(In reply to Yousuf (Jay) Philips from comment #11)
> (In reply to Cor Nouws from comment #9)

> > Some comments:

> > What happened to Edit > Fields / Footnote/Endnote / Index entry /
> > Bibilograohy entry / Hyperlink? I don't see them.
> 
> Those were removed as their functionality is easily accessible in the
> context menu and they clutter up the Edit menu. Is there an important reason
> to have them their that you are aware of?

At other places we have also seen items being removed from the context menu and added to the menu bar.

> > View
> > 
> > Pls keep print preview with File > Print.
> 
> Print Preview is a view of looking at a document, basically viewing a
> document similar to how it will be printed without the ability to modify its
> contents in that view.

It breaks with the principle to bundle related functions: print and print preview.
Comment 26 Cor Nouws 2015-06-04 07:21:18 UTC
(In reply to Yousuf (Jay) Philips from comment #11)
> (In reply to Cor Nouws from comment #9)

> > Edit
> > Merge document is a function limited to documents with tracked changes. It
> > must be in that sub menu.
> 
> All three entries - Track Changes, Compare Document and Merge Document - are
> track change related and are grouped together. All entries that are related
> to making track changes to the current document are in the submenu and all
> entries that deal with track changes by using separate files are outside of
> the submenu.

This argument is broken. Merge document needs to be applied to two versions of the same file with changes tracked.
Compare https://help.libreoffice.org/Common/Merging_Versions
and https://help.libreoffice.org/Common/Comparing_Versions_of_a_Document

This special example has the potential of making people suspicious on motivation and rationale.
This very change was first proposed based on improper understanding. After being pointed to the proper information in the Help (twice), another argument for the change was given. Again wrong. Then in the mean time others got convinced based on that wrong argument (and prolly that the workers must not be blocked to much). The change was reverted. Now again a new argument is found for that change. And again not a solid
one. I find this rather insulting personally.
Comment 27 Cor Nouws 2015-06-04 07:26:34 UTC
Some general remarks about 'work versus commenting"

It is _good_ to give detailed comments. No need to apologize. Nor to label them as nitpicking or something like that. 
After all, reviewing and commenting proposed changes is work too. It helps to prevent errors.

I think that it is reasonable to see as a rule of thumb that you prepare four changes and that two are accepted as improvement.
That should not be considered a waste of time for the two others. If you
prepared only two, maybe just one would become effective ;)
Comment 28 Stanislav Horacek 2015-06-04 07:28:45 UTC
> My concern and it is a deep one is about the help files. If nobody cares
> about it, why do we provide help files at all.

Sorry for going off-topic - nobody cares about creating help, users care about and use it a lot:))

I think we must live with the simple fact that developers will not update the Help, they can't be forced to do so. And as I wrote, I see the only way in Help conversion to wiki system - it could involve hundreds of users who want to improve the Help and are able to edit wiki. (I even think that TDF should solve this - maybe by funding?)
Comment 29 Cor Nouws 2015-06-04 07:34:42 UTC
General about the process:

These UI changes must IMO maybe be handled with greater care then incompatible API changes, since many more people are affected.

We must realize that many people working on e.g. documentation are pretty over loaded with work, often for various projects. Therefore getting people involved in discussions early, is difficult (see l10n).

To facilitate a good discussion, evaluation etc of a change of the whole menu structure as easy as reasonably possible, I would consider a single document, with rationale, explanation and discussion of every change appropriate, eh, helpful.

And if we, as whole team, are not able to organize the (full) process properly, then we face the question: is it such an important change to make now, that we accept the risk of breakage that must be solved over a longer period of time, or can it be done later, with ore preparation?
Comment 30 sophie 2015-06-04 07:45:00 UTC
(In reply to Stanislav Horacek from comment #28)
> > My concern and it is a deep one is about the help files. If nobody cares
> > about it, why do we provide help files at all.
> 
> Sorry for going off-topic - nobody cares about creating help, users care
> about and use it a lot:))
> 
> I think we must live with the simple fact that developers will not update
> the Help, they can't be forced to do so. And as I wrote, I see the only way
> in Help conversion to wiki system - it could involve hundreds of users who
> want to improve the Help and are able to edit wiki. (I even think that TDF
> should solve this - maybe by funding?)

I'll bring the topic to the Board. Be aware however that the help will never be edited by hundred of users because it would break the l10n work. So only few will be able to edit the wiki when it will be ported to it (which has for the moment several technical problems and also l10n issues so we are not close to this solution). Sophie
Comment 31 sophie 2015-06-04 08:33:18 UTC
(In reply to Cor Nouws from comment #29)
> General about the process:
> 
> These UI changes must IMO maybe be handled with greater care then
> incompatible API changes, since many more people are affected.
> 
> We must realize that many people working on e.g. documentation are pretty
> over loaded with work, often for various projects. Therefore getting people
> involved in discussions early, is difficult (see l10n).
> 
> To facilitate a good discussion, evaluation etc of a change of the whole
> menu structure as easy as reasonably possible, I would consider a single
> document, with rationale, explanation and discussion of every change
> appropriate, eh, helpful.
> 
> And if we, as whole team, are not able to organize the (full) process
> properly, then we face the question: is it such an important change to make
> now, that we accept the risk of breakage that must be solved over a longer
> period of time, or can it be done later, with ore preparation?

I agree with you. What is frightening me also is that some changes are made without a full knowledge of the functionality with the risk to lose part of it (which already happened unfortunately). That should be a pre-requisite to have a full knowledge and overview of a function before modifying it. Sophie
Comment 32 Cor Nouws 2015-06-04 08:48:53 UTC
(In reply to sophie from comment #31)

> I agree with you. What is frightening me also is that some changes are made
> without a full knowledge of the functionality with the risk to lose part of
> it (which already happened unfortunately). That should be a pre-requisite to
> have a full knowledge and overview of a function before modifying it. Sophie

Indeed.
Also I think it is a good attitude to realize that the past design of menu etc has been done by full time professionals, so that understanding of the choices they made, helps with preparing changes.
Comment 33 Yousuf Philips (jay) 2015-06-04 10:13:02 UTC
(In reply to Cor Nouws from comment #25)
> > > What happened to Edit > Fields / Footnote/Endnote / Index entry /
> > > Bibilograohy entry / Hyperlink? I don't see them.
> > 
> > Those were removed as their functionality is easily accessible in the
> > context menu and they clutter up the Edit menu. Is there an important reason
> > to have them their that you are aware of?
> 
> At other places we have also seen items being removed from the context menu
> and added to the menu bar.

The context menu is for quick access to frequently used functions and shouldnt contain ever possible function, which is the job of the menu bar. The HIG states that all functions should be accessible in the menu bar, so on that basis they do deserve to be in the menu bar, but the HIG also states that we should attempt to keep the menu bar entries to 20, which is why i had removed them as Edit > Hyperlink is no different that Insert > Hyperlink or clicking on the Hyperlink button in the toolbar or Context Menu > Edit Hyperlink. If it is preferred to have them, then ideally we should make a submenu for them. Any suggestion on how to title them?

> > > View
> > > 
> > > Pls keep print preview with File > Print.
> > 
> > Print Preview is a view of looking at a document, basically viewing a
> > document similar to how it will be printed without the ability to modify its
> > contents in that view.
> 
> It breaks with the principle to bundle related functions: print and print
> preview.

I do agree that it breaks the principle of bundling related functions, when its in the File menu. Heiko has also expressed that it would be preferable to have it in the View menu. @Stuart, do you have a preference of this?
Comment 34 Yousuf Philips (jay) 2015-06-04 11:25:13 UTC
(In reply to Heiko Tietze from comment #18)
> Terrific work, Jay! And a lot of nitpicking from my side for both
> https://bugs.documentfoundation.org/show_bug.cgi?id=91820 and Writer here.

Thanks heiko for the suggestions. It was great to go through them with you yesterday after the design meeting and i've put in a patch for the fixes.

https://gerrit.libreoffice.org/16067

(In reply to Joel Madero from comment #20)
> The last thing I want to do is stand in the way of the people who do - but I
> *do* want to protect the people downstream who have to do a bunch of work
> every time a change is made and these menu changes seem to be a weekly
> occurrence these days. I know there's another one planned for calc (I was
> poked by Jay about it for my feedback).

To clarify, I havent made any menu bar changes in quite some time, unless it was moving entries from the context menu into the menu bar. I would assume downstream doesnt have to do a bunch of work every time a change is made, they do it when a UI and string freeze is put in on a branched version.

> Is *anyone* willing to help documentation team with these things? I was a
> bit confused about Jay just saying absolutely not....as these are his
> changes I'm not sure what the big deal about him helping documentation would
> be. 

My statement was the i wouldnt do it myself, i do not have the knowledge, but would assist the documentation team to make it easier for them to do it. For everyone, time is limited and i need to focus my time on ui and ux, as that is where i believe libreoffice needs the most attention, and i'm lucky enough to have knowledge in that area and have a great team around me.

> As a last word, you all know how much I appreciate your work, even if I poke
> holes in efforts some times it's only because you guys are the heavy lifters
> doing a lot of the work so of course some of the "blame" (not really blame,
> but complaints) are going to go your way. Hopefully you take it as a
> compliment and my sincere appreciation :-b

Well i didnt get many complaints for improving the toolbars, so i'm looking forward to the complaints of the menu bar changes. :D
Comment 35 Yousuf Philips (jay) 2015-06-04 11:37:19 UTC
(In reply to Stanislav Horacek from comment #16)
> My comment as from a person who updates the Help occasionally:
> I really welcome UI changes that are *reasonable* and *discussed*. We've
> seen a lot of them that were not (e.g. still unfinished Picture → Image,
> including silly Graphic Styles → Image Styles → Drawing Object Styles →
> Graphic Styles etc.), but I think the design team now discuss things and
> does great changes which makes sense, e.g. I like a lot the recent toolbar
> improvements.

Glad that you like it. :D

> For documenters, it would be helpful to collect the changes on this page (I
> think no one cares about it nowadays):
> https://wiki.documentfoundation.org/Documentation/RecentStringChanges
> (Before and after screenshots for the menus would be enough.)

I normally do add changed strings there, but just incase i forgot, i'll go through all my commits to see if there are any that i left out.

> One more point: when I see some removed items mentioned, do you consider
> that menus can be used also by searching items, like in Ubuntu's HUD? This
> is a fast and efficient way, regardless how cluttered menus are.

My goal of improving the toolbars is that regular users would never have to open the menu bar, while advanced users are more likely to use shortcut keys and already know the layout of the menu bar, so searching the menu bar has less and less importance. But the option t being able to search the menu bar should still be something to take into consideration, which is another reason to keep those entries in the Edit menu.

(In reply to Joel Madero from comment #23)
> I mean any and all documentation that needs to be updated because of these
> changes. As far as I know when developers implement something (which this is
> development) they are responsible for documenting those implementations. I
> could be wrong - but I'm going to remove myself from CC on this one as the
> changes were made and it's outside of my area. I'm just concerned that mass
> UX changes are happening without input (Cor, Adolfo, and even Heiko seemed
> to be unaware of this pretty significant change) which creates work for
> others....worries me. That's about all I can say though - you did the work,
> as the doer, you can continue "doing" ;)

Yes the changes are made and incrementally will be improved with more feedback from the team, which is why i opened this bug report. So you can be at ease that the same type of benefits you are enjoying in the toolbar, you'll also enjoy in the menu bar. Or maybe not :P
Comment 36 Yousuf Philips (jay) 2015-06-04 12:39:19 UTC
(In reply to Cor Nouws from comment #26)
> This argument is broken. Merge document needs to be applied to two versions
> of the same file with changes tracked.
> Compare https://help.libreoffice.org/Common/Merging_Versions
> and https://help.libreoffice.org/Common/Comparing_Versions_of_a_Document

The real argument here is if Edit > Compare Documents relates to track changes, which it does, so why are you not suggesting that it also be placed under Edit > Track Changes.

> This very change was first proposed based on improper understanding. After
> being pointed to the proper information in the Help (twice), another
> argument for the change was given. Again wrong. Then in the mean time others
> got convinced based on that wrong argument (and prolly that the workers must
> not be blocked to much).

Yes this change was proposed in bug 85046. Though i may not had fully understanding of it when i proposed it, it was clear that the behaviour of the entries in the Edit > Track Changes submenu were all aligned except for Merge Document. Sophie, heiko and kendy also agreed with the change.

> The change was reverted. Now again a new argument
> is found for that change. And again not a solid
> one. I find this rather insulting personally.

You reverted the change, though you were the only one that disagreed with the change and i felt insulted but conceded pursuing it further at that time as i knew it the best way to deal with the menu bar was with a full overhaul.

(In reply to sophie from comment #31)
> I agree with you. What is frightening me also is that some changes are made
> without a full knowledge of the functionality with the risk to lose part of
> it (which already happened unfortunately). That should be a pre-requisite to
> have a full knowledge and overview of a function before modifying it. Sophie

Yes i have tried to refrain from making changes that i dont fully understand and the OOo stats dont give me enough guidance about.

(In reply to Cor Nouws from comment #32)
> Also I think it is a good attitude to realize that the past design of menu
> etc has been done by full time professionals, so that understanding of the
> choices they made, helps with preparing changes.

I do not believe that the design of the menu was done with that much of understanding and was simply done to resemble microsoft office's menus. This was the same for the toolbars.
Comment 37 V Stuart Foote 2015-06-04 13:53:54 UTC
(In reply to Yousuf (Jay) Philips from comment #33)

> I do agree that it breaks the principle of bundling related functions, when
> its in the File menu. Heiko has also expressed that it would be preferable
> to have it in the View menu. @Stuart, do you have a preference of this?

Currently on the View menu the Layout actions--Print Layout, Web Layout, and HTML Source (when editing an LO .html document)--are all _editing_ modes. Placement there suggests that Print Preview is also an editing mode. It is not and so might not belong as placed. 

But if the preview actually reflected how document would be "rendered", responding to the currently specified printer settings I can see the argument for that--or as Heiko suggests better in a Previews grouping on the View menu. 

Status quo, as a Preview of an action to Print it is an _output_. Those actions currently all reside on the File menu, where grouping with the Print and Printer Settings would remain logical. Where, besides the cluster of Print actions, the other Export _output_ buttons are located. Along with the "Preview in Web Browser" that could logically be repositioned on the View menu as Heiko suggests.

As a sidebar--this incremental process of UI/UX transition will simply take time to sort through. It won't really affect the 5.0 release. But these major UI changes should have been done prior to that major milestone, they instead will affect 5.1 or even a 6.0--IMO for issues of the UI we really should have remained at 4.x and have a 4.5 incremental pending, calling it a 5.0 release is premature but guess that is moot. We definitely need more folks working actively at this--reviewing the daily builds, commenting on, and committing appropriate changes. 

@Kendy, since you architected the lash-up for the embedded portions of WikiHelp/HC2 can you figure some way to mentor us on getting the UI changes into the .xhp text strings so we don't corrupt the documentation excessively and give the l10n/i18n side a fighting chance of keeping up.
Comment 38 Commit Notification 2015-06-04 16:14:24 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=76a9afc9da110dbf3a00a628311a0b5d9aa6d2bc

tdf#91781 Changes based on discussion of heiko suggestions

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 39 Yousuf Philips (jay) 2015-06-04 16:39:53 UTC
(In reply to V Stuart Foote from comment #37)
> Currently on the View menu the Layout actions--Print Layout, Web Layout, and
> HTML Source (when editing an LO .html document)--are all _editing_ modes.
> Placement there suggests that Print Preview is also an editing mode. It is
> not and so might not belong as placed. 

Considering them to be editing modes isnt correct because if you are in print or web layout and deactivate editing (Edit > Edit Mode), then you are only viewing the document in the particular layout.

> But if the preview actually reflected how document would be "rendered",
> responding to the currently specified printer settings I can see the
> argument for that--or as Heiko suggests better in a Previews grouping on the
> View menu. 
>
> Status quo, as a Preview of an action to Print it is an _output_. Those
> actions currently all reside on the File menu, where grouping with the Print
> and Printer Settings would remain logical. Where, besides the cluster of
> Print actions, the other Export _output_ buttons are located. Along with the
> "Preview in Web Browser" that could logically be repositioned on the View
> menu as Heiko suggests.

Spoke with Heiko yesterday about 'Preview in Web Browser' and it behaves similar to exporting the document as an html and opening the file in a browser, or taken another way - Send to Web Browser, which isnt a way of viewing a document inside of LO, like you can with HTML Source.

> As a sidebar--this incremental process of UI/UX transition will simply take
> time to sort through. It won't really affect the 5.0 release. But these
> major UI changes should have been done prior to that major milestone, they
> instead will affect 5.1 or even a 6.0--IMO for issues of the UI we really
> should have remained at 4.x and have a 4.5 incremental pending, calling it a
> 5.0 release is premature but guess that is moot. We definitely need more
> folks working actively at this--reviewing the daily builds, commenting on,
> and committing appropriate changes. 

It would have been nice to have focused on improving the menu bar earlier but i had to clean up the context menus first to gather many of the missing commands found in the context menus that werent in the menu bar. The ESC has okayed pushing this into 5.0 as its a major release and of course it can be polished during the 5.x cycle.
Comment 40 Adolfo Jayme 2015-06-05 04:33:44 UTC
> The ESC has
> okayed pushing this into 5.0 as its a major release and of course it can be
> polished during the 5.x cycle.

“And of course it can be polished during the 5.x cycle”.

WHAT? So the ESC no longer cares about the UI freeze, about translators, about documenters?
Comment 41 Commit Notification 2015-06-05 06:01:43 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d304dd4db35c79a33bdf118e45e0675d2d86f51d

tdf#91781 Restoring Edit entries under a new submenu and change view names

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 42 Yousuf Philips (jay) 2015-06-05 10:02:33 UTC
(In reply to Adolfo Jayme from comment #40)
> WHAT? So the ESC no longer cares about the UI freeze, about translators,
> about documenters?

I assume they do care about the UI freeze, translators and documenters, as the UI freeze is to happen in around 2 weeks - Week 25 , Jun 15, 2015 - Jun 21, 2015.

https://wiki.documentfoundation.org/ReleasePlan/5.0#5.0.0_release
Comment 43 V Stuart Foote 2015-06-05 14:00:39 UTC
(In reply to Adolfo Jayme from comment #40)

> WHAT? So the ESC no longer cares about the UI freeze, about translators,
> about documenters?

Of course they do, see the ref June 4th ESC minutes.

The discussions around

* Menu changes / help & documentation handling (Jay / Sophie)

Outcome of that is a major rework of Help, and a revert of any "lost" function in the menu/toolbar rework in time for the 5.0 release. But they're in otherwise.

Sophi doesn't say it but assume she'll work that into a MozTrap sequence for guided review.

=-ref-=
http://nabble.documentfoundation.org/minutes-of-ESC-call-tc4150562.html
https://wiki.documentfoundation.org/Documentation/RecentStringChanges
Comment 44 Yousuf Philips (jay) 2015-06-05 19:54:25 UTC
(In reply to V Stuart Foote from comment #43)
> Outcome of that is a major rework of Help, and a revert of any "lost"
> function in the menu/toolbar rework in time for the 5.0 release. But they're
> in otherwise.

Doubt there would be major rework of Help, but kendy is speaking with olivier to see how we can fix the current problems with help as it is presently until a time when we can fully move to a wikihelp.

> Sophi doesn't say it but assume she'll work that into a MozTrap sequence for
> guided review.

Sophie is currently going through all the changes to make sure that she is okay with them and i'm working with her to answer any questions that she may have about it.

The ESC suggested that it would be good to have these changes in the beta 2 release, so users can try it out. If anyone has any comments on any of the strings that have been changed or the repositioning of an entry or submenu to another menu, please do try out the menus in a daily build and let me know.
Comment 45 sophie 2015-06-06 06:57:34 UTC
(In reply to Yousuf (Jay) Philips from comment #44)
> (In reply to V Stuart Foote from comment #43)
> > Outcome of that is a major rework of Help, and a revert of any "lost"
> > function in the menu/toolbar rework in time for the 5.0 release. But they're
> > in otherwise.
> 
> Doubt there would be major rework of Help, but kendy is speaking with
> olivier to see how we can fix the current problems with help as it is
> presently until a time when we can fully move to a wikihelp.

You said during ESC that you will modify the help accordingly to your changes, if not, commits will be reverted.
> 
> > Sophi doesn't say it but assume she'll work that into a MozTrap sequence for
> > guided review.
> 
> Sophie is currently going through all the changes to make sure that she is
> okay with them and i'm working with her to answer any questions that she may
> have about it.

For the moment, we are discussing Tools > Sort and Edit > Links you wanted to remove, I hope you have reverted that commit, but I'll check today.
> 
> The ESC suggested that it would be good to have these changes in the beta 2
> release, so users can try it out. If anyone has any comments on any of the
> strings that have been changed or the repositioning of an entry or submenu
> to another menu, please do try out the menus in a daily build and let me
> know.

If the help is modified and if there is no other functionality lost, it will be in Beta2. Of course we won't play commit and revert at this moment and give more work than needed to l10n team. 
To answer Adolfo concerns, there will be no string changes in minor versions as usual, rules remains unchanged.
Comment 46 Yousuf Philips (jay) 2015-06-06 09:29:20 UTC
(In reply to sophie from comment #45)
> > Doubt there would be major rework of Help, but kendy is speaking with
> > olivier to see how we can fix the current problems with help as it is
> > presently until a time when we can fully move to a wikihelp.
> 
> You said during ESC that you will modify the help accordingly to your
> changes, if not, commits will be reverted.

I had stated in ESC that i didnt have the skills to modify the help, though i'm willing to try. The changes have only been pushed into master, so there isnt anything to revert.

> > Sophie is currently going through all the changes to make sure that she is
> > okay with them and i'm working with her to answer any questions that she may
> > have about it.
> 
> For the moment, we are discussing Tools > Sort and Edit > Links you wanted
> to remove, I hope you have reverted that commit, but I'll check today.

Yes Tools > Sort has been reverted and I think Table > Sort should then be removed, as Tools > Sort handles both scenarios or else we should find a more suitable label for Tools > Sort. Yes the various entries in Edit (fields, footnote/endnote, index entry, bibliography entry, hyperlink) have also been reverted and are now found under Edit > Entries, though i'm looking for a more suitable name for the submenu. Anyone have a suggestion?

> > The ESC suggested that it would be good to have these changes in the beta 2
> > release, so users can try it out. If anyone has any comments on any of the
> > strings that have been changed or the repositioning of an entry or submenu
> > to another menu, please do try out the menus in a daily build and let me
> > know.
> 
> If the help is modified and if there is no other functionality lost, it will
> be in Beta2. Of course we won't play commit and revert at this moment and
> give more work than needed to l10n team. 

If the only way these changes will land in Beta2 is if the help is done, then i guess it wont be happening in Beta2, as it will be releasing in the next few days, and there wont be enough time to complete the menu changes and the help by then. As previously stated, nothing has been committed to 5.0.
Comment 47 Heiko Tietze 2015-06-06 09:57:05 UTC
Created attachment 116328 [details]
Separate menu for direct formatting
Comment 48 Heiko Tietze 2015-06-06 09:58:27 UTC
Created attachment 116329 [details]
Separate menu for direct formatting - menu tweak

xml file has to be placed at /.config/libreofficedev/4/user/config/soffice.cfg/modules/swriter
Comment 49 Heiko Tietze 2015-06-06 10:04:51 UTC
Similar to Sheet in Calc and Slide in Presentation we could have another menu in Writer: Text, that contains of all functions for direct formatting. Reason to do so is consistency over programs and a streamlined Format menu. The objection that we want to promote Styles contradicts users' behavior, IMHO. 

The proposal is just an illustration of the idea. Content and labels are matter of discussion. To try it yourself place the xml file in the right directory and restart Writer. You can edit the xml directly (starting with line 451) or via Tool > Customize.
Comment 50 Yousuf Philips (jay) 2015-06-06 11:48:20 UTC
(In reply to Heiko Tietze from comment #49)
> Similar to Sheet in Calc and Slide in Presentation we could have another
> menu in Writer: Text, that contains of all functions for direct formatting.
> Reason to do so is consistency over programs and a streamlined Format menu.

The problem i see with a Text menu is that it would have to appear in all the apps if we wanted consistency and Calc now has Sheet and Data, and impress has Slide and Slide Show. Also with a menu named Text, shouldnt it have everything related to text and not just direct formatting.

Regarding its organization, a direct formatting submenu with some of the font direct formatting features would likely lead to confusion, as users may think only the things under that submenu are considered direct formatting. I think you forgot to include the paragraph... entry in the section with Spacing and Align submenus. :D

> The objection that we want to promote Styles contradicts users' behavior,
> IMHO. 

If we want to promote styles in Writer, then maybe we should have a Styles menu item and pull all the entries out of Format > Styles and place them into it. A menu item like this would also be useful when we finally add style sets and document themes. (bug 90497)
Comment 51 Heiko Tietze 2015-06-07 10:22:44 UTC
Created attachment 116348 [details]
Separate menu for Styles

(In reply to Yousuf (Jay) Philips from comment #50)
> If we want to promote styles in Writer, then maybe we should have a Styles
> menu item and pull all the entries out of Format > Styles and place them
> into it. A menu item like this would also be useful when we finally add
> style sets and document themes. (bug 90497)

Not that bad.
Comment 52 Heiko Tietze 2015-06-07 10:23:47 UTC
Created attachment 116349 [details]
Separate menu for Styles - menu tweak
Comment 53 Commit Notification 2015-06-07 12:27:45 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb3286016c4e34f313a4c5fb7c561c08f582113e

tdf#91781 Addition of new commands not found in the menu bar

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 54 sophie 2015-06-08 09:23:22 UTC
'Entries' should be replaced by something more significant as it assembles very different things like fields and index, etc and it is already used for another functionality.
Comment 55 Yousuf Philips (jay) 2015-06-08 11:56:39 UTC
(In reply to sophie from comment #54)
> 'Entries' should be replaced by something more significant as it assembles
> very different things like fields and index, etc and it is already used for
> another functionality.

I completely agree, but still havent come up with a suitable name. The submenu has Fields, Footnote/Endnote, Index Entry, Bibliography Entry, and Hyperlink, so i thought to possibly have it as 'Links and References' and change the Edit > Links entry to something more meanful as many people refer to hyperlinks as links and Links doesnt fully describe what is it is and should likely be called 'External File Links' or 'Linked Files'.
Comment 56 Cor Nouws 2015-06-10 07:14:34 UTC
(In reply to Yousuf (Jay) Philips from comment #33)
> (In reply to Cor Nouws from comment #25)
>>>> What happened to Edit > Fields / Footnote/Endnote / Index entry /
>>>> Bibilograohy entry / Hyperlink? I don't see them.
>>> 
>>> Those were removed as their functionality is easily accessible in the
>>> context menu and they clutter up the Edit menu. Is there an important 
>>> reason to have them their that you are aware of?
>> 
>> At other places we have also seen items being removed from the context menu
>> and added to the menu bar.
> 
> The context menu is for quick access to frequently used functions and
> shouldnt contain ever possible function, which is the job of the menu bar.
> The HIG states that all functions should be accessible in the menu bar, so
> on that basis they do deserve to be in the menu bar, but the HIG also states
> that we should attempt to keep the menu bar entries to 20, which is why i
> had removed them as Edit > Hyperlink is no different that Insert > Hyperlink
> or clicking on the Hyperlink button in the toolbar or Context Menu > Edit
> Hyperlink. If it is preferred to have them, then ideally we should make a
> submenu for them. Any suggestion on how to title them?

Thanks for explaining.
I would not be able to think of good name for such a mixed category.
But I would give preference to the rule to have all items available in the menu, over the (arbitrary) limit of 20 items. Esp since those items are at the lower side.
Comment 57 Cor Nouws 2015-06-10 07:19:23 UTC
(In reply to Yousuf (Jay) Philips from comment #36)
> (In reply to Cor Nouws from comment #26)
>> This argument is broken. Merge document needs to be applied to two versions
>> of the same file with changes tracked.
>> Compare https://help.libreoffice.org/Common/Merging_Versions
>> and https://help.libreoffice.org/Common/Comparing_Versions_of_a_Document
> 
> The real argument here is if Edit > Compare Documents relates to track
> changes, which it does, so why are you not suggesting that it also be placed
> under Edit > Track Changes.

Maybe that is even a better solution.
But Compare Documents is to use on files with currently no changes tracked and Merge Documents is to combine versions with changes tracked.
And having them separated in the menu, maybe helps people to get the clue.

>> This very change was first proposed based on improper understanding. After
>> being pointed to the proper information in the Help (twice), another
>> argument for the change was given. Again wrong. Then in the mean time others
>> got convinced based on that wrong argument (and prolly that the workers must
>> not be blocked to much).
> 
> Yes this change was proposed in bug 85046. Though i may not had fully
> understanding of it when i proposed it, it was clear that the behaviour of
> the entries in the Edit > Track Changes submenu were all aligned except for
> Merge Document. Sophie, heiko and kendy also agreed with the change.

I propose to bring it back in a meeting where I can attend.
Comment 58 Cor Nouws 2015-06-10 07:21:05 UTC
(In reply to Yousuf (Jay) Philips from comment #36)

> (In reply to Cor Nouws from comment #32)
>> Also I think it is a good attitude to realize that the past design of menu
>> etc has been done by full time professionals, so that understanding of the
>> choices they made, helps with preparing changes.
> 
> I do not believe that the design of the menu was done with that much of
> understanding and was simply done to resemble microsoft office's menus. This
> was the same for the toolbars.

There were enough complaints about differences. And currently we look at othe applications too. So I would propose to adapt a nuanced view here :)
Comment 59 Cor Nouws 2015-06-10 07:24:42 UTC
(In reply to V Stuart Foote from comment #37)
> (In reply to Yousuf (Jay) Philips from comment #33)
> 
>> I do agree that it breaks the principle of bundling related functions, when
>> its in the File menu. Heiko has also expressed that it would be preferable
>> to have it in the View menu. @Stuart, do you have a preference of this?
> 
> Currently on the View menu the Layout actions--Print Layout, Web Layout, and
> HTML Source (when editing an LO .html document)--are all _editing_ modes.
> Placement there suggests that Print Preview is also an editing mode. It is
> not and so might not belong as placed. 

In Calc the print preview is an important place for editing the page settings.
Still, for the close relation to the action of printing, I would think the place with File > Print is more natural.
Comment 60 Yousuf Philips (jay) 2015-06-10 14:44:52 UTC
(In reply to Cor Nouws from comment #56)
> Thanks for explaining.
> I would not be able to think of good name for such a mixed category.
> But I would give preference to the rule to have all items available in the
> menu, over the (arbitrary) limit of 20 items. Esp since those items are at
> the lower side.

Yes i've already added them back and decided to include just footnote/endnote, bibliography entry and index entry in a submenu titled 'References' and leave hyperlink and fields in the first level, as those two entries are in the first level in impress as well.

(In reply to Cor Nouws from comment #57)
> Maybe that is even a better solution.
> But Compare Documents is to use on files with currently no changes tracked
> and Merge Documents is to combine versions with changes tracked.
> And having them separated in the menu, maybe helps people to get the clue.

Both commands would be confusing to regular users if they were taken at face value, i remember going through a bug report which a user filed as he was going to Edit > Changes > Comment thinking it was Insert > Comment. If i saw compare documents, i'd assume it would bring up a dialog and visually display the differences between the two documents. If i saw merge documents, i'd assume it would take the contents of one document and merge the other document to its end. Presently i'm fine either way, moving them both in track changes or having them both out. One benefit of having them in the submenu is that the main menu would be two entries smaller, which would be an advantage in writer, but not that particular in calc.

> I propose to bring it back in a meeting where I can attend.

Look forward to it. We've missed you and Stuart for some time now at the meetings.

(In reply to Cor Nouws from comment #58)
> There were enough complaints about differences. And currently we look at
> othe applications too. So I would propose to adapt a nuanced view here :)

They definitely werent exactly the same, but the similarities were quite easily visible. Compare this with WordPerfect, which has a completely different toolbar layout and quite a different menu. I've tried to be as careful as i can be by primarily focusing on reorganizing within the same menu more than moving things to other menus, as i know people like things where they are and prefer not to relearn. :D

(In reply to Cor Nouws from comment #59)
> In Calc the print preview is an important place for editing the page
> settings.
> Still, for the close relation to the action of printing, I would think the
> place with File > Print is more natural.

Yes the stats do agree with you, as 71% of users click the 'Format Page' button in the print preview toolbar over Format > Page in the menu, but that dont change that it is a way of viewing your document and it is an important view in calc, as normal/grid view doesnt show you how it will look on a printed page.
Comment 61 Jean-Baptiste Faure 2015-06-11 14:59:18 UTC
About Print Preview:

The problem is not to put a function in the more appropriate menu but to put it where the user will find it the most easily.
For the Print Preview the current users are used to find it in the File menu, thus keep it there. If you really think that new users will search this function preferentially in the View menu, then add it there too. 
Redundancy is not a sin. :-) 

Best regards. JBF
Comment 62 Philippe Jung 2015-06-11 19:51:40 UTC
(In reply to Jean-Baptiste Faure from comment #61)
> About Print Preview:
> 
> For the Print Preview the current users are used to find it in the File
> menu, 

I definitely agree: every time I used a software where print preview is not is File menu, I had to search for it.
Comment 63 Marc Pare 2015-06-11 20:31:20 UTC
Hi everyone,

I am also adding my voice to keeping the Print Preview under File. As having used OOo and LibreOffice in a school setting, this is where the kids will find it first. Their first instinct is to look for "Print" and logically speaking "Print Preview" should appear in the same menu column. Students will NOT look under "View" as their line of thinking does not work this way.

I would also say that my 82 year old mother who also uses LibreOffice Calc, from time to time, as treasurer of her club, would really be mixed up if the Print-Preview were moved anywhere else. 

Marc Paré
Comment 64 Yousuf Philips (jay) 2015-06-11 23:52:14 UTC
(In reply to Jean-Baptiste Faure from comment #61)
> Redundancy is not a sin. :-) 

Definitely not a sin, but i try my best not to duplicate commands in the menu. :D

(In reply to Philippe Jung from comment #62)
> I definitely agree: every time I used a software where print preview is not
> is File menu, I had to search for it.

So which softwares have you used that didnt have it there and which menu did they place it in?

(In reply to Marc Pare from comment #63)
> I am also adding my voice to keeping the Print Preview under File. As having
> used OOo and LibreOffice in a school setting, this is where the kids will
> find it first. Their first instinct is to look for "Print" and logically
> speaking "Print Preview" should appear in the same menu column. Students
> will NOT look under "View" as their line of thinking does not work this way.
> 
> I would also say that my 82 year old mother who also uses LibreOffice Calc,
> from time to time, as treasurer of her club, would really be mixed up if the
> Print-Preview were moved anywhere else. 

Its would be quite unfortunate that your students or your mother would be going to the menus for print and print preview, when both of them are in the toolbar.

Well i guess there are more people in disagree with this, so i've put it back to where it was. :D
Comment 65 Commit Notification 2015-06-11 23:55:07 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb9dad2ef23829b2500c9f99154bca6a8ba7d49a

tdf#91781 Make Styles a new main menu bar entry and small rearrangments

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 66 Jean-Baptiste Faure 2015-06-12 04:40:19 UTC
(In reply to Yousuf (Jay) Philips from comment #64)
> (In reply to Jean-Baptiste Faure from comment #61)
> > Redundancy is not a sin. :-) 
> 
> Definitely not a sin, but i try my best not to duplicate commands in the
> menu. :D

Why ? We have duplication for toolbars, why not in menu? When you open a new empty document with a new clean user profile, you have both sidebar/properties and formatting toolbar. There is several other toolbar duplications.

Best regards. JBF
Comment 67 Heiko Tietze 2015-06-12 07:51:35 UTC
(In reply to Jean-Baptiste Faure from comment #66)
> (In reply to Yousuf (Jay) Philips from comment #64)
> > (In reply to Jean-Baptiste Faure from comment #61)
> > > Redundancy is not a sin. :-) 
> Why ? We have duplication for toolbars, why not in menu?

Redundancy is a good thing as it offers several ways of access to functions in terms of casual users like Benjamin and power users like Eve. Both are free to Copy by keyboard, context menu, toolbar, or main menu. 

Duplicates in menus, on the other hand, do not add another way of interaction. Quite contrary, users might get confused whether or not the entries have different options - just like us regarding Sort... (which have to get renamed, by the way). So I would add this as the 11th commandment: "Thou shalt not have duplicates in menus." (to be added to the HIG?)

Regarding the issue: Can we solve the Print <Preview> problem by renaming the function? Another solution would be to always show the preview before printing (would be weird however). We discussed this but I don't remember the outcome.
Comment 68 Jean-Baptiste Faure 2015-06-13 20:33:56 UTC
in master / Writer the menu File > Templates > Manage opens the Form design toolbar
Not sure if it is a bug in this reorganization or if the root cause is elsewhere. Indeed in my build of LO 5.0 beta3, the same menu opens the media playback toolbar in a French UI and the Form Design toolbar in the EN UI).

Best regards. JBF
Comment 69 Yousuf Philips (jay) 2015-06-13 23:30:16 UTC
(In reply to Jean-Baptiste Faure from comment #66)
> Why ? We have duplication for toolbars, why not in menu?

Where do we have duplication in the toolbars?

> When you open a new
> empty document with a new clean user profile, you have both
> sidebar/properties and formatting toolbar.

The sidebar is not open by default in a new clean user profile, so there isnt duplication there. Users who prefer to use the sidebar for properties over the formatting toolbar will likely disable the formatting toolbar because of this duplication.

(In reply to Heiko Tietze from comment #67)
> just like us regarding Sort... (which have to get renamed, by the way).

I have asked Sophie about this but unfortunately she hasnt replied yet.

> So I would add this as the 11th commandment:
> "Thou shalt not have duplicates in menus." (to be added to the HIG?)

He said it was a sin, so you are making it a sin. ;)

> Regarding the issue: Can we solve the Print <Preview> problem by renaming
> the function?

It used to be called 'Page Preview' and i changed it to 'Print Preview' in 4.4. Print Preview had a major benefit in the old MS Word days when the default view wasnt a view that looked similar to now it was printed, which is what we use today.

> Another solution would be to always show the preview before
> printing (would be weird however). We discussed this but I don't remember
> the outcome.

Alot of users are used to jumping into print preview before they open the print dialog and the dialog also has a preview in it as well. I dont think it would be a good idea to force users into a particular workflow for printing.

(In reply to Jean-Baptiste Faure from comment #68)
> in master / Writer the menu File > Templates > Manage opens the Form design
> toolbar

Works fine for me on master and i doubt reorganization entries in the menu xml would affect how a function would work.

Version: 5.1.0.0.alpha1+
Build ID: 3754474cdea72ebe7f09457ef82a5c3131d06b78
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-06-13_07:55:37
Comment 70 Cor Nouws 2015-07-02 11:00:29 UTC
(In reply to Yousuf (Jay) Philips from comment #60)

> (In reply to Cor Nouws from comment #57)
> > Maybe that is even a better solution.
> > But Compare Documents is to use on files with currently no changes tracked
> > and Merge Documents is to combine versions with changes tracked.
> > And having them separated in the menu, maybe helps people to get the clue.
> 
> Both commands would be confusing to regular users if they were taken at face
> value, ...

Therefore it is good to have on in the menu Track Changes. And to be more precise: the one that is related to files with changes tracked :)

> ... Presently i'm fine either way, moving them both in
> track changes or having them both out. One benefit of having them in the
> submenu is that the main menu would be two entries smaller, which would be
> an advantage in writer, but not that particular in calc.

Both in, is less bad then both out. But as you indicated yourself, there is some confusion if one does not know what is does. Splitting over the proper places, helps. The user sees: Track Changes .. Merge Document. (Hmm could that be to merge documents with changes tracked??)
After all, the initial idea to move 'Merge Document' was based on misunderstanding.

> > I propose to bring it back in a meeting where I can attend.
> 
> Look forward to it. We've missed you and Stuart for some time now at the
> meetings.

Sorry for that. Making a special appointment is advised here :)

Ciao,
Cor
Comment 71 Cor Nouws 2015-07-02 11:04:26 UTC
(In reply to Jean-Baptiste Faure from comment #68)
> in master / Writer the menu File > Templates > Manage opens the Form design
> toolbar

I don't see that problem in daily from 2015-06-30. So must be gone :)
Comment 72 Jean-Baptiste Faure 2015-07-02 11:15:37 UTC
(In reply to Cor Nouws from comment #71)
> (In reply to Jean-Baptiste Faure from comment #68)
> > in master / Writer the menu File > Templates > Manage opens the Form design
> > toolbar
> 
> I don't see that problem in daily from 2015-06-30. So must be gone :)

Still there for me in Version: 5.1.0.0.alpha1+
Build ID: c18f11587d37f285a95447dd8996c8b605732e00
built at home under Ubuntu 15.04 x86-64.
I guess the problem is linked to Unity and GTK2.If I use the VCL plugin GTK3 it works as expected. Same problem in LO 5.0 branch.

Best regards. JBF
Comment 73 Cor Nouws 2015-07-02 11:18:14 UTC
(In reply to Jean-Baptiste Faure from comment #72)

(better handle this in a separate issue - sorry that I commented here)
Comment 74 Jean-Baptiste Faure 2015-07-02 18:08:12 UTC
(In reply to Cor Nouws from comment #73)
> (In reply to Jean-Baptiste Faure from comment #72)
> 
> (better handle this in a separate issue - sorry that I commented here)

Already done: bug 92067

Best regards. JBF
Comment 75 Yousuf Philips (jay) 2015-07-04 01:28:57 UTC
(In reply to Cor Nouws from comment #70)
> > Both commands would be confusing to regular users if they were taken at face
> > value, ...
> 
> Therefore it is good to have on in the menu Track Changes. And to be more
> precise: the one that is related to files with changes tracked :)
> 
> > ... Presently i'm fine either way, moving them both in
> > track changes or having them both out. One benefit of having them in the
> > submenu is that the main menu would be two entries smaller, which would be
> > an advantage in writer, but not that particular in calc.
> 
> Both in, is less bad then both out. But as you indicated yourself, there is
> some confusion if one does not know what is does. Splitting over the proper
> places, helps. The user sees: Track Changes .. Merge Document. (Hmm could
> that be to merge documents with changes tracked??)
> After all, the initial idea to move 'Merge Document' was based on
> misunderstanding.

Due to the limited space in the Edit menu, they have been put in the Track Changes submenu. :D
Comment 76 Duago 2015-07-11 13:17:19 UTC
I like how you have reorganized the context menu <b>Except</b> that I always used the font option that was in the right click context menu.
I find it very useful to have a font option(with sub options that appear on mouse over).

I have not seen a place to make this as a request so I am noting it here.
Comment 77 Commit Notification 2015-08-09 15:14:38 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=351c17497e36c5a42fba627043dabaef2e7040eb

tdf#91781 Add additional selection options and go to page to menu

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 78 Commit Notification 2015-08-09 15:24:33 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e5dee3512f5b010b832fcf569d7a3eb60f0f62c

Revert "tdf#91781 Add additional selection options and go to page to menu"

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 79 V Stuart Foote 2015-08-09 16:02:48 UTC
Nothing nasty...this explanation from Maxim M. on gerrit...

"@Jay: Hi, this change breaks the build, so i reverted it.

There are 2 problems with it:

1. You put it in the wrong place in the xml tree (it shouldn't be at the top level).
2. Writer doesn't have those commands."
Comment 80 Charles 2015-09-02 14:27:10 UTC
(In reply to Duago from comment #76)
> I like how you have reorganized the context menu <b>Except</b> that I always
> used the font option that was in the right click context menu.
> I find it very useful to have a font option(with sub options that appear on
> mouse over).
> 
> I have not seen a place to make this as a request so I am noting it here.

Since we can already modify the current Menu toolbars, I'm not too concerned about changes that are made, as anything that really irks me I can change.

But, in my opinion, the Context Menus should have never been modified without first providing your existing users and power users to add things back in that they rely on heavily.

So, I would very much like some support for my new bug 93837, to 'Allow customization of the Context Menus', and hope someone will pick it up and start working on it as something that can be added to 5.1 to remedy this long standing oversight.

Thanks,

Charles
Comment 81 Cor Nouws 2015-09-02 14:36:36 UTC
(In reply to Charles from comment #80)

> But, in my opinion, the Context Menus should have never been modified
> without first providing your existing users and power users to add things
> back in that they rely on heavily.

I consider myself in that category.. but concerns are easily waved ..
Comment 82 Commit Notification 2015-09-20 10:01:54 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=66a7292f2faf51cc0ba018771a5ab25e8d7b5929

tdf#91781 Added character styles and fix labels

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 83 Olivier R. 2015-10-19 07:08:44 UTC
@Yousuf: I think the style menu should also offer the style “Text Body”, which is the style we are supposed to use for the document’s content.
Comment 84 Yousuf Philips (jay) 2015-11-04 00:45:14 UTC
(In reply to Olivier R. from comment #83)
> @Yousuf: I think the style menu should also offer the style “Text Body”,
> which is the style we are supposed to use for the document’s content.

Yes it will be add in the next patch. https://gerrit.libreoffice.org/19765
Comment 85 Olivier R. 2015-11-04 07:28:21 UTC
@Yousuf: Thanks. :)
Comment 86 Commit Notification 2015-11-06 00:25:31 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0644737e00ec2c9127944fbc76b19c8e55d98a3d

tdf#91781 Add Form related commands to insert and tools menus

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 87 Jean-Baptiste Faure 2015-11-08 08:38:25 UTC
(In reply to Yousuf (Jay) Philips from comment #84)
> (In reply to Olivier R. from comment #83)
> > @Yousuf: I think the style menu should also offer the style “Text Body”,
> > which is the style we are supposed to use for the document’s content.
> 
> Yes it will be add in the next patch. https://gerrit.libreoffice.org/19765

Thank you very much for this patch. Remaining issue: it seems you forgot the shortcut keys for Text Body style that is CTRL+0.

Best regards. JBF
Comment 88 Commit Notification 2015-12-06 11:57:51 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=900a22c9ef53d8597570ccd1fa8a7a6106006f32

tdf#91781 Add more shapes to the menu and additional tweaks

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 89 Paul Oranje 2015-12-07 10:11:05 UTC
(In reply to Yousuf (Jay) Philips from comment #39)
> (In reply to V Stuart Foote from comment #37)
> > Currently on the View menu the Layout actions--Print Layout, Web Layout, and
> > HTML Source (when editing an LO .html document)--are all _editing_ modes.
> > Placement there suggests that Print Preview is also an editing mode. It is
> > not and so might not belong as placed. 
> 
> Considering them to be editing modes isnt correct because if you are in
> print or web layout and deactivate editing (Edit > Edit Mode), then you are
> only viewing the document in the particular layout. 

Any preview related to an export of the document, irrespective of the doc being in edit mode or not, only makes sense within the context of the actual export. Also having those previews available only within these contexts helps removing abundant cluttering of the global menu's.

As a sidenote, IMHO, the View menu should never affect the state of a document and strictly only affect how it's seen, or unrelated to a document, which parts of the UI are to be shown. The purposes of the different top menu's should be as orthogonal as much as possible (the extra special edit menu's that offload document type specific edit actions from the general Edit menu (Writer its Insert menu, Impress its Slide menu, etc) are special cases).
Comment 90 Commit Notification 2015-12-07 21:48:39 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5eb75cd21c78fd55f3165ce4af250109a46fefd&h=libreoffice-5-1

tdf#91781 Add more shapes to the menu and additional tweaks

It will be available in 5.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 91 Jean-Baptiste Faure 2015-12-08 08:17:43 UTC
New Format menu is too long. Please try it on a screen 1366x768 with not maximized Writer window.

Best regards. JBF
Comment 92 Yousuf Philips (jay) 2015-12-08 11:17:16 UTC
(In reply to Jean-Baptiste Faure from comment #91)
> New Format menu is too long. Please try it on a screen 1366x768 with not
> maximized Writer window.

As menus will contain all commands, they will be long and are to fit in a maximized window of 1280x768, defined in the HIG.

I tried the menus in a non-maximized window (804x586) and it worked fine.
Comment 93 Commit Notification 2016-02-18 12:06:45 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=39c8d40ddf85903d9ea2b81ae4ca924e91f89cb7

tdf#91781 Move uppercase and lowercase up one level

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 94 Commit Notification 2016-05-31 13:43:25 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=198cba6e9af2d8a2d8d201a8b26d9a835744c659

tdf#91781 A round of minor tweaks to Writer's menus

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 95 Commit Notification 2016-06-02 10:47:51 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=08bb0cf5872c24533312994976969e734d33bcef&h=libreoffice-5-2

tdf#91781 A round of minor tweaks to Writer's menus

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 96 Cor Nouws 2016-06-07 14:10:51 UTC
(In reply to Commit Notification from comment #94)

> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=198cba6e9af2d8a2d8d201a8b26d9a835744c659
> 
> tdf#91781 A round of minor tweaks to Writer's menus
> 
> Affected users are encouraged to test the fix and report feedback.

Yes me :)
A bookmark != a link.
I would suggest keeping Bookmark directly under Insert.
Same for Cross references.
Comment 97 Yousuf Philips (jay) 2016-06-07 14:20:56 UTC
(In reply to Cor Nouws from comment #96)
> Yes me :)
> A bookmark != a link.
> I would suggest keeping Bookmark directly under Insert.
> Same for Cross references.

I would have preferred it in the main folder as well, but space is limited. A bookmark and cross reference is an internal link within a document, which is why the submenu was named 'Link'. If others have a better suggestion to the name of the submenu please let me know.
Comment 98 Cor Nouws 2016-06-07 14:59:40 UTC
(In reply to Yousuf (Jay) Philips from comment #97)

> I would have preferred it in the main folder as well, but space is limited.
> A bookmark and cross reference is an internal link within a document, which
> is why the submenu was named 'Link'. If others have a better suggestion to
> the name of the submenu please let me know.

Sorry for the confusion. Apart from the naming, it's breaking productivity.
The menu already is long. So the two extra ..

If really needed, take the extra "Page Number" out (people expect something else there), add Chart to Object> (not that often used in Writer) :)
Comment 99 Martin Srebotnjak 2016-06-08 09:19:22 UTC
It was announced how 5.1 and in some extent 5.2 brings massive changes to menus, UI, to make it better. The l10n teams said, ok, if this is it, ok.

OK. But it seems now you intend to keep massively change the ui even for 5.3 etc. Every member of UI team who looks at the changes has another N ideas how to make further changes. So please first discuss each menu - all UX members - then decide what will change. This is not AbiWord, it is the leading open source office suite, used by millions of users all over the world.

All online help and manuals, printed and not printed ones, become obsolete the minute you change one of the menu entries.

I think the TDF and especially the l10n teams should give an ultimatum to the UX guys: you have time to 5.2 RC1 to massively change the UI, if you think there is still something very wrong with it. After that only singular, very well argumented changes will be possible and they must be confirmed by the l10n teams - I propose some kind of a l10n body in the TFD structure to approve such changes, or the TDF board. And we should also market/advertise the 5.2 release as a release that finally puts all the commands etc. onto the right places.

If MS would change the commands and their position as you do now, no one would be using MS Word etc. today. It is simply schizophrenic to use newest versions of LO - you never know where the commands have finished in the menus.

Also, I plead the old system of UI and functionality changes from the Sun days would return - there the developers and UX people prepared a document - online wiki one, I think, I do not have link, maybe one has a copy of it - where the rationale of the proposed change is explained, the (changed or introduced) gui is laid out and explained and then this is discussed, maybe changed and - in the end - implemented.
Comment 100 Yousuf Philips (jay) 2016-06-08 11:07:43 UTC
(In reply to Cor Nouws from comment #98)
> Sorry for the confusion. Apart from the naming, it's breaking productivity.
> The menu already is long. So the two extra ..

Please explain what productivity this breaks? The menu currently has 26 items in it and above 27 items, laptop and tablet users (e.g. Sophie, Me) will have to scroll up and down in the menu to view all the items.

> If really needed, take the extra "Page Number" out (people expect something
> else there), add Chart to Object> (not that often used in Writer) :)

Not possible for cross-module unification.

I'll move Hyperlink back into the root menu (good for cross-module unification) and rename 'Link' to 'Bookmark and Cross-reference'.
Comment 101 Yousuf Philips (jay) 2016-06-08 12:10:03 UTC
Incremental changes to the UI have been happening since 4.4, with some being massively changed in different releases, and that will continue for the foreseeable future 

(In reply to miles from comment #99)
> It was announced how 5.1 and in some extent 5.2 brings massive changes to
> menus, UI, to make it better. The l10n teams said, ok, if this is it, ok.

Yes 5.1 brought massive changes to the menus, though i'm not sure there were any other massive changes to the UI.

> OK. But it seems now you intend to keep massively change the ui even for 5.3
> etc. Every member of UI team who looks at the changes has another N ideas
> how to make further changes. So please first discuss each menu - all UX
> members - then decide what will change. This is not AbiWord, it is the
> leading open source office suite, used by millions of users all over the
> world.

There will be incremental tweaks to the menus in 5.2 and future releases as not all changes can be achieved within LO's 6 month release cycles, we are volunteers working on these improvements, and user feedback helps us improve on the changes. Getting feedback from the UI/UX team and from our users is the reason for this bug report, so people are more than welcome to give their opinions on my changes.

> All online help and manuals, printed and not printed ones, become obsolete
> the minute you change one of the menu entries.

Hard to believe that changing a single menu entry makes all help and manuals obsolete, but if that is what you believe that is fine.

> I think the TDF and especially the l10n teams should give an ultimatum to
> the UX guys: you have time to 5.2 RC1 to massively change the UI, if you
> think there is still something very wrong with it. After that only singular,
> very well argumented changes will be possible and they must be confirmed by
> the l10n teams - I propose some kind of a l10n body in the TFD structure to
> approve such changes, or the TDF board. And we should also market/advertise
> the 5.2 release as a release that finally puts all the commands etc. onto
> the right places.

There is already a deadline for string changes with RC1 and anything after than is approved by Sophie. - https://wiki.documentfoundation.org/ReleasePlan/5.2#5.2.0_release

> If MS would change the commands and their position as you do now, no one
> would be using MS Word etc. today. It is simply schizophrenic to use newest
> versions of LO - you never know where the commands have finished in the
> menus.

MS Word releases a new version every 3 years, has paid employees working on it and has clear goals to be achieved in each release. LO doesnt have these, so there is no point in comparing it. Hopefully there wont be any more changes needed to the menus after 5.3, but only time will tell.

> Also, I plead the old system of UI and functionality changes from the Sun
> days would return - there the developers and UX people prepared a document -
> online wiki one, I think, I do not have link, maybe one has a copy of it -
> where the rationale of the proposed change is explained, the (changed or
> introduced) gui is laid out and explained and then this is discussed, maybe
> changed and - in the end - implemented.

https://design.blog.documentfoundation.org/2016/01/22/way-down-in-the-libreoffice-menus/
Comment 102 Commit Notification 2016-06-09 19:33:20 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c8200675c7fd6550c78b20b7c87ebf03047bb6d4

tdf#91781 tweak to Writer's insert menu

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 103 Cor Nouws 2016-06-10 02:17:56 UTC
(In reply to Yousuf (Jay) Philips from comment #100)
> (In reply to Cor Nouws from comment #98)
> > Sorry for the confusion. Apart from the naming, it's breaking productivity.
> > The menu already is long. So the two extra ..
> 
> Please explain what productivity this breaks? The menu currently has 26
> items in it and above 27 items, laptop and tablet users (e.g. Sophie, Me)
> will have to scroll up and down in the menu to view all the items.

I work on a laptop (1366x768) too. And there is room for at least three extra items in the menu.
Plus: how often does one use Insert > Form Control (without the mouse; ~never) and Insert Envelope ?
For certain tasks Insert Bookmark and Insert Cross-reference are used often.

If the menu really needs to be shorter, then these are better candidates:
 Chart  : Hardly used this way in Writer, sorry for the inconsistency
 Page Number  :  Duplicate and confusing
 Manual Break :  Duplicate

> > If really needed, take the extra "Page Number" out (people expect something
> > else there), add Chart to Object> (not that often used in Writer) :)
> 
> Not possible for cross-module unification.

Unification is a good thing, but not an altar to sacrifice anything else.

> I'll move Hyperlink back into the root menu (good for cross-module
> unification) and rename 'Link' to 'Bookmark and Cross-reference'.

Thanks for the extra work, but I'm not satisfied.
Comment 104 Yousuf Philips (jay) 2016-06-10 14:13:45 UTC
(In reply to Cor Nouws from comment #103)
> I work on a laptop (1366x768) too. And there is room for at least three
> extra items in the menu.

I work on a laptop (1280x768) and there isnt room with the three without scrolling.

Ubuntu Mate - http://picpaste.com/ubuntu_mate_-_writer_insert-YVnr0EX4.png
Windows 7 - http://picpaste.com/windows_7_-_writer_insert-aMbO7Oxe.png

> Plus: how often does one use Insert > Form Control (without the mouse;
> ~never) and Insert Envelope ?
> For certain tasks Insert Bookmark and Insert Cross-reference are used often.

Well Form Control is already a submenu, so not sure where you'd like to stick it. Insert envelope isnt highly used, while inserting a bookmark and cross-reference are definitely more highly used, which is why they are in the toolbars.

> If the menu really needs to be shorter, then these are better candidates:
>  Chart  : Hardly used this way in Writer, sorry for the inconsistency
>  Page Number  :  Duplicate and confusing
>  Manual Break :  Duplicate

Definitely not worth removing these, but if we needed alternatives to move to a submenu, document and envelope would be my first choices, though they arent in a related section like bookmark and cross reference are.
Comment 105 Commit Notification 2016-06-12 19:31:56 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=49c73926554dab691978b6d6c101525d1415a751&h=libreoffice-5-2

tdf#91781 tweak to Writer's insert menu

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 106 Commit Notification 2016-06-17 13:45:53 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=42dc04de01cb937b5a64d23f54e8dfe5f4c9b35f

tdf#91781 Move bookmark and cross-reference to root insert menu

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 107 Commit Notification 2016-06-19 21:53:56 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a567c9286d82c46f51d7d30322e86fcf40468d6&h=libreoffice-5-2

tdf#91781 Move bookmark and cross-reference to root insert menu

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 108 Cor Nouws 2016-06-20 08:19:45 UTC
(In reply to Commit Notification from comment #107)
> Yousuf Philips committed a patch related to this issue.
> It has been pushed to "libreoffice-5-2":


Thanks Jay!
Comment 109 Commit Notification 2016-09-11 09:19:33 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=55f1b2b305864212cb1f808c031c028e12b44020

tdf#91781 Add Edit > Comment submenu to writer

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 110 Commit Notification 2017-05-22 23:14:44 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=adb5cdcf2352d3f1c78645feafc4c270b58b197a

tdf#91781 Add list styles and reorganized form controls

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 111 Commit Notification 2017-06-03 14:41:39 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=94852757f93bc1b3813164903258d567ffe83747&h=libreoffice-5-4

tdf#91781 Add list styles and reorganized form controls

It will be available in 5.4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 112 Commit Notification 2017-06-20 01:19:49 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ef59d7ace7e4db52caea601a384ed016365bcaf

tdf#91781 Move watermark from insert to format menu

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 113 Commit Notification 2017-06-23 19:18:37 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccd08a5a8fbf3fd4ca344181a700764d5339589d&h=libreoffice-5-4

tdf#91781 Move watermark from insert to format menu

It will be available in 5.4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 114 Commit Notification 2017-08-24 13:42:27 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=04e719efbdb551d7c72fd0cc690f76c96bb66960

tdf#91781 Removal of Format > Columns

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 115 Commit Notification 2017-10-30 17:39:05 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c364fa7d507ae41bf04d36464f8942d154e49c0

tdf#91781 Collect form commands into new Form menu

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.