Please add a not what UI element exactly you have in mind. "Edit" is quite generic and my first thought was the main menu. The second is the Styles & Formatting deck at the sidebar and the top-right button, though this is not labelled Edit.

All of five of the commands I mentioned can be found at the bottom of the Styles submenu of the main menu. The names I give in quotes are the names in the customize dialog.

The "Edit" command I mention is labeled "Edit Style..." in the UI, both in the main menu and in the context menu.

"New", "Update", and "Load Styles" are found in the main menu and in the plus button on the styles sidebar.

"Styles" is labeled "Manage Styles" in the main menu, and is bound to F11.

So this is about Tools > Customize > Keyboard where .uno:EditStyle is listed under Templates, for example. Agreed, we need to reorder.

About "Edit" vs "Edit Style", the latter is the tooltip and not always appropriate - actually I wish it was never and would provide more information than today.

There are several issues in this ticket.

1. About ”Load Styles”
Here is a patch that recategorizes Load Styles out of ”Format” and into Templates which seems more appropriate (for now). 

https://gerrit.libreoffice.org/c/core/+/133147

2. About ”New” and ”Update” – 
As noted in comment 2, the (Writer) ”Styles” menu has the following commands (at the bottom):

   Edit Style...
   Update Selected Style
   New Styles from Selection
   Load Styles from Template

As noted in OP,  all these commands are (now with patch) categorized as ”Template” (even if, as OP notes, it is not appropriate).  

But @Heiko, there is no obvious other category to use for these commands.
(I believe ”Styles” is a special category that is populated with the loaded styles). 

3. About Styles (F11) (.uno:DesignerDialog).  Same problem as previous point. 
At present, the command is located in Format, but none of the other choices seem particularly appropriate. (and it could just as well be moved to Template for now, given the other commands already categorized there.)

4. Finally – the issue of ”tooltip” for Edit/Edit Style is not so simple because .uno:EditStyle is used in many contexts, both across applications and toolbars/menus (see bug 107120 comment 11 for a way to approach the issue.)

In sum, points 2 and 3 needsUXEval to assess whether other categories are needed, while point 4 may need a more systematic approach/evaluation, not just a single change to the tooltip Label in GenericCommands.xcu.

