Discussion: Scribus UI/usability improvements

Scribus has received its fair amount of praise for good usability. But there has also been valid criticism.

This is the page where you can make suggestions regarding improvements to usability and user interface design. Please do not add requests for new features unless they are related to the improvement of Scribus' usability. If you like, you can create mockups with UI builders like Qt Designer and upload a screenshot. If possible, don't just complain, but suggest alternatives. In case you think an existing application offers a good solution, you can add screenshots with a description.

Consistency with other applications

Unless there are solid reasons for going its own way, Scribus should act like other, well-known applications. It should follow their conventions. The more similar it is to them, the faster new users can get up to speed with it (i.e., a lower learning curve.)

Individual commands

Insert Page

Considering myself an experienced Scribus user, I still catch myself clicking the "Insert" menu to insert a page instead of the "Page" menu. I'd be interested to hear what others think about it. Maybe the "Insert Page" action should be moved to the "Insert" menu.

• Comment: I am of two minds about this. It is logical where it is, but it is contrary to most UI conventions and how we think/speak (at least in a subject-verb-object language like English.) It is generally a bad idea to duplicate commands across a UI, but in this case perhaps an exception is warranted? I.E., both Insert|Page and Page|Insert in the UI? Word 2007 makes a similar exception: the full range of breaks (page, column, text wrapping, next page, continuous, even page, odd page) is on the Page Layout tab; however, Page Break also appears on the Insert tab. Faramond 01:29, 21 June 2007 (CEST)

Menu naming

Windows menu

Even though the Windows menu has distant relatives under QuarkXPress, many users are unable to find essential features there, because Windows isn't specific enough. Personally, I don't have a problem with the menus, but many others do. At least the title of the menu should be changed ("Advanced Tools"?), but I think a major change might be the better solution. Please add your suggestions here.

• Comment: I definitely have a problem with the menu structure. I find myself hunting around even after having used Scribus a lot--indeed, it is the major reason why I resort to other software to get the job done. Faramond

In addition, the toolbars on the windows menu are problematic. First, comparable software often includes toolbars on the View menu. Second, only two of the current four toolbars are listed there.

Recommendation 1: add the File and Edit toolbars to the Windows menu

Recommendation 2: move all four toolbars to a "Toolbars" submenu on the View menu

(Note that the two recommendations above are mutually exclusive.)

View menu

The View menu has a split personality: the top half zooms, while the bottom half toggles display of various things. If the zoom commands are removed, as described in the Cleanliness/simplicity section below, the View menu could be renamed to be more self-explanatory.

Recommendation: rename the View menu to Show or Show/Hide. As a bonus, this would allow removal of the repetitious word "Show" from the entries on the menu.

