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.
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.
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.
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.
(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.
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.
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'.
(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.
(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 :)
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
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?
(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.
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.
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.
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.
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.
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.
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.
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
+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.
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
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.
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.
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" ;)
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.
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.
(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.
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 ;)
> 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?)
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?
(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
(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
(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.
(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?
(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
(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
(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.
(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.
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.
(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.
> 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?
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.
(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
(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
(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.
(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.
(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.
Created attachment 116328 [details] Separate menu for direct formatting
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
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.
(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)
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.
Created attachment 116349 [details] Separate menu for Styles - menu tweak
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.
'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.
(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'.
(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.
(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.
(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 :)
(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.
(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.
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
(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.
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é
(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
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.
(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
(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.
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
(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
(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
(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 :)
(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
(In reply to Jean-Baptiste Faure from comment #72) (better handle this in a separate issue - sorry that I commented here)
(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
(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
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.
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.
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.
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."
(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
(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 ..
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.
@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.
(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
@Yousuf: Thanks. :)
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.
(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
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.
(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).
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.
New Format menu is too long. Please try it on a screen 1366x768 with not maximized Writer window. Best regards. JBF
(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.
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.
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.
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.
(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.
(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.
(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) :)
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.
(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'.
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/
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.
(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.
(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.
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.
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.
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.
(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!
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.
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.
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.
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.
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.
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.
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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=67d245adca298134fc8ab4364acbe880b4e0911a tdf#91781 Round of improvements to Writer's menus for 6.0 It will be available in 6.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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=35589bc4e390282f1e26b9900addc3742e61b3ff&h=libreoffice-6-0 tdf#91781 Round of improvements to Writer's menus for 6.0 It will be available in 6.0.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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac5518b6d4a14b2ed8011c35f97435e797a7b8d6 tdf#91781 Round of improvements to Writer's menus for 6.0 (2) It will be available in 6.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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ad84cb95887096731ad48c65a29547660658c01&h=libreoffice-6-0 tdf#91781 Round of improvements to Writer's menus for 6.0 (2) It will be available in 6.0.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.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=993bbae2d43d3e4dea445cccbee3bb16d883af02 tdf#91781 Writer: Add Breaks submenu in Insert menu It will be available in 6.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.
Adding bug 115238 as see also. I suggest when doing the menu improvements, one should better not make the root menu too long. Just my personal opinion. Revelant menu items should be groupded if possible.
Closing as FIXED because it's assigned to Yousuf Philips who isn't active anymore. Open bugs will be moved to Main-Menu meta bug.