(In reply to sdc.blanco from comment #8)
> (In reply to Heiko Tietze from comment #7)
> Checking to be sure that your response to comment 6 is in relation to the
> Customize dialog (which is what the OP is about) and not the menubar.

Okay, if it's still the customization... If we cannot use Styles the Templates category works for me. Would search for the function anyway rather than using some "random" category or to read all the entries under Format.

The (Manage) Styles function could go into the View category.

(In reply to Heiko Tietze from comment #9)
> The (Manage) Styles function could go into the View category.
Ack. Better than Format at least.

> Okay, if it's still the customization... If we cannot use Styles the
> Templates category works for me.
Do you know if it is possible to use the Styles category for commands? I could not determine if it was possible (or see how to do it). 

The (implicit) question to UXEval was whether another category should be added (e.g., "Style Editing") that could collect together the different style editing commands.

I can see now that not all commands are categorized (e.g., Character .uno:FontDialog).

> Would search for the function anyway rather than using 
> some "random" category or to read all the entries under Format.
Fine for Eve. For Benjamin, in principle, the categories can be a way to discover what kinds of commands exist and can be customized.

But maybe it is time for @Kenneth to say a little more about how/why this issue came up.

Seth Chaiklin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8831d4ebbf8253327f4f0024035ff310ae233e43

tdf#131760 change category of Load Styles

It will be available in 7.4.0.

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

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

Seth Chaiklin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/40559dd30db04ab67d27fafe1e0c928757f7e7c0

tdf#131760 change category of Styles command

It will be available in 7.4.0.

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

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

The topic was on the agenda of the design meeting and we appreciate your work. If the category Styles cannot be used a similar name like "Style Functions" works as well.

(In reply to Heiko Tietze from comment #13)
> If the category Styles cannot be used a similar name like "Style
> Functions" works as well.
In this concrete case, how about:

Templates --> Styles and Templates

Reasons:
1. not so many entries in Templates 
2. a Styles Functions would not have many entries either (and Templates would have even fewer if split up).
3. Could be an advantage to highlight the connections between templates, the updating styles functions, and styles in general.
4.  Maybe would address most of the concerns of the OP -- (without hearing further from the OP).
5. Easier to do than adding a new category.

Me would not expect templates being a source of styles. Don't see a benefit from loading just the styles- why not configure the template so it has no additional modification to the default? That's why I hesitate to put style focused functions together with templates. 

Do we need a category at all? My take is to get rid of the tab and all categories and have it at the commands list, see https://design.blog.documentfoundation.org/2015/01/22/how-to-make-libreoffice-customization-usable/

(In reply to Heiko Tietze from comment #15)
> Me would not expect templates being a source of styles. Don't see a benefit
> from loading just the styles-
The "Load Styles from Template" command, which is now moved to Templates, can be used to load additional styles into a document. (fwiw, I keep a set of specialized templates with specialized styles and use this command to load them as needed to particular documents).  But -- that was just to answer your (possibly rhetorical) question. 

> Do we need a category at all? My take is to get rid of the tab and all
> categories and have it at the commands list, 
Ok -- but then close this bug as WF. (-: 

More seriously -- is your point that it is not worth the trouble to invest more effort here with the categorization, because the whole thing will be dropped -- at some point?  Just trying to figure out how to resolve this ticket....

I hope it will become obsolete but wont do it myself. And I think it's not worth to put much effort in. Not to hard to find a command and browsing through categories is not a task.

(In reply to Heiko Tietze from comment #17)
> I hope it will become obsolete but wont do it myself. And I think it's not
> worth to put much effort in. 
In this light, not much point in creating a new "Style Functions" category and when "Styles and Templates" is rejected, then I cannot see that much more can be done for now, so I pass the baton to others.

Would still be interesting to hear from @Kenneth about thoughts or experiences that motivated this ticket.

(In reply to sdc.blanco from comment #18)
> Would still be interesting to hear from @Kenneth about thoughts or experiences that motivated this ticket.

Sorry for the delay. Thank you for looking into this.

The current customization menus are extremely confusing due to a combination of (1) inconsistent naming conventions, (2) duplicate names, (3) names that don't match the application menus, (4) miscategorized commands. Currently, it is excessively difficicult find the command you are looking for, whether by searching for the name, browsing by category, or sometimes both. When you've found something, you don't actually know what it does.

It seems quite obvious to me that this is a usability problem for *ALL* users.

When I investigated and first reported these bugs, I got the impression that there were implementation issues that made it difficult to fix the command names. I don't know whether the situation has changed. In the meantime, at least fixing the categories would help a lot.

(In reply to sdc.blanco from comment #10)
> I can see now that not all commands are categorized (e.g., Character .uno:FontDialog).

Yet another problem!

(In reply to sdc.blanco from comment #10)
> Do you know if it is possible to use the Styles category for commands? I could not determine if it was possible (or see how to do it).

(In reply to Heiko Tietze from comment #13)
> The topic was on the agenda of the design meeting and we appreciate your
> work. If the category Styles cannot be used a similar name like "Style
> Functions" works as well.

I never saw an answer as to whether the current "Styles" category can be used. If so, this seems like the the obvious thing to do. If not, Heiko's solution seems sensible to me. The result might not be ideal, but it would be an improvement.

(In reply to sdc.blanco from comment #14)
> In this concrete case, how about:
> Templates --> Styles and Templates
> a Styles Functions would not have many entries either (and Templates would have even fewer if split up).

I don't understand the problem with having categories with few entries. As Heiko mentioned somewhere, they don't have anything to do with each other (or any other category).

A combined Styles and Templates category could be workable if others insist on it, but note that the names of the commands *must* be fixed to disambiguate. You can't just have "New", "Edit", and so on in a mixed category. This is exactly the problem with searching by name in all categories.

(In reply to Heiko Tietze from comment #15)
> Do we need a category at all? My take is to get rid of the tab and all
> categories and have it at the commands list, see
> https://design.blog.documentfoundation.org/2015/01/22/how-to-make-
> libreoffice-customization-usable/

This is a terrible idea. There is a huge benefit to being able to filter a monstrous list, or to browse by category. This would be true even if not for the problems I reiterate here.

(In reply to Kenneth Hanson from comment #19)
Thanks for giving your thoughts Kenneth. Good to have the motivating POV for the OP.

> The current customization menus are extremely confusing 
> excessively difficult ….
> usability problem for *ALL* users.
Ack.  Command names issue goes far beyond categorization, but understand that sensible categorization in existing Customize dialog can be an improvement. 

> difficult to fix the command names.
The problem arises because some commands (e.g., the one labelled “Edit”) are used in different applications, so in Writer, the command that appears as “Edit” edits Paragraph Style, but in Impress the same command “Edit” will edit Graphic Styles, hence the neutral (and hard to interpret) "Edit". 

However, there is a technical solution, designed exactly for this purpose, where it is possible to make an alias just for Writer, and another for Impress (and a third for Calc...), each with its own (more meaningful)  “name”,  appropriate tooltip, label, etc. But then it becomes necessary to find and change the right toolbars and menus (across the different applications) so that the right alias is appearing on all the right toolbars and menus, and not appearing where it shouldn’t (where there can easily be dozens of menus and toolbars to check). In short, a tedious task, that must be done with high (about 100%) accuracy. Not difficult technically, but not the sort of thing to attract voluntary efforts. 

(Same issue with changing "Edit" to "Edit Style". Maybe it would work, but would require a lot of checking/testing to see the consequences because the command is used in many places).

> names of commands *must* be fixed to disambiguate. 
> can't just have "New", "Edit", and so on in a mixed category.
> This is exactly the problem with searching by name in all categories.
Agreed. In some individual cases, it may be possible (i.e., relatively easy) to make name improvements. (e.g., bug 134432). In other cases, such as Edit (and probably several others), then the just-mentioned complications arise. To evaluate and revise command names requires knowing what the command does, discover where it used, and decide what aliases are needed, as well as get acceptance about possible changes. Not exciting work.

The point of these explanations is to give a hypothesis for why your sensible suggestions have not been tackled systematically.

> (In reply to sdc.blanco from comment #10)
> > not all commands are categorized (e.g., Character 
My mistake. It was categorized.  I believe now all commands are categorized.
 
>never saw an answer as to whether the current "Styles" category can be used.
No definitive answer, but my best guess (from looking at the source code) is it cannot be done in a simple, nontrivial way, so then it becomes a question of whether it will be accepted to make a special change in the source code to allow this. 


Not to sweep the general issue away, but perhaps this ticket should be closed – because it has too many issues running here. 

My friendly recommendation:
 - file a new ticket requesting large-scale, systematic evaluation and revision of the existing Customize dialog  (if it does not already exist – I have not searched). Then that “big idea” is available (and Heiko can add his link to an alternative vision).

 - meanwhile – as a completely different strategy – file bug reports in relation to specific difficulties with specific command names or categories, etc. when using the existing interface (such as you did here). 

That strategy does not immediately address the global problems that you have raised here, but if you think that small, incremental changes to the existing dialog are also worthwhile (or better than nothing), then it may slowly start to reduce some of the “noise”.

If you follow that strategy, then there is an advantage to have each report focus on one specific limited issue. If you file 10 different tickets for 10 different, specific problems, so be it. If each one is clear, limited, focused, then there is a much better chance that someone actually might address it. (see bug 129549 as example). 

So – to repeat myself:
> cannot see that much more can be done for now, so I pass the baton to others.

(In reply to Kenneth Hanson from comment #19)
> > Do we need a category at all?...
> This is a terrible idea. There is a huge benefit to being able to filter a
> monstrous list, or to browse by category.

It would still be possible to search by name, of course. But as you commented the expectation of categories is that commands follows the menu structure, which is wrong.

(In reply to sdc.blanco from comment #20)
>  - file a new ticket requesting large-scale, systematic evaluation and
> revision of the existing Customize dialog

bug 115527

> > cannot see that much more can be done for now, so I pass the baton to others.

Resolve this ticket as WF/DUP?

@Kenneth -- .
> Resolve this ticket as WF/DUP?
DUP(licate) is a good choice. You will be added automatically to the cc: list for the other ticket, and a duplicate contributes to moving the issue over a threshold where it would get more focus. 

You can actually makr this ticket as a DUP yourself.  Look under the "Comment box" - there is a "Mark as Duplicate" link, click on that and write 115527 as the duplicate number.

*** This bug has been marked as a duplicate of bug 115527 ***