• Comment: I disagree. "View" explains perfectly well what the menu is for. The only issue (if it's an issue at all) is that the upper half duplicates a part of the functionality of the status bar. Maybe the rest (fit to height, fit to width) can be added to the status bar and the double entries be removed from the menu.--C schaefer 20:26, 20 June 2007 (CEST)
  • I'd be okay with keeping "View." But it does seem a little superfluous to say "View|Show Margins." Why not remove all the "Show"s? "View|Margins" seems pretty clear to me. Faramond 00:50, 21 June 2007 (CEST)

Extras menu

Is this a standard menu name on other operating systems? Or is it a poor translation? On Windows, in English, the usual name for this sort of menu is "Tools." (In German, however, it is "Extras.") If this is an artifact of translation, it should be adjusted.

Recommendation: if justified, rename the Extras menu to Tools

• Comment: I disagree. "Tools" is already used for text frames, image frames etc. (cf. Preferences). And the "Extras" are what the menu says: extras.--C schaefer 20:29, 20 June 2007 (CEST)
  • Comment: Oops! You are right on "Tools" already being used, and it is a bad thing to use the same word for two different things. So "Extras" will stay--and this section will be struck out. Faramond 01:09, 21 June 2007 (CEST)

Keyboard

Scribus' keyboard shortcuts are by and large adhere to IBM's Common User Access (CUA) guidelines. This makes Scribus consistent with other applications. Yet some of the most frequently-used CUA shortcuts--mostly those pertaining to the clipboard--are not implemented in Scribus. The shortcuts concerned are:

• SHIFT+DEL = cut
• CTRL+INS = copy
• SHIFT+INS = paste
• ALT+BACKSPACE = undo
• SHIFT+ALT+BACKSPACE = redo
• F10 = activate the menu bar

Pressing these keys has no effect (or an incorrect one, in the case of SHIFT+DEL) in Scribus. These keys are supported by all [Windows] applications, and it would be nice if Scribus supported them in addition to the Macintosh-based CTRL+X, CTRL+C, CTRL+V, CTRL+Z, etc.

Recommendation: provide CUA aliases for the clipboard, undo, and menu bar shortcuts

(There is precedent for having duplicate keyboard shortcuts in Scribus: CTRL+W and CTRL+F4 both close a document window; CTRL+TAB and CTRL+F6 both cycle through document windows. Also, note that changing F10 to activate the menu bar would necessitate reassigning the current F10 function, show/hide all palettes to another key. F12 might be a good choice, as it is located at the end of the F-key row and is thus faster and easier to press. See http://en.wikipedia.org/wiki/Common_User_Access for details on the CUA.)

• Comment: Keyboard shortcuts should be carefully revisited before the release of 1.4. --C schaefer 20:34, 20 June 2007 (CEST)

Cleanness/simplicity

A complex UI detracts from the user experience. It hinders both novice and professionals by making commands a) hard to find and b) hard to use. The UI should be as clean/simple as is possible without sacrificing any functionality. The Scribus UI is chock full of commands. Unfortunately, these commands are scattered rather haphazardly throughout the UI. In addition, many of them are redundant. For instance:

Toolbars

Tools toolbar

The Tools toolbar is lengthy, at 18 items. This makes locating commands more time-intensive for users. They have to scan it longer to find the button they are seeking. This problem is compounded by suboptimal ordering of the buttons. In particular:

1. the Zoom In or Out button is probably a high-use tool, so it should be located at the end of the toolbar, in order to make it more "clickable." In addition, the buttun is sandwiched between insert and edit buttons. Zoom neither inserts or edits. Indeed, its closest analog in the toolbar is the compass/magic wand/eyedropper at the end of the toolbar.
2. the toolbar intersperses text and graphics commands. Why is Insert Text Frame situated at the opposite end of the toolbar from Edit Contents of Frame, Edit the text with the Story Editor, Link Text Frames, and Unlink Text Frames? What if users only want to work on text or graphics at one time? Why should they have to move the mouse back and forth over the buttons to insert graphics?

Recommendation 1a: move the zoom button to the end of the toolbar

Recommendation 1b: divide the toolbar into three parts with toolbar separators (blank spaces) between button groups. Separators will break up the sequence of buttons and show the groupings among them. These should fall between Insert Freehand Line and Rotate Item; Unlink Text Frames and Measurements (the compass)

• Comment: The status bar already has zoom tools. Maybe the zoom icon could be placed there too. C_schaefer
  • Comment: That's a great idea (I've already proposed it on the bug tracker) Faramond

Recommendation 2: split the toolbar into TWO toolbars: "Text Tools" and "Graphics Tools." Text tools would include:

1. Insert Text Frame
2. Insert Table
3. Edit Contents of Frame
4. Edit the text with the Story Editor
5. Link Text Frames
6. Unlink Text Frames

• Comment: I'd like to get rid of the link/unlink modes in favour of direct controls attached to the frame, as in PageMaker - av
  • Comment: I agree. But if text and drawing controls still should be separated. Faramond 01:25, 21 June 2007 (CEST)
• Comment: what about pathtext?

Graphics (or Drawing) tools would include:

1. Insert Image Frame
2. Insert Shape
3. Insert Polygon
4. Insert Line
5. Insert Bezier Curve
6. Insert Freehand Line
7. Rotate Item

• Comment: this [insert line] should go since it's just a special case of a polygon - av
  • Agreed. Also, Insert Polygon could be merged into the Insert Shape control (or vice-versa.) Faramond 01:25, 21 June 2007 (CEST)

The remaining commands could be moved to the "Edit" toolbar, such as follows:

1. Select Item
2. Undo
3. Redo
4. Cut
5. Copy
6. Paste
7. Eye Dropper
8. Copy Item Properties
9. Measurements

