Bug 161031 - Form creating is too niche to merit a main menu item visible by default
Summary: Form creating is too niche to merit a main menu item visible by default
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Form-Controls
  Show dependency treegraph
 
Reported: 2024-05-10 16:52 UTC by Eyal Rozenberg
Modified: 2024-05-23 07:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-05-10 16:52:02 UTC
LO Writer currently has the following main menu items:

File | Edit | View | Insert | Format | Styles | Table | Form | Tools | Window | Help

I submit, that the creation of forms and form control, in a document without forms to begin with, is niche enough, that it does not merit its own main menubar item, it's own top-level menu.

Instead, I suggest that the menu become visible under any of the following conditions:

1. Activating it, using a checkbox to be placed in one of the other menus (e.g. Tools)
2. Having made a setting in Toos | Options... to always have the Forms menu visible
3. (Perhaps) opening a document which has forms/form controls, in non-Read-Only mode

What say you?
Comment 1 Heiko Tietze 2024-05-13 14:21:05 UTC
Maybe make it visible if the Design Mode is enabled? And move this item to the Edit menu.
Comment 2 Eyal Rozenberg 2024-05-13 14:26:23 UTC
(In reply to Heiko Tietze from comment #1)
> Maybe make it visible if the Design Mode is enabled? And move this item to
> the Edit menu.

That's one possibility, certainly. It might fit near the 'Edit Mode' menu entry.
Comment 3 jan d 2024-05-14 16:01:21 UTC
I also assume that "Form" is rarely used. 

Does it make sense to create a conditional logic for its activation at the top level or is it better to group it into another menu (e.g. insert)? Conditional logic seems tricky to test and maintain.

I remember that in some update several top level menu points were added (I guess, form was among them). Do we know what triggered the changes back then?
Comment 4 Eyal Rozenberg 2024-05-14 16:38:17 UTC
(In reply to jan d from comment #3)
> I also assume that "Form" is rarely used. 

Well... rare for most users, but frequent for some users. And the same goes, I suppose, for some other features on our menus.

> Does it make sense to create a conditional logic for its activation at the
> top level or is it better to group it into another menu (e.g. insert)?

I'm not 100% sure. I would want people who actually use the menu to chime in. It might, because:

1. It's not a small menu, and has some submenus as well. creating a very large submenu of Insert, with a third-level menu, seems rather unwieldy.

2. The original designers of the menu wanted it to exist, and found it useful. I don't know that their considerations are invalid (and would like to understand what they were, a questio you've also brought)
.
> Conditional logic seems tricky to test and maintain.

Is it, though? There are lots of menu items whose state has conditional aspects, like being toggled or not, grayed out or not... why not also the aspect of being visible or not.
Comment 5 Heiko Tietze 2024-05-23 06:44:03 UTC
We discussed the topic in the design meeting.

The menu was introduced to align the number of root items across different modules, IIRC. Another long list of items that might be worth to show is the Shapes. And while we may show one of the two conditionally like "View > [ ] Show Forms Menu" or "[ ] Show Shapes Menu" this is would be quite uncommon. And changes to the main menu are very unpleasant for the users. So without a very good reason we better not change the default (customization is always possible).
Comment 6 Eyal Rozenberg 2024-05-23 07:08:13 UTC
Our agreement at the meeting was on WONTFIX.