Suggestions on menu structure

[daubnet]

As noted in another thread, I'm currently working on a german translation of Sigil. While working on that a few inconsistencies came up that I'd like to point out.

The "Tools" menu. The usual german translation for "Tools" in menus is "Extras", having the exact same meaning as the english word "extras". This "Extras" has been around for as long as there is a MS-Word with a Tools-menu. Apart from the inconsistency between whatever is considered an "extra" and whatever might be a "tool", it has always been a list of assorted functions that Microsoft didn't find any better place to put. What started out as an innocent menu with just a few items became one of the biggest distractions when working with Word, because you had no idea where to search for a menu command. Quick example: "Word Count..." is that a tool? an extra? May be it's somewhere in File, because it works on the whole file? Or is that a view? You guessed it: It ended up in the "Tools" menu. Just like "Protect Document", which very clearly works on files. I could go on ranting for hours, but to get back to business: I'd like to see the Tools menu being reworked, or - if possible - actually to go away.

This is my approach on how it could be changed:

Even before writing this I had always wondered why it is Tools->Meta Editor, opposed to Edit->Metadata.

Likewise, I think "Tools->Split on SGF Chapter Markers" should be "Insert->Chapter Breaks at SGF Chapter Markers" - and while we're at it, the term "SGF" is distracting. "Insert Sigil Chapter Marker" and "Insert Chapter Breaks at Sigil Chapter Markers" make a lot more sense to me. (To be totally honest, I don't understand why anyone would want to insert markers first, and then turn them into breaks, when they could've inserted chapter breaks right away, but may be that's just me.)