• Comment: this is a mixture of modes (select, measurements, eyedropper, wand) and actions. I'm not sure about that. av
  • Admittedly Select Item, Undo, and Redo do not belong with the clipboard commands, but then again, Undo, Redo, and Select All are on the Edit menu, which also hosts all the clipboard commands. Copy Item Properties also seems to belong in this group. It copies! Likewise, it could be said that the Eye Dropper copies a color from the document to the document's palette. As for Measurements--it might be better off on the status bar, by the zoom tools. In any event, where it is currently located (next to unlink text frames), is suboptimal. Faramond 01:25, 21 June 2007 (CEST)
• Comment: we also have another mode "edit shape" which is currently hidden in the properties palette - av
  • Edit shape would seem to fit into "Drawing Tools" toolbar. Faramond 01:25, 21 June 2007 (CEST)

Logically speaking "Copy Item Properties" should be near "Copy."

• Comment: We must not forget PDF form tools. C_schaefer

(Note that Recommendation 1a/1b and 2 above are mutually exclusive.)

Closing documents

There are five separate ways to close a document window with the mouse:

• click the X in the upper-right
• double-click the control menu
• click the control menu and choose "Close"
• click the X button on the toolbar
• click File|Close

This clutters the screen and probably detracts from usability. In addition, it is not standard practice to include a close X on the application toolbar--because it is not part of the child window, it is not clear whether it pertains to the parent (the Scribus application) or child window (the open Scribus document.)

Recommendation: remove the X button from the toolbar

• Comment: Scribus has to work under different OSes and different window managers. Eg. under KDE there's another possibility to close ist. Also, user expectations are certainly different. Some users are used to closing from the icon bar, others use File > Close, others prefer a shortcut etc. I also don't think this is really confusing. C_Schaefer

• comment: control menu and window close button is mandated by the window manager. File|Close is necessary because that's where everyone knows they can find this function. I wouldnt mind if the toolbutton would go - av

Menus

Style menu

The Style menu duplicates what the Properties palette--but only for text and only in part. This is problematic because:

• Users may not be aware that a much richer selection of attributes is available on the Properties palette.
• The menu only applies to text and nothing else. Why do we have a menu for some of the attributes on the Text tab of the Properties palette, when the X, Y, Z; Shape; Group; Image, Line, and Colors tabs do not appear at all in the menus? This is inconsistent. In any event, most of the time this menu is disabled (grayed out) and unnecessarily complicates the menu bar.
• Furthermore, it is not clear from its naming what the menu refers to. Nowhere does it specify that it only applies to Text (i.e., not shape or image styles.) It is also misleading insofar as it does not apply a named style but rather direct formatting (which is generally not considered a style.)

The sole benefit that the menu offers appears to be keyboard access. If keyboard access can be added to the Text tab Properties palette, the need for the Style menu will evaporate.

Recommendation 1: delete the Styles menu and add keyboard shortcuts to commonly-used items on the Text tab of the Properties palette. These shortcuts might include: font, size, color; bold, italic, underline, strikethrough, small caps; superscript, subscript; and left, center, right, and block/justified align. These shortcuts should be documented in the tooltips that appear when a user hovers over the respective buttons on the Properties|Text tab. Modelling these on the shortcuts of commonly-used word processors (where possible) would be helpful. (It would lower the learning curve/capitalize on existing knowledge; besides, CTRL+U is much faster than ALT+Y,E,U.) Finally, Tabulators should be added to the Text tab of the Properties dialog (at present, it appears only on the Style menu.)

Recommendation 2: do as in Recommendation 1, but leave "Style" on the menu bar. Clicking this would not open a menu but instead bring up the Properties palette. (In this scenario, the Properties palette could be renamed "Style".) This is nonstandard menu behavior but would preserve the Style menu for those who are accustomed to it.

(Note that the two recommendations above are mutually exclusive.)

• Comment: The Style menu has been removed in 1.3.4/1.3.5 C_schaefer

Item menu

The menu is very long. It has 23 entries! Moreover, generally about half of these, depending on the item selected, are grayed out. The longer the menu is, the more reading (scanning) the user has to do. And excess scanning is especially wasteful when the commands are not even applicable.

