[Libreoffice-ux-advise] [Bug 91781] Reorganization of the menu bar for Writer

https://bugs.documentfoundation.org/show_bug.cgi?id=91781

--- Comment #11 from Yousuf (Jay) Philips <philipz85@hotmail.com> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.