"HTML Tidy" actually isn't a tool, but an editing option, I'm not sure where that should go - I think it belongs in the program preferences (which currently don't exist, but which seem to be coming our way in 0.5), or may be as a clickable indicator in the status bar as well.

The only item in the tools menu that actually *is* a tool is the validator. Since it works on entire files, I think it should go in the File menu. "File->Validate" makes a lot of sense to me, more so than "Tools->Validate" does. I assume that validating in the background would require a lot of coding and raise performance issues, otherwise an automatic validation would be a nice alternative that could turn such a command into a simple view that can be turned on and off.

For the time being I've translated the menu items to closely resemble their English original - including things like "SGF". The above is only a suggestion in which direction I'd like to see the menu structure going. I'd love to see other people comment on this, to see whether I'm alone in my resentment against the "assorted commands that didn't fit anywhere" menu.

[theducks]

I have to agree the TEXT menus are a bit odd.

IMHO (because toolbars can not be hidden) they are a a Text replication of a toolbar.

My ideal text menu:

File
Edit
View
Window
Help

Validate belongs on the File menu as it applies to the whole
The current Format and Insert s/b a sub-menu of Edit
Split is a Edit function (I believe it only applies to the current segment)

Book Browser, Validate Results and TOC belong on the Window Menu


Just my 2 cents

I just noted that various toolbars CAN be hidden by a Right click.
IMHO
A toolbar master control should probably added to View

[user_none]

Keep the ideas coming. I like what has been suggested so far.

Originally Posted by daubnet

"HTML Tidy" actually isn't a tool, but an editing option, I'm not sure where that should go - I think it belongs in the program preferences (which currently don't exist, but which seem to be coming our way in 0.5), or may be as a clickable indicator in the status bar as well.

There is a clickable indicator in the tool bar.

Originally Posted by theducks

IMHO (because toolbars can not be hidden) they are a a Text replication of a toolbar.

The toolbar is just there for connivence. My preference is to have everything available via the menubar. Then have common ones in the toolbar.

Originally Posted by theducks

A toolbar master control should probably added to View

Great idea!

[DaleDe]

Originally Posted by user_none

The toolbar is just there for connivence. My preference is to have everything available via the menubar. Then have common ones in the toolbar.

I really support the idea of everything available on the menubar. It makes the program easier to use by allowing the user to easily find everything. It took me a long time to discover the import HTML as it was not on the menubar but a magic right click. I hate magic right clicks, they should always be used to speed up operations, not as the only way to do things.

Dale

[daubnet]

Originally Posted by theducks

The current Format and Insert s/b a sub-menu of Edit

Hiding "Insert" and "Format" inside the "Edit" menu is going to hide the commands pretty deep, and will require lots of clicking for very commonly used commands.

Sigil is a document-centric application. I believe there are good reasons to arrange the menus in a way that looks familiar to what other document-centric apps look like. So lets look at the menus of two very widespread applications: LibreOffice and Word (2003, because it still had menus, and not a ribbon)





They have almost identical menus, only "Table" and "Tools" are reversed in Word - the LibreOffice version is more logical. Unless there is a good reason not to, I'd vote to stick to these menus:

• File
• Edit
• View
• Insert
• Format
• Tools (if really, really needed)
• Window
• Help

Originally Posted by DaleDe

I really support the idea of everything available on the menubar. It makes the program easier to use by allowing the user to easily find everything. It took me a long time to discover the import HTML as it was not on the menubar but a magic right click. I hate magic right clicks, they should always be used to speed up operations, not as the only way to do things.

True. However, this will require a small change. Currently we have

• "Add New Item" in the Text folder
• "Add New Item" in the Styles folder
• "Add Existing Item(s)..." in all folders

Because the first two actually do different things, they would have to be renamed to "Add New Text" and "Add New Stylesheet" so they could then be put inside the Insert menu. I believe this greatly enhances the discoverability of these commands. BTW, I'd personally rephrase "Add Existing Item(s)" as "Add from File(s)".

Are there any other commands that are currently hard to discover, because they're not in the menu?

Edit: I just noticed this: "Insert Chapter Break" with the cursor at the very end of the last text file actually does the same as "Add New Text". And it probably should be "Add New Chapter".

[user_none]

I've made some changes to the menus.

Format I think is fine. Insert I want to get rid of because many of the items work in other places. Tools I want to get rid of as well. This will happen in the 0.6 release as I plan on making tidy and well-formed checking manual operations. I think they're worth keeping in the menu in 0.5 as many people use them to toggle these options on the fly.

I've added some new menu options for creating new item and inserting existing items.

@daubnet, other than removing insert the menus are what you've described. Insert can easily come back once there are enough items to make it necessary.

Some of the item descriptions could probably use some work... If any one has input on the refined menu structure (though only people running from source are liable to see it) speak up.

[theducks]

Add New Item -> Add Blank Item (on Browser Right-click)
Insert Image... -> Place Image: Add existing, repeat usage
Insert Chapter Break -> Split Chapter Section(?) [How well does this translate?]

just some ideas

[daubnet]

Commands from the Format and Insert menus are actually editing commands, so they can easily become part of the Edit menu. This is fine if - and only if - there are just a few. MS-Word (and LibreOffice as well) allows you to insert so many different things into a document that it really needed an extra menu.

So let's count what we currently have: 3 commands in "Insert", one from "Tools" and three new candidates which in 0.4 were just available in the Book View's context menu: Add blank chapter, Add blank style sheet, Add from File. That gives me a total of 7 commands.

The current "Edit" menu has 8 commands. While I think that a total of 15 is still fine, there is a good chance of more items being added to the menu over time, which might make it necessary to split them into two menus again.

The Format menu could have a submenu with the H1-H6 styles in it, plus some items to switch from LTR to RTL. Alternatively, those could be made available in a format dialog.

[user_none]

Originally Posted by daubnet

Commands from the Format and Insert menus are actually editing commands, so they can easily become part of the Edit menu. This is fine if - and only if - there are just a few.

I agree. This is why I'm keeping the Format menu separate. The insert commands are now in the Edit menu. I've put the add blank / existing file commands into a sub menu in the File menu.

Originally Posted by daubnet

The Format menu could have a submenu with the H1-H6 styles in it...

h1-6 have already been added to the Format menu.

[daubnet]

Originally Posted by user_none

I've put the add blank / existing file commands into a sub menu in the File menu.

I don't think that is a good idea. The "File" menu usually relates to the whole document you're working on, not to parts of it which just happen to be files themselves. E.g.: "Insert Image" is not part of the File menu (and shouldn't), even though it pops up a "file open"-dialog, and operates on that file. It is an editing command, and thus should go in the Edit menu (or, if that is split into multiple menus, the Insert menu or submenu).
Adding a new section to a book is an editing command, and actually does almost the same as the "Insert Chapter Break" command. Both technically create a file inside the ZIP archive, but more importantly, they change the current document.
For all practical purposes, that first menu could be renamed from "File" to "Book". So any command that doesn't work with a book doesn't really belong there.

Good references:
(please take look at the gnome guidelines, which is the only place I could find that specifically says when to use an Insert menu (see 4.4.2.3), and gives a list of standard menu items that should go into such a menu (see 4.4.4), including the "Insert From File..." item.
GNOME Human Interface Guidelines
MacOs X 10.7 Human Interface Guidelines
Windows (7) User Experience Interaction Guidelines
unfortunately, the KDE Human Interface Guidelines are a joke.

Originally Posted by user_none

h1-6 have already been added to the Format menu.

Meh. I'm late to the party

[user_none]

Originally Posted by daubnet

I don't think that is a good idea. The "File" menu usually relates to the whole document you're working on...

Qt Creator and Eclipse both put this behavior as part of the file menu.

Originally Posted by daubnet

Good references: ...

Thanks, these will be helpful, I'll take a look.

[mvo]

I started drafting up my ideal menu structure, then realized - I agree with daubnet's suggestions. Also, thanks for those references

[daubnet]

Originally Posted by user_none

Qt Creator and Eclipse both put this behavior as part of the file menu.

Please note that neither is a document centric application.

[user_none]

Originally Posted by daubnet

Please note that neither is a document centric application.

How are two editors who's sole purpose is editing documents not a document centric app?

[daubnet]

A "document-centric application" is one where you open a file that you work on. It is not important that the file contains text.

Examples of document-centric applications:

• Wordprocessors
• Spreadsheets
• Image Manipulation Applications

Common theme: The concept of where things are stored is simple. The program works with one file at any time (let's ignore the flawed MDI here), and the user decides which file they work on. The File menu pertains to that one file, being the current document.

Not every application is document centric, examples of non-document centric apps are:

• process-managers (no files, whatsoever)
• e-mail clients (storage is a database, which usually is never changed by the user)
• file system explorers (yes, it works on files and folders, but not with its contents, so it never "open"s them)
• Minesweeper

Common theme: A "File" menu either doesn't exist at all, or doesn't fulfill the same function as in a document-centric application. The File menu does not pertain to a current document. Some UI Guidelines even state when the File menu could be renamed.

IDEs, such as Eclipse, Qt Creator, Visual Studio or even Dreamweaver fall into a third category. They do not work on a single file, but on a number of files. So many in fact, that there are systems such as GIT to keep track of changes, which files are added, changed and removed. The differences are sometimes subtle, but nevertheless game changing:
I can open a C++ source file from the File menu, but I could also open the project file first, and then go to the linked C++ file from there, skipping any commend in the File menu. The file I'm editing will be the same, but in a totally different context. This context must be visualized and there must be commands to manipulate it.
Some IDEs create a new menu called "Project" to handle some of the additional management, some keep all in the File menu.
Either way, such systems need more advanced commands, a different menu structure, and have a steeper learning curve. The File menu mostly pertains to the current project, not to the actual file being edited, but it is usually a mix of both, which is a complex concept.

Even though an EPUB is a ZIP file with a number of files, those are all contained *within* the ZIP, similar to an ODF or DOCX. So it will be always one document that Sigil is working on. This allows us to stick with the simpler, document centric approach.