Recommendation 1a: move Duplicate, Multiple Duplicate, and Delete to the Edit menu. (The former two function like Copy and Paste; the latter, like Cut; and most software includes a Clear/Delete entry on the Edit menu, so these commands would be at home there.)

• Comment: Sounds reasonable. --C schaefer 20:47, 20 June 2007 (CEST)

Recommendation 1b: rename the Send to Layer submenu "Send to" and merge Send to Scrapbook and Send to Patterns into it. (The "Send to" prefixes could be deleted.)

• Comment: Reasonable only at first sight. Moving items to another layer means two submenus. Working with submenus takes more time. --C schaefer 20:47, 20 June 2007 (CEST)
  • Comment: I did consider that submenus take more time and are less "discoverable." However, the menu is overwhelming. There has to be some way to organize it better. Any other suggestions? Faramond 00:52, 21 June 2007 (CEST)

Recommendation 1c: create an Image submenu and fill it with Adjust Frame to Image, Extended Image Properties, Update Image, and Preview Settings. (The word "Image" could be excised from the middle two entries, yielding "Extended Properties" and "Update.")

• Comment: Why not remove the image related entries altogether and move them to the context menu for images?--C schaefer 20:47, 20 June 2007 (CEST)
  • Because users use the main menu as a manual. That means all functions should be available through the menubar, even if from some subsubmenu (within limits of course, cf. xemacs for what happens if you put too many functions into menus) --avox 23:19, 20 June 2007 (CEST)

Recommendation 2: do something entirely different!

Individual commands

Zoom commands

There are many ways to zoom in Scribus:

• CTRL+mouse wheel
• CTRL+numpad +/-/0
• the Zoom button on the Tools toolbar
• the Zoom buttons on the status bar
• the View menu

Are all of these methods necessary? Does anybody actually use the zoom commands on the View menu? These commands take up valuable menu space but may not add much in the way of value to the end user.

Recommendation: remove the 50/75/100/200% zoom commands from the View menu. Replace Fit to Height and Fit to Width with buttons on the status bar; add keyboard shortcuts for Fit to Width and the deleted zoom commands if need be (e.g., 50% zoom = CTRL+numpad 5.) As a bonus, making this change would simplify the View menu so that it ONLY refers to objects within the document (and could thus be renamed; see section on menu naming above.) Also, the Preview Mode entry could be removed (a button for it has been added to the status bar.)

Intuitiveness of the UI

The user interface should be intuitive--users should be able to guess or use their gut feeling to figure out how the program works. On a related note, commands should also be "discoverable" (not tucked away in corners with strange monikers.) This is especially important in open-source projects, which often lack comprehensive help systems. There should be a logic behind how commands are named, placed, and used.

Floating palettes

Properties

The real power of Scribus lies in its palettes, above all the Properties palette. Unfortunately, this is far from evident in the UI: the Properties palette is buried in the Windows menu. Many users may erroneously assume that this menu ONLY includes a list of currently open documents. The labeling of the palette is confusing, too: Windows|Properties does not give one the Properties for the current window, but rather for the selected item/object. Finally, Properties may not be the best choice of a name (what kind of Properties are we talking about? Real estate? File properties? Document properties? Not all users think like object-oriented programmers. And how exactly is Properties different than Attributes? They are synonyms.Confusingly, both appear on the right-click context menu!)

• Comment: A DTP program offers complex features, and there are some things a user will have to learn. The "Attribute" features will become more powerful in the future, and there will be appropriate documentation. I don't think a change of terms is required. Also, the Properties Palette has a shortcut (F2) by default. I agree that "Windows > Properties" isn't the best place for such an important tool. The "Item" menu seems to a better place. --C schaefer 21:01, 20 June 2007 (CEST)
  • True. Let's leave "Properties" untouched. But I still would advise changing "Attributes." Surely there has to be a better, more descriptive term for what the dialog does? Faramond 01:41, 21 June 2007 (CEST)

Recommendation 1a: add a button to toggle the properties palette to the status bar.

• Comment: Sounds reasonable. The menu bar would also be a good place. --C schaefer 21:01, 20 June 2007 (CEST)

