Created attachment 116248 [details] calc menu bar Similar to the work being done for Writer (bug 91781), i've also worked on reorganizing the menu bar in Calc. The most noticeable change is the addition of a new menu bar item called 'Sheet' which contains all sheet management options which were scattered all through the menus. Look forward to the feedback and for you to test drive it soon.
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. View Print preview limits editing possibilities, unlike Normal/page break. I would keep it with File > Print Why do you rename Freeze to Freeze panes ? Tools Cell contents - I miss this. It is not about Data as the function in that menu. We had another discussion on the position of the Tools menu. Do I see that it is missed here? Data AutoFilter and More filters.. I would not do that. Shortcut Data > Filter immediately offers AutoFilter Sheet Interesting idea.. Thanks! Cor
(In reply to Cor Nouws from comment #1) > Question: what is the work based on, comments, experience, study, comparing > with other software, ...? As stated in the description of bug 91781, "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. > Some comments: > > Edit > Merge document is a function limited to documents with tracked changes. It > must be in that sub menu. Answered in bug 91781 comment 11. > View > Print preview limits editing possibilities, unlike Normal/page break. I > would keep it with File > Print Answered in bug 91781 comment 11. > Why do you rename Freeze to Freeze panes ? The word 'Freeze' by itself has no meaning. It had no meaning as Window > Freeze as you are not actually freezing the window. Freeze panes is used in Excel, but we could use Freeze Rows/Columns if that is more preferable. > Tools > Cell contents - I miss this. It is not about Data as the function in that > menu. This was moved and to Data > Calculate as the entries are to recalculate data. > We had another discussion on the position of the Tools menu. Do I see that > it is missed here? No we had discussions about it during the HIG work and decided that Tools would always be next to Window for consistency of the menu bar. > Data > AutoFilter and More filters.. I would not do that. Shortcut Data > Filter > immediately offers AutoFilter The stats showed that 78% of users who opened the Data > Filter submenu went for AutoFilter and it is the second most used entry in the Data menu, so it is important that it be not in a submenu. > Sheet > Interesting idea.. Yes i wondered what would be the best possible name for it. Any suggestions?
(In reply to Yousuf (Jay) Philips from comment #2) > (In reply to Cor Nouws from comment #1) > > Some comments: > > > > Edit > > Merge document is a function limited to documents with tracked changes. It > > must be in that sub menu. > > Answered in bug 91781 comment 11. Replied there: wrong argument. > > View > > Print preview limits editing possibilities, unlike Normal/page break. I > > would keep it with File > Print > > Answered in bug 91781 comment 11. Replied there: It breaks with the principle to bundle related functions: print and print preview. > > Why do you rename Freeze to Freeze panes ? > > The word 'Freeze' by itself has no meaning. It had no meaning as Window > > Freeze as you are not actually freezing the window. Freeze panes is used in > Excel, but we could use Freeze Rows/Columns if that is more preferable. OK clear, thanks. > > Tools > > Cell contents - I miss this. It is not about Data as the function in that > > menu. > > This was moved and to Data > Calculate as the entries are to recalculate > data. It is also about AutoInput. So that argument is not correct. > > We had another discussion on the position of the Tools menu. Do I see that > > it is missed here? > > No we had discussions about it during the HIG work and decided that Tools > would always be next to Window for consistency of the menu bar. I brought forward long time ago, that the applied sequence is File-...-Format-Tools. And all module specific menu's between Tools and Window. So that was the originally chosen consistency. (With the sole exception that Table was added in Writer later) But I do not think that I prefer the one consistency over the other. > > Data > > AutoFilter and More filters.. I would not do that. Shortcut Data > Filter > > immediately offers AutoFilter > > The stats showed that 78% of users who opened the Data > Filter submenu went > for AutoFilter and it is the second most used entry in the Data menu, so it > is important that it be not in a submenu. It is important that is is easy accessible. It is now since it's at top in the submenu. Furthermore with the change the first menu will be more cluttered. > > Sheet > > Interesting idea.. > > Yes i wondered what would be the best possible name for it. Any suggestions? Not yet, no. But again we face a situation where part of the entries can be considered to apply for sheets as well as for different components, I'm afraid.
(In reply to Cor Nouws from comment #3) > > > Why do you rename Freeze to Freeze panes ? > > > > The word 'Freeze' by itself has no meaning. It had no meaning as Window > > > Freeze as you are not actually freezing the window. Freeze panes is used in > > Excel, but we could use Freeze Rows/Columns if that is more preferable. > > OK clear, thanks. So do you have a preference here? > > > Tools > > > Cell contents - I miss this. It is not about Data as the function in that > > > menu. > > > > This was moved and to Data > Calculate as the entries are to recalculate > > data. > > It is also about AutoInput. So that argument is not correct. So are the 3 calculate items correct to place under Data? > > > We had another discussion on the position of the Tools menu. Do I see that > > > it is missed here? > > > > No we had discussions about it during the HIG work and decided that Tools > > would always be next to Window for consistency of the menu bar. > > I brought forward long time ago, that the applied sequence is > File-...-Format-Tools. And all module specific menu's between Tools and > Window. So that was the originally chosen consistency. > (With the sole exception that Table was added in Writer later) > But I do not think that I prefer the one consistency over the other. Guess my words werent clear when i wrote that sentence. Yes we (me and you) discussed the issue in the past and then we (me and heiko) discussed it as part of the HIG. In the HIG we decided that we need to consistency across apps, so it was preferred to have the least opened menus (tools, windows, help) to the end together, like in writer. > > > Data > > > AutoFilter and More filters.. I would not do that. Shortcut Data > Filter > > > immediately offers AutoFilter > > > > The stats showed that 78% of users who opened the Data > Filter submenu went > > for AutoFilter and it is the second most used entry in the Data menu, so it > > is important that it be not in a submenu. > > It is important that is is easy accessible. It is now since it's at top in > the submenu. > Furthermore with the change the first menu will be more cluttered. It is not as cluttered as most menus as it has 20 items in it, while the sheet menu has 25 items in it. The menu had 16 items in it before i made changes to it. > > > Sheet > > > Interesting idea.. > > > > Yes i wondered what would be the best possible name for it. Any suggestions? > > Not yet, no. But again we face a situation where part of the entries can be > considered to apply for sheets as well as for different components, I'm > afraid. Yes that is always a challenge, so we try to make the best possible that fits best.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ce5470cb3eb7e5394ef1d7cb1906886abab80d5d tdf#91820 Reorganize calc'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.
(In reply to Yousuf (Jay) Philips from comment #4) > (In reply to Cor Nouws from comment #3) >>>> Why do you rename Freeze to Freeze panes ? >>> >>> The word 'Freeze' by itself has no meaning. It had no meaning as Window > >>> Freeze as you are not actually freezing the window. Freeze panes is used in >>> Excel, but we could use Freeze Rows/Columns if that is more preferable. >> >> OK clear, thanks. > > So do you have a preference here? I think the change is good. >>>> Tools >>>> Cell contents - I miss this. It is not about Data as the function in that >>>> menu. >>> >>> This was moved and to Data > Calculate as the entries are to recalculate >>> data. >> >> It is also about AutoInput. So that argument is not correct. > > So are the 3 calculate items correct to place under Data? In fact it is a mixed group, about calculation and auto-Input. And AutoImput is really a tool :) >>>> We had another discussion on the position of the Tools menu. Do I see that >>>> it is missed here? >>> >>> No we had discussions about it during the HIG work and decided that Tools >>> would always be next to Window for consistency of the menu bar. >> >> I brought forward long time ago, that the applied sequence is >> File-...-Format-Tools. And all module specific menu's between Tools and >> Window. So that was the originally chosen consistency. >> (With the sole exception that Table was added in Writer later) >> But I do not think that I prefer the one consistency over the other. > > Guess my words werent clear when i wrote that sentence. Yes we (me and you) > discussed the issue in the past and then we (me and heiko) discussed it as > part of the HIG. In the HIG we decided that we need to consistency across > apps, so it was preferred to have the least opened menus (tools, windows, > help) to the end together, like in writer. One can also say: all between File and Tools is consequent (I read in the Writer issue that there is still a search for that holy grail :) ) and that the rest before view is app-specific. I have no strong preference here. >>>> Data >>>> AutoFilter and More filters.. I would not do that. Shortcut Data > Filter >>>> immediately offers AutoFilter >>> >>> The stats showed that 78% of users who opened the Data > Filter submenu went >>> for AutoFilter and it is the second most used entry in the Data menu, so it >>> is important that it be not in a submenu. >> >> It is important that is is easy accessible. It is now since it's at top in >> the submenu. >> Furthermore with the change the first menu will be more cluttered. > > It is not as cluttered as most menus as it has 20 items in it, while the > sheet menu has 25 items in it. The menu had 16 items in it before i made > changes to it. It adds cluttering because Filter is mentioned twice in the main menu. It hurts to my eyes. May be only me? (No others interested in Cal ?) >>>> Sheet >>>> Interesting idea.. >>> >>> Yes i wondered what would be the best possible name for it. Any suggestions? >> >> Not yet, no. But again we face a situation where part of the entries can be >> considered to apply for sheets as well as for different components, I'm >> afraid. > > Yes that is always a challenge, so we try to make the best possible that > fits best. Still going on. Thanks for that! Cor
(In reply to Cor Nouws from comment #6) > >> OK clear, thanks. > > > > So do you have a preference here? > > I think the change is good. I changed it from 'Freeze Panes' to 'Freeze Rows and Columns' as i'd assume most people would know what panes are, me included. :D > > So are the 3 calculate items correct to place under Data? > > In fact it is a mixed group, about calculation and auto-Input. And AutoImput > is really a tool :) So you okay with moving AutoInput to Tools and keeping the rest under Data? > > Guess my words werent clear when i wrote that sentence. Yes we (me and you) > > discussed the issue in the past and then we (me and heiko) discussed it as > > part of the HIG. In the HIG we decided that we need to consistency across > > apps, so it was preferred to have the least opened menus (tools, windows, > > help) to the end together, like in writer. > > One can also say: all between File and Tools is consequent (I read in the > Writer issue that there is still a search for that holy grail :) ) and that > the rest before view is app-specific. > I have no strong preference here. I believe it is quite similar to our toolbars, where we put the most important buttons on the left (new, open, save) and less important on the right (draw tools). > > It is not as cluttered as most menus as it has 20 items in it, while the > > sheet menu has 25 items in it. The menu had 16 items in it before i made > > changes to it. > > It adds cluttering because Filter is mentioned twice in the main menu. > It hurts to my eyes. May be only me? > (No others interested in Cal ?) Well i'm hoping you never open the File menu, as save is mentioned 4 times. :D > >> Not yet, no. But again we face a situation where part of the entries can be > >> considered to apply for sheets as well as for different components, I'm > >> afraid. > > > > Yes that is always a challenge, so we try to make the best possible that > > fits best. > > Still going on. Thanks for that! LibreOffice is a never ending story.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cdd7ef358d8e97ebf13431b78337f61ad5c2c01a tdf#91820 Minor fixes and fix icon links 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.
I'm not happy with all details of this change, in particular: * Sheet * Fill Cells * Was in the Edit menu as Fill. * Makes more sense in the Edit menu, because filling cells is an edit action, not a sheet action. * Names Cells * Was in the Insert menu as Names. * The new name "Names Cells" doesn't make sense; if we change the name then to "Named Expressions", but not to Names Cells. * May make more sense in the Insert menu, because named expressions and ranges more often are document global than sheet local. However, Insert isn't the exact functionality, but Sheet isn't the exact functionality either. * Cell Comment * Has an unselectable blank first submenu entry that probably should read "Insert Comment". * Edit * Protect Spreadsheet * Why was this renamed from Protect Document? Spreadsheet is confusingly similar to Sheet. * The entries immediately above are Merge Document and Compare Document. * It is very unfortunate to move the Tools' Protect Document menu entry that had a submenu with Document and Sheet away from the Tools menu AND split it up and scatter over two different menus AND rename the entries. Imagine how confused users will be who want to use the functionality. Already I was when I wanted to unprotect a document..
Hi Eike, Glad to get your input on this as you the calc maintainer. :D (In reply to Eike Rathke from comment #9) > * Sheet > * Fill Cells > * Was in the Edit menu as Fill. > * Makes more sense in the Edit menu, because filling cells is an > edit action, not a sheet action. Pretty much everything that is done in calc involves edit/modifying of a sheet/column/row/cell, which is why quite a number of these functions were moved from the edit and insert menus into a dedicated Sheet menu. So now a user can go into Sheet to insert or delete a cell, as well as fill or clear a cell. The name Sheet encompasses all features of a sheet, similar to the Table menu in writer encompasses all features of a table. > * Names Cells > * Was in the Insert menu as Names. > * The new name "Names Cells" doesn't make sense; if we change the > name then to "Named Expressions", but not to Names Cells. > * May make more sense in the Insert menu, because named expressions > and ranges more often are document global than sheet local. > However, Insert isn't the exact functionality, but Sheet isn't the > exact functionality either. It was renamed to 'Name Cells' in my June 11th patch as a user is defining a name for a group of cells on the current sheet or globally for the spreadsheet. 'Naming Cells' is another possible as that is what we use in the help - https://help.libreoffice.org/Calc/Naming_Cells Yes its hard to always know the best possible place to put it, but if i had to choose between insert and sheet, it would be sheet, as the Insert menu contains elements that are visibly seen and inserted in a sheet, while defining a name to a group of cells is more like setting a reference on a sheet. > * Cell Comment > * Has an unselectable blank first submenu entry that probably should > read "Insert Comment". It was named as 'Edit Comment' in my June 11th patch. > * Edit > * Protect Spreadsheet > * Why was this renamed from Protect Document? Spreadsheet is > confusingly similar to Sheet. The use of document in libreoffice is primarily linked to writer, as we have 'Writer Document' in the start center and we have 'Text documents' in the open dialog. While calc has 'Calc Spreadsheet' in the start center, 'Spreadsheets' in the open dialog and ODF Spreadsheet in the save dialog. I doubt users would not know the difference between a spreadsheet and a sheet and if they dont, it is a good opportunity to teach them the difference by using the word spreadsheet more. > * The entries immediately above are Merge Document and Compare > Document. Yes those would likely also need to be changed. > * It is very unfortunate to move the Tools' Protect Document menu > entry that had a submenu with Document and Sheet away from the > Tools menu AND split it up and scatter over two different menus > AND rename the entries. Imagine how confused users will be who > want to use the functionality. Already I was when I wanted to > unprotect a document.. Yes it would be a change for users who have already know where things have been, but that is the case with any change. Better organized menus help both old and new users. So is it better for a user to find protect sheet under Tools > Protect Document > Sheet or Sheet > Protect Sheet? Of course i would assume most users would simply use the sheet tab context menu for this rather than digging into menus. Should protecting the contents of a spreadsheet from being changed be considered a tool or simply an edit function similar to tracking the changes being make to a spreadsheet? The tools menu has been known to be a dumping ground for functions that didnt seem to go into other menus rather than them truly being tools.
(In reply to Yousuf (Jay) Philips from comment #7) > (In reply to Cor Nouws from comment #6) > > >> OK clear, thanks. > > > > > > So do you have a preference here? > > > > I think the change is good. > > I changed it from 'Freeze Panes' to 'Freeze Rows and Columns' as i'd assume > most people would know what panes are, me included. :D Maybe it helps. But as many items: people have to learn what it is first. The position in View rather then Window does not change that. > > > > So are the 3 calculate items correct to place under Data? > > > > In fact it is a mixed group, about calculation and auto-Input. And AutoImput > > is really a tool :) > > So you okay with moving AutoInput to Tools and keeping the rest under Data? I think it would be OK below Autocorrect options yes. > > > It is not as cluttered as most menus as it has 20 items in it, while the > > > sheet menu has 25 items in it. The menu had 16 items in it before i made > > > changes to it. > > > > It adds cluttering because Filter is mentioned twice in the main menu. > > It hurts to my eyes. May be only me? > > (No others interested in Cal ?) > > Well i'm hoping you never open the File menu, as save is mentioned 4 times. > :D That is a wrong argument. In other menu's where items are repeated, _all_ the items are in the same menu, and not some in the menu and some in a submenu. > > >> Not yet, no. But again we face a situation where part of the entries can be > > >> considered to apply for sheets as well as for different components, I'm > > >> afraid. > > > > > > Yes that is always a challenge, so we try to make the best possible that > > > fits best. I do like the most changes definitely.
Hi Jay, Eike, (In reply to Yousuf (Jay) Philips from comment #10) > Glad to get your input on this as you the calc maintainer. :D > > (In reply to Eike Rathke from comment #9) > > * Sheet > > * Fill Cells > > * Was in the Edit menu as Fill. > > * Makes more sense in the Edit menu, because filling cells is an > > edit action, not a sheet action. > > Pretty much everything that is done in calc involves edit/modifying of a > sheet/column/row/cell, which is why quite a number of these functions were > moved from the edit and insert menus into a dedicated Sheet menu. So now a > user can go into Sheet to insert or delete a cell, as well as fill or clear > a cell. The name Sheet encompasses all features of a sheet, similar to the > Table menu in writer encompasses all features of a table. It's new, but not bad. > > * Names Cells > > * Was in the Insert menu as Names. > > * The new name "Names Cells" doesn't make sense; if we change the > > name then to "Named Expressions", but not to Names Cells. @eike: why 'Named Expressions'? > > * May make more sense in the Insert menu, because named expressions > > and ranges more often are document global than sheet local. > > However, Insert isn't the exact functionality, but Sheet isn't the > > exact functionality either. > > It was renamed to 'Name Cells' in my June 11th patch as a user is defining a > name for a group of cells on the current sheet or globally for the > spreadsheet. 'Naming Cells' is another possible as that is what we use in > the help - https://help.libreoffice.org/Calc/Naming_Cells > > Yes its hard to always know the best possible place to put it, but if i had > to choose between insert and sheet, it would be sheet, as the Insert menu > contains elements that are visibly seen and inserted in a sheet, while > defining a name to a group of cells is more like setting a reference on a > sheet. > > > * Cell Comment > > * Has an unselectable blank first submenu entry that probably should > > read "Insert Comment". > > It was named as 'Edit Comment' in my June 11th patch. > > > * Edit > > * Protect Spreadsheet > > * Why was this renamed from Protect Document? Spreadsheet is > > confusingly similar to Sheet. > > The use of document in libreoffice is primarily linked to writer, as we have > 'Writer Document' in the start center and we have 'Text documents' in the > open dialog. While calc has 'Calc Spreadsheet' in the start center, > 'Spreadsheets' in the open dialog and ODF Spreadsheet in the save dialog. I > doubt users would not know the difference between a spreadsheet and a sheet > and if they dont, it is a good opportunity to teach them the difference by > using the word spreadsheet more. I think people will simply understand Protect document. No need to change that. > > * The entries immediately above are Merge Document and Compare > > Document. > > Yes those would likely also need to be changed. > > > * It is very unfortunate to move the Tools' Protect Document menu > > entry that had a submenu with Document and Sheet away from the > > Tools menu AND split it up and scatter over two different menus > > AND rename the entries. Imagine how confused users will be who > > want to use the functionality. Already I was when I wanted to > > unprotect a document.. > > Yes it would be a change for users who have already know where things have > been, but that is the case with any change. Better organized menus help both > old and new users. > > So is it better for a user to find protect sheet under Tools > Protect > Document > Sheet or Sheet > Protect Sheet? Of course i would assume most > users would simply use the sheet tab context menu for this rather than > digging into menus. > > Should protecting the contents of a spreadsheet from being changed be > considered a tool or simply an edit function similar to tracking the changes > being make to a spreadsheet? The tools menu has been known to be a dumping > ground for functions that didnt seem to go into other menus rather than them > truly being tools. The big disadvantage, mentioned by Eike too, is that now protecting is split over Sheet and Edit. For such a situation, using Tools makes sense maybe? Similar with Pivot Tables... Now we have Insert > Pivot Table and Data > Pivot Table > .. Shrug. Maybe it's better to have that in Data, where it is now. Cheers, Cor
Coming back to this one.. (In reply to Cor Nouws from comment #12) > > > * Names Cells > > > * Was in the Insert menu as Names. > > > * The new name "Names Cells" doesn't make sense; if we change the > > > name then to "Named Expressions", but not to Names Cells. > > @eike: why 'Named Expressions'? In the dialog you can name a cell area (range) but also enter a formula expression. Within the dialog we use "range or formula expression" as label for the edit field. A reference is a subexpression (can be used as part of a formula), the unifying term for all you can enter there is "named expression". > > > * It is very unfortunate to move the Tools' Protect Document menu > > > entry that had a submenu with Document and Sheet away from the > > > Tools menu AND split it up and scatter over two different menus > > > AND rename the entries. Imagine how confused users will be who > > > want to use the functionality. Already I was when I wanted to > > > unprotect a document.. > > > > Yes it would be a change for users who have already know where things have > > been, but that is the case with any change. Better organized menus help both > > old and new users. I don't consider this situation to be better organized though.. > > So is it better for a user to find protect sheet under Tools > Protect > > Document > Sheet or Sheet > Protect Sheet? Of course i would assume most > > users would simply use the sheet tab context menu for this rather than > > digging into menus. You would be surprised how many users don't use context menus at all or don't even know/recall it does exist and offers different choices for different, well, contexts.. > > Should protecting the contents of a spreadsheet from being changed be > > considered a tool or simply an edit function similar to tracking the changes > > being make to a spreadsheet? The tools menu has been known to be a dumping > > ground for functions that didnt seem to go into other menus rather than them > > truly being tools. > > The big disadvantage, mentioned by Eike too, is that now protecting is split > over Sheet and Edit. That's my point. It's not only a disadvantage, it makes working with the UI a bad experience. > For such a situation, using Tools makes sense maybe? > Similar with Pivot Tables... > Now we have Insert > Pivot Table and Data > Pivot Table > .. > Shrug. > Maybe it's better to have that in Data, where it is now. And also move all Protect actions there. At the end you want to protect your data.
(In reply to Yousuf (Jay) Philips from comment #10) > > * Cell Comment > > * Has an unselectable blank first submenu entry that probably should > > read "Insert Comment". > > It was named as 'Edit Comment' in my June 11th patch. And is displayed now, but ... now we have Edit, Show, Hide and Delete, all greyed out if there is no comment at the current position, but no entry to insert a comment from that menu. I know it is in the Insert menu and in the context menu, but not having it in the menu there together with all other comment related actions is odd.
(In reply to Eike Rathke from comment #13) > > > Yes it would be a change for users who have already know where things have > > > been, but that is the case with any change. Better organized menus help both > > > old and new users. > > I don't consider this situation to be better organized though.. I guess we'll agree to disagree about this. > > > So is it better for a user to find protect sheet under Tools > Protect > > > Document > Sheet or Sheet > Protect Sheet? Of course i would assume most > > > users would simply use the sheet tab context menu for this rather than > > > digging into menus. > > You would be surprised how many users don't use context menus at all or > don't even know/recall it does exist and offers different choices for > different, well, contexts.. About 80 percent of users use context menus in general, as it is easier to access contextual entries than going into the toolbar or menubar, and if they are aware that the tabs have a context menu, they are less likely to open the menubar to access those entries, especially when they are all scattered through the menubar. Inserting a sheet was in the insert menu, copying and deleting a sheet was in the Edit menu, hiding and renaming a sheet was in the Format menu and protecting a sheet was in the Tools menu. > > > Should protecting the contents of a spreadsheet from being changed be > > > considered a tool or simply an edit function similar to tracking the changes > > > being make to a spreadsheet? The tools menu has been known to be a dumping > > > ground for functions that didnt seem to go into other menus rather than them > > > truly being tools. > > > > The big disadvantage, mentioned by Eike too, is that now protecting is split > > over Sheet and Edit. > > That's my point. It's not only a disadvantage, it makes working with the > UI a bad experience. The point here is that we find the most suitable place for entries and the most suitable place to protect a sheet is in the Sheet menu, not in the Tools menu, as all other sheet type functions are in the Sheet menu. > > For such a situation, using Tools makes sense maybe? > > Similar with Pivot Tables... > > Now we have Insert > Pivot Table and Data > Pivot Table > .. > > Shrug. > > Maybe it's better to have that in Data, where it is now. With the way the menus are structured, we dont always have the ability to always put related things together. When you insert an image you goto the Insert menu, but when you want to modify that image, you go to the Format menu. So if a user was told to insert a pivot table into their spreadsheet, they would likely go into the Insert menu to do so, similar to how they open that menu to insert a image or chart. > And also move all Protect actions there. At the end you want to protect > your data. So if the Data menu is to be used for do things with data, should hiding that data also go under that menu? Meaning should we have Data > Hide Sheet. (In reply to Eike Rathke from comment #14) > (In reply to Yousuf (Jay) Philips from comment #10) > > > * Cell Comment > > > * Has an unselectable blank first submenu entry that probably should > > > read "Insert Comment". > > > > It was named as 'Edit Comment' in my June 11th patch. > > And is displayed now, but ... now we have Edit, Show, Hide and Delete, > all greyed out if there is no comment at the current position, but no > entry to insert a comment from that menu. I know it is in the Insert > menu and in the context menu, but not having it in the menu there > together with all other comment related actions is odd. As stated above, we cant always have all related entries together. If Insert > Comment wasnt the default location in all other apps, i would have considered moving it there.
Hi Jay, Some comments on my side too: - Freeze Rows and Columns: where is the possibility to freeze only a column or a row? - Same for Split window: where is the possibility to split horizontally or vertically only? - Protect Sheet vs Protect Spreadsheet: Spreadsheet is often seen as the tool (which is how it translates) so it has little meaning for most of the languages, Document was much more understandable and as Eike, sad that it's split now. - Change case: is an often used function in sheet really well hidden now - Format menu: is too long for my screen - Sheet menu: is too long for my screen - Name cells: agreed with Eike, Name Expressions would be more accurate - Clear cell: Strange to see the name of the key attached but it's correctly changed if you use legacy shortcuts - Calculate: why do you change it, it was really more accurate with Cell content, only 2 entries on 4 are about calculation. - I would move Multiple Operations with the group that calculates the same resolutions under Tools. Will come with more later :) Sophie
(In reply to sophie from comment #16) > Hi Jay, Hi Sophie, > - Freeze Rows and Columns: where is the possibility to freeze only a column > or a row? Go to B1 and you will be able to freeze column A. Go to A2 and you will be able to freeze row 1. > - Same for Split window: where is the possibility to split horizontally or > vertically only? Same as above. > - Protect Sheet vs Protect Spreadsheet: Spreadsheet is often seen as the > tool (which is how it translates) so it has little meaning for most of the > languages, Document was much more understandable and as Eike, sad that it's > split now. Protecting a sheet or spreadsheet are both edit tools, as it "prevents changes from being made to cells in the sheets or to sheets in a document" ( https://help.libreoffice.org/Calc/Protect_Document ), the same as paste and track changes are edit tools. If it is preferable to keep protect sheet and protect spreadsheet together, than having protect sheet in the edit menu would be a good option. > - Change case: is an often used function in sheet really well hidden now Format menu is long so there isnt space to have it in the root menu. > - Format menu: is too long for my screen > - Sheet menu: is too long for my screen Await to see the screenshot as they are fine on Windows and Linux on my 1280x768 resolution. > - Name cells: agreed with Eike, Name Expressions would be more accurate Will be changed in the upcoming commit and will move it back to insert menu. > - Clear cell: Strange to see the name of the key attached but it's correctly > changed if you use legacy shortcuts Didnt follow. > - Calculate: why do you change it, it was really more accurate with Cell > content, only 2 entries on 4 are about calculation. I thought only autoinput was the only non-calculate one, as AutoCalculate, Recalculate and Formula to Value all seem to be calculate related. > - I would move Multiple Operations with the group that calculates the same > resolutions under Tools. Didnt follow.
Sent a patch in to move protect sheet, protect spreadsheet, share spreadsheet, autoinput back into Tools and named expression back into Edit. @Sophie: Eike suggested 'Named Expression' and you agreed saying 'Name Expression'. So which one?
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f03a700119fc149cf1b93dfafa404b997fc2d4be tdf#91820 Moved tool items back into Tools 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.
propose item "Fill cells" move from menu "Sheet" to menu "Data", it would be more correct filling the cells of the table data - is to work with the data, but not with a sheet
propose items "Clear cells" and "Сell comment" move from menu "Sheet" to menu "Edit". to operations on sheets, this function has nothing to do, it's just editing
(In reply to kompilainenn from comment #20) > propose item "Fill cells" move from menu "Sheet" to menu "Data", it would be > more correct Data menu is for doing work on existing data in a sheet (In reply to kompilainenn from comment #21) > propose items "Clear cells" and "Сell comment" move from menu "Sheet" to > menu "Edit". to operations on sheets, this function has nothing to do, it's > just editing "Clear Cells" was moved to Sheet as it is relate to "Fill Cells" where were both in Edit. The "Cell Comment" submenu has 3 entries (hide, show, delete) that have nothing to do with editing, though moving it to Edit would unify its position with Writer. If others think all three are better positioned in Edit, i'll move them there.
Is there any place, explaining the correlation between old menu positions and where they are in the new one?, sure there is but I didn't find it. I hope I'm wrong, but I can't imagine in how many situations we will need to explain about this matter. If you were so kind to complete the job and explain also in that place a bit about the whys?, it would be helpful on the users support.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=582839394a8224f74ae07dd08f8916352ce48259 tdf#91820 Round of small tweaks to Calc'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.
As someone who frequently uses Spreadsheets I find the current organization to be a *dramatic* change with little to gain and lots of confusion. I've found myself annoyed often looking through the new menus and trying to figure out where things were moved. There is *some* value in the status quo and this approach of "logic trumps all" and *no weight* given to the status quo (i.e., where things are because people are used to that) is problematic. To me I've been somewhat shocked at how these changes occur with almost no consensus (basically jay pushing a ton of changes that he finds to be logical) and they happen *in mass* so instead of gradual changes it's dramatic shifts that can *significantly harm* workflows. Furthermore, I've been surprised that when I suggest a change that seems to be logical I *do* get the "status quo is valuable in and of itself minus PROOF that there are gains from change" but then with toolbar changes it's kind of just a mass change and a "users can deal with it" mentality. Proof is not defined as "this makes sense on some philosophical level" - it means real gains....as in .... were users confused about where these things were before? Were people actively complaining? Was there some harm being done by the status quo? An example of this bug 96299 where there was push back on changing default behavior for cross-references basically because there is no proof of a gain and the status quo is valuable in and of itself. I'm not interested (nor do I have time) to spend hours debating over the merits. My points can be summarized as followed: 1) Status quo has some value - even if maybe some kind of logic would say move things - thus a balanced approach would be nice; 2) Gradual changes over longer periods of times can leave users with less interruptions to their workflow than mass changes
Hi Joel, I can only agree with you. May be questions like this one help to reduce some of our disagreements on the QA process?
(In reply to Joel Madero from comment #25) > 1) Status quo has some value - even if maybe some kind of logic would say > move things - thus a balanced approach would be nice; > > 2) Gradual changes over longer periods of times can leave users with less > interruptions to their workflow than mass changes First of all it's not just Jay to blame, rather all members of the design team. And of course we published a lot in advance. But anyway I think you wanted to positively suggest a slow down. Are you sure that users accept minor changes but with every update? And does it really make sense to do a job half way? I mean moving a few menu items around confuses much more if there is not concept in the end. On the other hand if you have an individually configured toolbar you wouldn't see any changes. So a solution for both issues could be to have a confirmation dialog for UI changes. When an update is applied the user is asked whether or not he or she wants to apply those changes. >I'm not interested (nor do I have time) to spend hours debating over the merits. Acknowledged. We will take your opinion into consideration anyway.
> First of all it's not just Jay to blame, rather all members of the design > team. And of course we published a lot in advance. But anyway I think you > wanted to positively suggest a slow down. Are you sure that users accept > minor changes but with every update? And does it really make sense to do a > job half way? I mean moving a few menu items around confuses much more if > there is not concept in the end. +1 - probably part of the reason why I said "Jay" instead of "Design team" is just that I see his commits largely coming through to do these mass tinkerings. Good to know that it was discussed (due to the lack of time to read . . . 5 sets of minutes per week I apologize for the oversight). I'm not sure of anything other than what I said. I know that when I've suggested changes to UX/UI I get a push back of basically "the status quo is valuable absent absolute proof that the change will be for the better for the user" - with toolbar I rarely see that. I see talks about philosophical "best place to put it" but little talk of "how long have users been using it this way with this placement and are they going to be confused by the changes" and then "is their confusion worth the minor gains that are to be had by constant movement based on some philosophical logic." This reminds me a lot about how Microsoft forced the Ribbon on people (huge change in one release) - although of course it's now been largely adopted by MSO user base, there was *harsh* criticism in the earlier years about forcing such mass changes on users who were entirely comfortable with the status quo. If the idea is "it's best to make them swallow the huge pill up front, hope they don't choke, and then they'll get used to it" is the mentality - then I suppose it might work. I also know that for me personally (speaking entirely for myself), I've stopped using dailies for my day to day work because my workflow was so entirely interrupted. Because of this, I won't be able to report bugs against daily as often...again I know I'm just one voice, and I'm not the "doer" so - take my opinion or leave it, either way I'll understand :) > On the other hand if you have an individually configured toolbar you > wouldn't see any changes. So a solution for both issues could be to have a > confirmation dialog for UI changes. When an update is applied the user is > asked whether or not he or she wants to apply those changes. > > >I'm not interested (nor do I have time) to spend hours debating over the merits. > > Acknowledged. We will take your opinion into consideration anyway. Thanks :) I understand that the "doers" decide - the most I can hope for as a user is simply to consider "my" (although I suspect this may be a criticism that you'll all have to address when a stable release comes out with these dramatic changes) opinion.
discussion interface changes likely not conducted. no publications on this topic was not. then developers just in a hurry. IMHO should publish the proposed changes at least in TDF blog to see the reaction of users
I've spent a huge amount of time in reviewing and trying to discuss the rationale in (mostly never mind what others think to be) pushed changes before given up. Little listening; can't afford spending that time.
In my point of view, this kind of changes will be used by 'users' to complain us that "the product doesn't work", "I can't do that thing I used to do...". It's the same MS did with his products: they just changed the places to do the same, they hide things from users.
(In reply to Rafael Strozi from comment #31) > In my point of view, this kind of changes will be used by 'users' to > complain us that "the product doesn't work", "I can't do that thing I used > to do...". Of course many will. That does not mean that we do not have to make good changes. And show users the changes (hoping they will read the information ;) )
Folks, Other than Cor, and Eike and Sophie's very specific engagement on facets of this reorganization of the calc menu UI--isn't the rest of this simply "bikeshedding"? This is an agreed to process--backed by what metrics were available--and a strong consensus across the project that the work was required. Jay, with full Design/UI team support, has lead the effort (and frankly done most of the work)--with some heavy lifting from a number of the devs. Folks simply have no idea just how tedious doing this correctly has been. Personally--Jay has my complete support, both for his vision and for his attention to doing the task correctly! Thank you! Keep going! Stuart
(In reply to V Stuart Foote from comment #33) > Folks, > > Other than Cor, and Eike and Sophie's very specific engagement on facets of > this reorganization of the calc menu UI--isn't the rest of this simply > "bikeshedding"? > > This is an agreed to process--backed by what metrics were available--and a > strong consensus across the project that the work was required. > > Jay, with full Design/UI team support, has lead the effort (and frankly done > most of the work)--with some heavy lifting from a number of the devs. Folks > simply have no idea just how tedious doing this correctly has been. > > Personally--Jay has my complete support, both for his vision and for his > attention to doing the task correctly! Thank you! Keep going! +1 Jay (and the design team :) has my full support and my help when he needs it Cheers Sophie
I understand your support for the Jay, however, is not listening to anyone's opinions but their own, you will soon encounter rejection users. Without dialogue with the simple user, you will move the project into the abyss
Couple points: 1) I specifically said feel free to ignore my opinion - understanding that the doers have the ultimate power; 2) I *only* suggested that the doers might want to consider weighing the status quo as having some value 3) I *only* said that *I* could not use the daily with these menus as they are in my day-to-day work, this *only* affects the project as far as I can't report bugs early as I'm not using master. If I am stuck using 5.0 indefinitely that's not a terribly bad thing for me personally (it gets the job done for me) so as far as that's concerned, not screaming from the rooftops to undo everything 4) I of course support doers doing - but I think the doers should be open minded to suggestions 5) A "process" is not set in stone - nor should it be wholly dependent on a ton of people having time in the middle of the day to join IRC chats, read lengthy minutes, and go through hundreds of emails. A user should be encouraged to offer suggestion for the doers to *consider* - this is clearly different from *demanding* that the doers change
(In reply to V Stuart Foote from comment #33) > Folks, > > Other than Cor, and Eike and Sophie's very specific engagement on facets of > this reorganization of the calc menu UI--isn't the rest of this simply > "bikeshedding"? > Let's not forget I was the "doer" for the dark ruler patch and you rejected it with the notion of "someone at some point might be able to do better." It's interesting how the opinion changes when you agree with the changes....
has there already be a response on comment #23?
(In reply to Cor Nouws from comment #38) > has there already be a response on comment #23? hardly, Yousuf does not like to explain WHY
(In reply to m.a.riosv from comment #23) > Is there any place, explaining the correlation between old menu positions > and where they are in the new one?, sure there is but I didn't find it. No nothing like that has been done, but it could be done. > I hope I'm wrong, but I can't imagine in how many situations we will need to > explain about this matter. I would assume we wouldnt need to explain about it other than that the menus have changed and users should navigate through them to see all the changes, as not only were entries moved, but new entries were added. It would be no different from a new user or a user of office 2003 coming to LO and the menus are a new thing to explore. > If you were so kind to complete the job and explain also in that place a bit > about the whys?, it would be helpful on the users support. What is remaining in the job that you wanted to see completed? The why's are given in comment 1 and comment 14 of bug 91781. (In reply to Joel Madero from comment #36) > 3) I *only* said that *I* could not use the daily with these menus as they > are in my day-to-day work, this *only* affects the project as far as I can't > report bugs early as I'm not using master. If I am stuck using 5.0 > indefinitely that's not a terribly bad thing for me personally (it gets the > job done for me) so as far as that's concerned, not screaming from the > rooftops to undo everything If you prefer the 5.0 layout, copy the menubar.xml file from a 5.0 user profile (e.g. ~/.config/libreofficedev/4/user/config/soffice.cfg/modules/scalc/menubar/menubar.xml) to a 5.1 user profile. In order for LO to create the menubar.xml file, you have to go into Tools > Customize, switch to the Menus tab and then move the 'Open...' entry down and then back up.
(In reply to Yousuf (Jay) Philips from comment #40) > (In reply to m.a.riosv from comment #23) > > Is there any place, explaining the correlation between old menu positions > > and where they are in the new one?, sure there is but I didn't find it. > > No nothing like that has been done, but it could be done. Jay, did you changed the help when needed? we won't provide help with false indications/explanations in it? If you have a listing of the changes/additions, maybe I could work on a FAQ article, do you have such list? Sophie
Joel have explained a lot of times that "doers" are libres to do what they want, so I need to assume that what they do it's always fine for the project, no explanations, no help, no guide, and of course nobody else have nothing to say, well we can say but as who preaches in the desert. Fortunately for the project, the software it's delivery as it is, so no one can claim about the millions of hours that will be lost around the world, searching for the new places in the menus, without any help or guide, searching for some help or guide in the computer or in the web, asking in forums, bothering other persons, IT services, consultants, etc. Usually electronic devices need electricity to work, what about the kWh expended, CO2 emitted? Have been the footprint evaluated. I thought we are green and responsible.-_- Who cares about the cost for professionals or companies?, wow, I forget, they can only give the thanks. But truly I'm a bit fool worried on this matter, it's easier, every time that we have some question about anything that's not in the help or anywhere, to search for who was/were the "doer(s)" and redirect the user to them, because only them will be able to give an adequate answer, guess I they can, of course if they come down to earth and wish to do so. The medals and the brightness are not for free. I we want to be responsible, the minimum is to put some information in the help menu or better a new main entry in the menu "Menu changes", at least with the moved options and where they are, but it's only an idiot's opinion, so the only way for me to be responsible it's forget this matter.
@Miguel Angel: most of the changes are documented in the release notes, see GUI part for example here https://wiki.documentfoundation.org/ReleaseNotes/5.0#GUI https://wiki.documentfoundation.org/ReleaseNotes/5.1#GUI and as you can see from here, translators are working on them too https://wiki.documentfoundation.org/Category:ReleaseNotes I could take the info from here, I was asking for a listing to go faster. Let see now if the corresponding help articles have been corrected at the same time as we discussed it some times ago at the ESC. Sophie
Hi, (In reply to Eike Rathke from comment #9) > * Names Cells > * Was in the Insert menu as Names. > * The new name "Names Cells" doesn't make sense; if we change the > name then to "Named Expressions", but not to Names Cells. As this menu item is used to name cells or expressions, it seems to me that neither "Names Cells" nor "Named Expressions" are suitable. "Names" is certainly too succinct, but IMHO mention only one of the two options is not relevant. (In reply to Eike Rathke from comment #13) > [...] A reference is a subexpression (can be used as > part of a formula), the unifying term for all you can enter there is > "named expression". That's right (a reference is a subexpression), but difficult to understand for an ordinary user. May I suggest: There would be a very simple solution like "Named Cells or Expressions". It is exhaustive and understandable by all and allowed because menu entries can be quite long. Best regards, Michel
(In reply to sophie from comment #41) > Jay, did you changed the help when needed? we won't provide help with false > indications/explanations in it? If you have a listing of the > changes/additions, maybe I could work on a FAQ article, do you have such > list? Sophie I was able to complete File, Edit and View in all the modules, so it is about half complete. I dont have a listing of all the changes, but i think Heiko is working on a list, as well an blog post for the design blog. (In reply to Michel Rudelle from comment #44) > May I suggest: There would be a very simple solution like "Named Cells or > Expressions". It is exhaustive and understandable by all and allowed because > menu entries can be quite long. Thanks for the suggestion Michel. Dont know why i didnt think of this myself. :D
Hi, Yousuf. Item "Fill cell" in menu "Sheet" inconvenient to use. Even knowing about the changes in the menu, I've been searching this item. It should be placed in the Data menu. It is more logical. ps: I would like to see the opinions of other users
(In reply to kompilainenn from comment #46) > Hi, Yousuf. Item "Fill cell" in menu "Sheet" inconvenient to use. Even > knowing about the changes in the menu, I've been searching this item. It > should be placed in the Data menu. It is more logical. Hey kompilainenn, The Data menu is for working with data already present in your sheet (sort, autofilter, pivot table, etc), so thats why i dont think that would be the correct place for it. It used to be Edit > Fill, but was moved from there as the Edit menu is for edit functions (undo, cut, track changes, edit object, edit mode). Also we needed to bring all cell related functions under one roof - insert cell, delete cell, filling cell with data, managing cell comment, clearing cell data, and changing cell references.
(In reply to Yousuf (Jay) Philips from comment #47) > (In reply to kompilainenn from comment #46) > > Hi, Yousuf. Item "Fill cell" in menu "Sheet" inconvenient to use. Even > > knowing about the changes in the menu, I've been searching this item. It > > should be placed in the Data menu. It is more logical. > > Hey kompilainenn, > > The Data menu is for working with data already present in your sheet (sort, > autofilter, pivot table, etc), so thats why i dont think that would be the > correct place for it. It used to be Edit > Fill, but was moved from there as > the Edit menu is for edit functions (undo, cut, track changes, edit object, > edit mode). Also we needed to bring all cell related functions under one > roof - insert cell, delete cell, filling cell with data, managing cell > comment, clearing cell data, and changing cell references. I disagree. In the menu Sheet - adding or removing cells - yes, the operation of the sheet - yes, add or delete rows and columns - yes. Filling cells DATA - no, delete data from the cell - no. Data operations (adding, modifying or deleting) must be in the Data menu. Thank you for attention.
(In reply to kompilainenn from comment #48) > I disagree. In the menu Sheet - adding or removing cells - yes, the > operation of the sheet - yes, add or delete rows and columns - yes. Filling > cells DATA - no, delete data from the cell - no. So according to your thinking, where should we place cell comment and cell references, as you didnt address those. > Data operations (adding, modifying or deleting) must be in the Data menu. I wouldnt call adding and removing data from a cell a data operation, as if that were so, we should move Cut, Copy and Paste under Data as well. The point here is that a user shouldnt need to open the Data menu unless there is data in his/her sheet. Here is what it says in the help about the Data menu - "Use the Data menu commands to edit the data in the current sheet. You can define ranges, sort and filter the data, calculate results, outline data, and create a pivot table."
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2ca0749440442fb141cf8862b62b5272bc07b5a tdf#91820 A round of minor tweaks to Calc'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.
(In reply to Yousuf (Jay) Philips from comment #49) > menu - "Use the Data menu commands to edit the data in the current sheet. > You can define ranges, sort and filter the data, calculate results, outline > data, and create a pivot table." This is not true anymore, creating pivot table is now in Insert and I would consider it as a bug. Pivot table is a type of data analysis, you are creating just a new view/interpretation of existing data (similarly to filters or statistical analysis - all from Data), not inserting a new object like image. The comments above does not seem to support the move to Insert - could the change be revised?
(In reply to Stanislav Horacek from comment #51) > (In reply to Yousuf (Jay) Philips from comment #49) > > menu - "Use the Data menu commands to edit the data in the current sheet. > > You can define ranges, sort and filter the data, calculate results, outline > > data, and create a pivot table." > > This is not true anymore, creating pivot table is now in Insert and I would > consider it as a bug. > > Pivot table is a type of data analysis, you are creating just a new > view/interpretation of existing data (similarly to filters or statistical > analysis - all from Data), not inserting a new object like image. > > The comments above does not seem to support the move to Insert - could the > change be revised? may be rename "Insert Pivot Table" to "Create Pivot Table" and really move it to menu "Data"?
(In reply to kompilainenn from comment #52) > > may be rename "Insert Pivot Table" to "Create Pivot Table" and really move > it to menu "Data"? I've had multiple calls on the fact that "pivot tables" don't work any more. It's rather counter intuitive atm..
(In reply to Stanislav Horacek from comment #51) > Pivot table is a type of data analysis, you are creating just a new > view/interpretation of existing data (similarly to filters or statistical > analysis - all from Data), not inserting a new object like image. I agree with you that pivot table is about data analysis, but the insert menu is not limited to just objects like an image, as you can insert a comment, hyperlink, function, etc. Similar to a chart, pivot table utilizes existing data on a sheet to render that data in a different way. > The comments above does not seem to support the move to Insert - could the > change be revised? There can be exceptions to the rule of having unique locations in the menu for each function and it seems this likely will be one of them. So i'll add an additional entry in the data menu for it. https://gerrit.libreoffice.org/27925 (In reply to kompilainenn from comment #52) > may be rename "Insert Pivot Table" to "Create Pivot Table" and really move > it to menu "Data"? The word create or add could be substituted for insert with many of the entries in the insert menu. Are we inserting or creating a chart, textbox, or shape? (In reply to Cor Nouws from comment #53) > I've had multiple calls on the fact that "pivot tables" don't work any more. > It's rather counter intuitive atm.. You cant please everyone with the reorganization of menus, luckily people still have the ability to customized them.
(In reply to Yousuf (Jay) Philips from comment #54) > There can be exceptions to the rule of having unique locations in the menu > for each function and it seems this likely will be one of them. So i'll add > an additional entry in the data menu for it. > > https://gerrit.libreoffice.org/27925 I think that's a good idea. Thanks. (Another user request on the Dutch list today - is going to be a FAQ ;) )
(In reply to Yousuf (Jay) Philips from comment #54) > (In reply to Stanislav Horacek from comment #51) > > Pivot table is a type of data analysis, you are creating just a new > > view/interpretation of existing data (similarly to filters or statistical > > analysis - all from Data), not inserting a new object like image. > > I agree with you that pivot table is about data analysis, but the insert > menu is not limited to just objects like an image, as you can insert a > comment, hyperlink, function, etc. Similar to a chart, pivot table utilizes > existing data on a sheet to render that data in a different way. Yes, Chart is the only Insert item dealing with existing data (when thinking about that, it would work in Data for me as well;) - but it inserts a new complex object controlled by completely different menus and toolbars. Pivot table is represented only by cells and filters - hence I would see it as something really close to filters. > There can be exceptions to the rule of having unique locations in the menu > for each function and it seems this likely will be one of them. So i'll add > an additional entry in the data menu for it. > > https://gerrit.libreoffice.org/27925 Maybe the duplicity is suboptimal, but surely better than the current state. Thanks, Jay! (Similarly to Cor's experience, my suggestion was inspired by a frustrated user who started to use AOO because he thought that LO contained a bug preventing creating pivot tables.)
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc25f08521ba73c4d5141c8c9b020de26159b1ed tdf#91820 Correct insert date and time labels in 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=79bca854451a24dd9cf17f8befaccfcb40d996fa tdf#91820 Add insert pivot table to data 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.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=606894486d7eb85d9748675ef4ef5bda12846753 tdf#91820 Add name and description to Format 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=191b4d964458a052f491521d41eed2f7a7792156 tdf#91820 Add Insert > Form Control submenu into Calc 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=a25b1ff25a3be97d688d66b12353b4217fd239a5 tdf#91820 - Toggle sheet grid is per sheet option 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=961fae9d75caf0cf52af62fdf9d9676ab0ab556f tdf#91820 Add design mode and image original size to menu 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f4c4e407c6731f37769d6ffaaadbf3a07951a594 tdf#91820 Add cell style and spreadsheet theme command 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b46552194dc41d0f3eabea373c36181878e8729f tdf#91820 Move cells styles to their own main menu entry It will be available in 5.5.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 Commit Notification from comment #65) > Yousuf Philips committed a patch related to this issue. > > tdf#91820 Move cells styles to their own main menu entry > Hi Yousuf, it is great to hear that Calc cell styles and spreadsheet themes receive some more love. Related to cell styles/table themes, is there a plan to add some nicer, more modern, styles? Maybe there is some overlap with the UX implementation done on the new Writer table styles and maybe one could reuse the ideas/styles collected there for Calc, too. Thanks for your work!
(In reply to Gerry from comment #66) > Hi Yousuf, it is great to hear that Calc cell styles and spreadsheet themes > receive some more love. Related to cell styles/table themes, is there a plan > to add some nicer, more modern, styles? We added a new set of nice and modern cell styles in 5.3 (bug 90937). > Maybe there is some overlap with the > UX implementation done on the new Writer table styles and maybe one could > reuse the ideas/styles collected there for Calc, too. Hopefully when its fully implemented in writer, it can be ported also to Calc. > Thanks for your work! Glad to help.
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=d8b18479b178b96eb86cde5ae21ae916f24895e0&h=libreoffice-5-4 tdf#91820 Add cell style and spreadsheet theme command 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8bd2d900ae67fe7c7253fbc6d04d3e5b73eaf12 Change ~Styles to St~yles to resolve clash with ~Sheet, tdf#91820 follow-up 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=82e88b91665c8954eba1333577627a520140630d tdf#91820 Add insert field commands to Insert 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=41e71a7c6f10eeca0d7bc083fc68dc85d9f2a986 tdf#91820 Round of improvements to Calc'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.
(In reply to Commit Notification from comment #71) > Yousuf Philips committed a patch related to this issue. > It has been pushed to "master": > > tdf#91820 Round of improvements to Calc's menus for 6.0 > > It will be available in 6.1.0. > If I'm not wrong, several sheets can be hidden at once.
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=04b50d4b6fd944313fd5164598f64ef787645692&h=libreoffice-6-0 tdf#91820 Round of improvements to Calc'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.
(In reply to m.a.riosv from comment #72) > If I'm not wrong, several sheets can be hidden at once. If selected, yes multiple sheets can be hidden, but without selection only the current sheet is hidden, and there is no means to have dedicated labels for single sheet selection and multiple sheet selection.
Sorry I don't understand such approach, why not Sheet(s). So the user can know that is possible hide several at once. But if it makes you happy, let it go.
(In reply to m.a.riosv from comment #75) > Sorry I don't understand such approach, why not Sheet(s). So the user can > know that is possible hide several at once. We dont use '(s)' in our labels, we either go singular or plural when its possible to do an action 1 or more times. The '(s)' concept may work for english and some languages but doesnt with other languages (e.g. arabic) where a different word is used. > But if it makes you happy, let it go. I'm not changing it to make me happy, i'm changing it for better uniformity with other related commands. Right-click on a sheet tab and all the commands except 'Hide Sheets' used the singular 'Sheet' even though many of the command can also work with multiple sheets.
(In reply to Yousuf Philips (jay) from comment #76) > [...] > I'm not changing it to make me happy, i'm changing it for better uniformity > with other related commands. Right-click on a sheet tab and all the commands > except 'Hide Sheets' used the singular 'Sheet' even though many of the > command can also work with multiple sheets. Doing that you add ambiguity: user may ask if the command acts on the selected sheets or only on the current sheet. It would be better if the command wording was adapted to the number of selected sheets. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #77) > > It would be better if the command wording was adapted to the number of > selected sheets. > Why? Such contextually aware changes impose overhead and complexity. Adding needed logic to menu and button labels would not trivial to solve, and the "solution" still would need to be localized. Leave it alone--the static labels as pluralized now are functional and suited to use.
Heiko, this is older bug assigned to Yousuf, he is not active, I think. I didn't read the bug itself, but wrap-up would be most useful.