Recommendation 1b: have the Properties palette visible on the first load after installation so that new users see it.

• Comment: This should be configurable. --C schaefer 21:01, 20 June 2007 (CEST)

Recommendation 1c: if justified, rename the Properties palette to "Format," "Format Item," or something similar.

• Comment: The Properties Palette is a well-established feature and well-known to Scribus' users. It's almost like a brand, so I don't think it's a good idea to change the name. Moreover "Properties" is a very good description of its purpose, because almost all properties of the item can be changed here. It's ok to accommodate users, but it's not ok to treat them like idiots. I doubt that any user would think of real estate in DTP software ;) --C schaefer 21:01, 20 June 2007 (CEST)
  • Comment: Good point. I'm nixing Recommendation 1c. Faramond 01:41, 21 June 2007 (CEST)

All palettes

The palettes arrayed on the Windows menu are a grab bag of things: from positioning (Align and Distribute) to error-checking (Pre-flight Verifier.) The palettes are apparently grouped together because of how they are implemented, not by what they do (i.e., form instead of function.) This is intuitive for programmers but not end users.

Recommendation: redistribute certain palettes to the relevant menus:

• Properties --> Item menu

• Comment: Agreed. See above.--C schaefer 21:07, 20 June 2007 (CEST)

• Arrange Pages --> Page menu

• Comment: Agreed. --C schaefer 21:07, 20 June 2007 (CEST)

• Action History --> Edit menu (where undo/redo are located)

• Comment: Agreed. --C schaefer 21:07, 20 June 2007 (CEST)

• Align and Distribute --> Item

• Comment: Perhaps, but above you complained that the Item menu is already quite bloated. This palette can remain where it is. --C schaefer 21:07, 20 June 2007 (CEST)

• Measurements --> (delete, as there is already a toolbar button for it, and there is no need for keyboard access--the measurements command presupposes use of the mouse.)

• Comment: Agreed as to the shortcut. The rest can remain as it is now. --C schaefer 21:07, 20 June 2007 (CEST)

• Preflight Verifier --> File menu (where Collect for Output and Save as PDF are located)

Comment: Agreed. --C schaefer 21:07, 20 June 2007 (CEST)

The remaining palettes (Outline, Scrapbook, Layers, Bookmarks) do not really belong on any other menus and might be best left on the Windows menu.

Comment: we have even more palettes: patterns, colours, stylemanager, masterpages, javascript. Ok, some of those are dialogs for historical reasons. The idea is to combine colours/patterns/javascript/... into a resource manager palette. Masterpages should be replaced with a more generic page selection scheme in the navigation bar: just list the masterpages in the pageselector popup. Maybe also provide a button for quick switch from MP mode and back. --avox 23:32, 20 June 2007 (CEST)

Toolbars

Right-clicking on a toolbar brings up a context menu listing all toolbars. This is good. However, right-clicking on an empty space in the toolbar row (generally to the right of all toolbars when they are docked horizontally) does not, nor does right-clicking on the menu bar. This is suboptimal for two reasons:

• Users may right-click on empty space on the toolbar row to show a toolbar. They may click there because: a) they want the hidden toolbar to appear there or b) they want a context menu for all toolbars as opposed to that for a single toolbar or button.
• When all toolbars are hidden, there is no clear way to show them again (without digging through the menus.)

Recommendation: add a context menu for right-clicks on the menu bar and toolbar. This context menu should be identical to the one triggered by right-clicking on visible toolbars.

• Comment: Agreed. --C schaefer 21:12, 20 June 2007 (CEST)

Menus

Item menu

"Item" is not a particularly intuitive word. Quark may use this--but perhaps Selection or Object (like Photoshop and InDesign, respectively) would be a better word? Or Arrange (like Xara)?

• Comment: "Item" and "Object" are mutually interchangeable. I don't think this is a real issue. Please also consider that all tooltips would have to be rewritten, and they have been cleared of all "objects" recently. --C schaefer 21:14, 20 June 2007 (CEST)

Individual commands

Edit|Item Action Mode (and Windows|Action History)

These commands are obliquely named. What IS an Action Mode?

Recommendation: rephrase. Perhaps "Separate undo history," "Track undo by item," or "Keep undo history by item" would be better. ("Action History" could become "Undo History.")

• Comment: Agreed as to Item Action Mode. It's opaque and almost untranslateable. For the German transalation I chose the equivalent of "Tool Mode". Action History is a good description, though. --C schaefer 21:17, 20 June 2007 (CEST)

• what about "undo history by item" and "undo history" ?

Item|Multiple Duplicate

This command is missing an ellipsis (...) to indicate that it brings up a dialog box.

Recommendation: add an ellipsis

• Comment: That's nitpicking, IMHO. There are many other menu entries that open other dialogs and without an ellipsis. As said above, don't expect your users to be fools. --C schaefer 21:20, 20 June 2007 (CEST)

• This is a misconception. The ellipsis does *not* mean that a dialog appears, but that the command/action needs an object which has yet to be specified. Since Multiple Duplicate always operates on the current selection, it is correct to have no ellipsis. --avox 23:39, 20 June 2007 (CEST)
  • Comment: actually, poking around Google shows that UI guidelines and windowing systems differ on this. Considering that Scribus runs on platforms that conflict in this regard, this issue is basically moot. So--I'll strike this item out. Faramond 01:00, 21 June 2007 (CEST)

Extras|Manage Pictures

This command is missing an ellipsis (...) to indicate that it brings up a dialog box.

Recommendation: add an ellipsis

• Comment: No. "Manage Pictures" is a complete description and does not need an ellipsis.

Help|Tooltips

This command does not include the word "Show." In addition, there is no reason to include it on the Help menu. Do users really change its state that often?

Recommendation: rename Tooltips to "Show Tooltips" and move it to the File|Preferences|General|User Interface dialog box. The checkbox should be located right below "Show Splashscreen on Startup."

• Comment: No change required. Scribus works like many other apps here. --C schaefer 21:22, 20 June 2007 (CEST)
  • Hmmm, I vaguely recall some applications working that way in the early-mid 90s, but it's a minor quibble, so I'll strike it. Faramond 01:27, 21 June 2007 (CEST)

Context menu|Attributes/Properties

As noted in the discussion of the Properties palette (above), Properties and Attributes are synonyms. Having both in one menu is like "loudness" and "volume" on a car radio. (Many car radios have it, but without reading the manual, most people will be hard-pressed to explain the distinction.) Yet in Scribus, Properties and Attributes do vastly different things: one changes the look of objects; the other, defines their names and relationships to other objects.

Recommendation: rename Properties to "Format" or "Format Item" and Attributes to "Define Item," "Relationships," or "Define/Relate Item"

Ease of use and shortcuts

Properties palette

Mouse wheel

Rolling the mouse wheel increases/decreases values in text boxes in the Properties palette. However, it does nothing when the pointer is not resting over a control such as a list box or text box. The mouse wheel would be a great way to switch tabs in the Properties palette.

Recommendation: enhance the Properties palette so that rolling the mouse wheel flips through its tabs (but only when the mouse is not hovering over a control--i.e., it is over the gray area.)

• Comment: The PP will be redesigned, perhaps in a way that makes this suggestion obsolete. --C schaefer 21:38, 20 June 2007 (CEST)

Keyboard

The tabs and controls in the Properties palette have underline letters. However, they are nonfunctional, e.g.:

• pressing ALT+Z when the palette is displayed but not active does not activate the X, Y, Z tab
• pressing ALT+Z when the palette is active but on another tab does not activate the X, Y, Z tab
• pressing ALT+X when the palette is displayed but not active and the X, Y, Z tab is on top does not activate the X-Pos control

In short, the only thing the user can do with the keyboard is switch to another control on the same tab when and only when the Properties palette is active.

Recommendation 1a: fix the Properties palette so that when it is active, pressing the shortcut for another tab does indeed switch to that tab.

Recommendation 1b: add keyboard shortcuts to move to the next/previous tab when the Properties palette is active. PAGE DOWN/PAGE UP or CTRL+TAB/SHIFT+CTRL+TAB would be good candidates for this. (TAB/SHIFT+TAB and HOME/END are already taken for navigation among and within controls.)

• Comment: You should file a bug for this. --C schaefer 22:26, 20 June 2007 (CEST)