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)
• Comment : The real question is : how usefull is that insert menu ? The user already has shortcut or toolbar for nearly all of its menuitems. But anyway, i guess the best place for an "insert page" would not be a menu, but the page window itself. So i'd recommand to delete all the menuitem related to a tool, i.e. just keep caracters and space, and rename Insert as Text in which one could also find "Style" moved from Edit menu and other relative option such as text along a path and so on
  • I agree. However, if the Tools toolbar is split (as described below) into a Text Tools and a Graphics Tools toolbar, it is unclear where Insert Page would go. Or perhaps by itself at the top or bottom of the vertical scrollbar, or in the status bar with the page navigation buttons? Incidentally, the Style menu is slated for removal. Faramond 19:10, 25 June 2007 (CEST)

Menu naming

The paradigm pioneered by the original Macintosh interface was that the user would select an object, then perform an action upon it. In terms of a menu structure, the menu should consist of objects (nouns) such as Page, Guides, Table, Graphics, etc. and the menu items should consist of "methods", that is, actions (verbs) on the objects.

Sometimes this paradigm will fall down because an object is so complex and has so many actions that can be performed with or on it that the menu (even compressed by the use of cascades) becomes unreasonably wrong. The following notes suggest ways in which the menubar and menus may be improved following this paradigm of object and action.

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. In most other applications, the Windows menu (a) allows you to configure the main window in various ways (cascade, stack, tile, refresh, etc), (b) lists currently open documents, and (c) in some cases lists the currently open non-modal palettes or dialogues.

• 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.)

Tools menu

A Tools menu should contain a number of the 'action' items on the current (v. 1.3.4) Windows menu, such as Properties, Outline, etc.

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:

File import/export

In 1.3.5svn the File > Import menu currently counts no less than 5 submenus for 7 file types, plus Get Text, Append Text and Get Image. File > Export has 5 submenus. This is inconsistent and should be simplified.

Import

The current file import should be replaced with a Place menu entry à la InDesign and no submenus. Clicking Place (or the equivalent) would open a regular file dialog. The options would depend on the file type:

• Text: after selecting a text file, the dialog should close and the cursor switch the text frame cursor, including all 3 options available for text frame cursors.

• Images: after selecting an image, the user should be given the options (shortcuts?) scale frame to image, scale image to frame, free scaling

• vector files: after selecting a vector file, the user should be able to set the size of the group.

It should also be possible to select multiple files and add them to a "placing queue". The user would then be presented a separate dialog from which he can chose the items he wants to place.

If a frame is selected, it may be reasonable to place the content of the selected file directly into the frame, if possible.

Export

There should be only one menu entry "Export". Clicking it would result in a regular file dialog. The chosen file type will determine the dialog that would appear after selecting a file, eg PDF export.

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 text and drawing controls still should be separated. Also, you could attach a control to the frame to edit its contents in the story or a graphics editor. Faramond 22:10, 22 June 2007 (CEST)
• Comment: what about pathtext?
  • I'd say "Text Tools" because it is text on a path (not a shape on text.) Faramond 21:59, 22 June 2007 (CEST)

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.)

• Comment: rotating and editing shapes are possible on all frame types, not just image related ones --Cbradney

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

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)
    • I agree but would add one proviso: functions that appear in toolbars or the status bar and have tooltips and keyboard shortcuts do not need to also be present in menus. (Cf. see discussion on the Insert menu, above.) Faramond 19:13, 25 June 2007 (CEST)

Recommendation 2: do something entirely different!

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 elsewhere in this section, all the repetitious "Show"s would become redundant. (View|Show Margins has the same meaning as View|Margins.)

Recommendation: remove the word "Show" from the entries on the menu.

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.)

Info command

The context menu that appears when users right-click on various objects, such as text and image frames, has an "Info" command. This gives text (paragraphs, lines, words, chars) or image (file, original PPI, actual PPI, colorspace) statistics. It is rather clumsy to include such information on a menu. Menus are not read-outs!

Recommendation: move this information to the lower status bar (the one with X- and Y-Pos.) This will cut down on clicks and also shorten the context menu, which is, at times, too long. Besides, there is plenty of empty space in 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.

Preferences

In the Preferences/Document Settings, the zoom factor currently resides under "Tools", probably due to the neighbourhood in the icon bar. IMHO, it should be moved to the "Display" tab. --C schaefer 03:12, 15 July 2007 (CEST)

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. 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)
• Comment : agree for toolbar, if we have a toolbar for main windows (i.e. properties, page...) Gemy_c

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)
• Comment: also may be a dockable on one side (as Stylist in OO.org or in other K* apps such as fila navigator in kate) Gemy_c

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)
  • Excellent idea. You might also want to include a tab/section in the resource manager that tracks all the external files/links that a document refers to. Faramond 01:47, 21 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

Script

Is "Script" the best word for this menu? "Script" is not only a programming term. It's also a linguistic and typesetting term with an entirely different meaning. See http://dictionary.reference.com/browse/script

Note that the programming use of "script" is not even in the Random-House dictionary and is the last definition in the American Heritage. Such definitional overlap is apt to cause confusion in non-technical users--all those who do NOT use scripts, which is probably the majority of Scribus users.

Recommendation: replace "Script" with a nonambiguous term. If a suitable replacement cannot be found, "Scripting" might be less confusing than "Script."

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.")

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

Edit|Paste

When no text frame is For text to be pasted, the user must already be editing a text frame. He must already have double-clicked on a text-frame or clicked the Edit Contents of Text Frame button and then on a frame. Pasting when no text frame is selected does not work, nor does pasting when the text frame is selected but not being edit (i.e., only clicked once.) This behavior means that text frames must be created and set to edit every time a user wants to paste. This behavior is bound to trip even advanced users up.

Recommendation 1a: when a user attempts to paste text into a document with no text frame selected, Scribus should create a new text frame and paste into it

Recommendation 1b: when a user attempts to paste text into a frame that has only been selected but not set to edit, Scribus should paste the text into the end of the frame (it should append it to any text already in the frame)

Edit|Image

If gimp is not installed or in the path, Scribus gives the warning, "The program gimp is missing!" This is not very informative or user-friendly, especially for users who do not know what gimp is.

Recommendation 1: this dialog should prompt the user to select an image editor in File|Preferences|External Tools. It could suggest gimp and provide a link to the gimp website (www.gimp.org), possibly to the correct operating system page there, too.

Recommendation 2: Scribus should invoke the default image editor (according to the operating system's file associations.)

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

Edit|Text/Image

As text and image frames are distinct entities, there is no need to have both Edit Text and Edit Image. At least one of these two entries is always grayed out.

Recommendation: combine Edit Text and Edit Image into one command. This could either automatically change its name to reflect the item selected, or it could be called something like "Edit Contents" or "Open in External Editor." This combined command could share one keyboard shortcut (which should be changed to something more accessible or memorable that CTRL+Y. A function key would probably be best.)

• In 1.3.5 there's a third "Edit" entry: Edit LaTeX-Frame, and who knows what other editable items will be added in the future. I agree with the parent: Edit Item should replace the different entries. --C schaefer 00:22, 19 August 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 Attributes to "Define Item," "Relationships," or "Define/Relate Item"

Script|About Script

This command is poorly named. Many users who might otherwise use it may not click it because it sounds too much like a Help menu command, viz. "About Scribus," "About Plug-ins," "About Qt." In addition, the dialog box it brings up is not even titled "About Script" but rather "Examine Script."

Recommendation: rename "About Script..." to "Examine Script..."

Mouse functionality

Stacked Text and Image frame behaviour

Text frames and image frames currently are selected by clicking on them. The highest stacked frame in the layer is selected once clicked. Resize boxes become visible once selected.

Scribus behaves thus:

1. Select object A, get resize handles. Grabbing edge of selected object A to resize, where the edge touches unselected object B, will select and move object B where object B is stacked higher in the layer
2. Select object A, get resize handles. Grabbing edge of selected object A to resize, where it is overlapped by unselected object B, will select and move object B where object B is stacked higher in the layer

InDesign / Quark behave thus:

1. Select object A, get resize handles. Grabbing edge of selected object A where where the edge touches unselected object B, will NOT select object B where object B is stacked higher in the layer, but instead resize Object A
2. Select object A, get resize handles. Grabbing edge of selected object A where where it is overlapped by unselected object B, will NOT select object B where object B is stacked higher in the layer, but instead resize Object A

Recommendation: change resize / move frame behaviour to assume the currently selected frame is to be resized or moved when grabbed

Note: I found that pressing the <control> key when attempting to re-size selected object A, prevented the selection of object B in both cases stated previously. This may alleviate some of the frustrations with this functionality until it is addressed.

Full time access to "Edit Content" tool

Please see bug #168 for the details.

Recommendation: once a tool is selected, let's assume the user wants to use this tool until he picks another one.

PDF Export

In the PDF export dialog, we have in the tab "General" under File|Export|Save as PDF: Generate Thumbnails, Save Linked Text Frames as PDF Articles and Include Bookmarks. This seems to be a heritage of 1.2.x. These options are solely viewer related, and they should be moved to the "Viewer" tab. They are also totally unrelated to the other options in the dialog, like binding, resolution or PDF version.

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)

Recommandation 2 : make the mousewheel scroll the value of a list without opening it (i guess this is supposed in the message above but not explicit)

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)

Function

Grouping functions/buttons on tab allows the user to find the needed button faster, when doing a special task. When working with frames, the xyz-Tab is good choice. But when working in the text or with a picture it makes no sense. Its annoying when working in textframes you always need to switch back to the text-tab, when you change to a new frame. So following recommendations:

Recommendation 1: Working with frames, keep xyz-tab selected. Editing text-frames select text-tab.

or

Recommendation 2: Keep always the last selected tab

and

Recommendation 3: Let the user choose between 1 or 2

Tab location

Once upon a time there was a property-window (I think 1.2/1.1 series) where the names of all tabs stayed at the top and only the content changed when clicking on the appropriate tab. In the current version I always have to "seach" the position for the tab to click on it. It depends which tab is active and which is the next to go. In the old version the "search area" was very small, only the width of the window. Now it is the whole height. Thus:

Recommendation: place the tabs at the top of the palette

What do others think?

• Comment: This has been discussed at length on the mailing list and in the bug tracker. --C schaefer 15:00, 28 June 2007 (CEST)
• The real problem here is not the location, but rather how the tabs move around. Other programs (e.g. Opera) use vertical tabs without problems, but they remain fixed. (Clicking a tab sends the previously active tabbed sheet to the background, rather than collapsing it.) Note that vertical tabs do have one advantage if they are pinned to the edge of the screen: they are easier and faster to click. The user can "slam" the mouse to the edge of the screen and click without having to decelerate in the horizontal direction. The buttons are a "mile wide," just like Macintosh menus are a "mile high." This makes them far more accessible. See the section Mile-High Menus and Magic Corners at http://blogs.msdn.com/jensenh/archive/2006/08/22/711808.aspx for details.

Size

The properties palette should be small as possible because screen space is always rare. In the QT4 version it seems even bigger.

Recommendation 1: omit control labels and put explanatory text in tooltips (the Text tab already does this well.) The Shape tab could be massively improved in this respect. Improving the quality of toolips with additional text and images would also help. E.G., the super tooltips Word 2007 has:

Super tooltip for the "Drop Cap" command

(More examples at http://blogs.msdn.com/jensenh/archive/2005/12/02/499371.aspx )

On the other hand, a palette of icons could be very intimidating for users. How many users will take the time to hover over each control, reading each tooltip and committing to memory what each says? There are other ways to increase screen real estate obliterating the text, e.g.:

Recommendation 2: add a mouse command to show/hide all palettes (say middle-click). This is also detailed under the mouse functionality section below.

Recommendation 3: reduce the size of text boxes as to allow denser spacing. (At present, when the Properties palette is sized wide enough to show all controls without clipping/scrolling, numbers in the quadrillions fit into some of the text boxes!)

Recommendation 4: make the Properties palette a retractable panel. This would work as in the web browser Opera:

1. When the user moves the mouse to the edge of the screen and clicks, the panel appears.
2. When the user clicks again, the panel disappears.

The panel consists of two parts: one column of tabs, and one of properties for that tab. The user can also opt to close only the properties column but leave the tab column open. Illustrations:

• Panel extension
• 

  Note the gray bar with an arrow at the left

• 

  Clicking it opens a list of tab icons. These are equivalent to the tabs on the Properties palette.

• 

  Clicking an icon opens the respective tab (here, "Search.") These are equivalent to the controls the Properties palette's tabs.

To optimize this design for Fitts' Law, the gray bar should only appear when the palette is closed (collapsed.) When it is open, it would get in the way of quick access to the tabs. (A close button, e.g. [X] should instead be provided on the palette.) Note that this is a modification of the way Opera works. (It retains the gray bar even when the palette is opening, forcing the user to stop the mouse pointer before it reaches the screen edge.)

Opera provides keyboard shortcuts for these tabs, too. F4 toggles display of the panel, and SHIFT+CTRL+1 through SHIFT+CTRL+0 show/hide the tabs from top to bottom. Scribus could use, e.g., ALT+1 through ALT+0. (Note that pressing these keys should transfer keyboard focus to the tab so that TAB/CTRL+TAB and ALT+accelerators work correctly.)

Advantages of this design:

1. easy show, easy hide
2. fast tab access via mouse (Fitts' Law)
3. keyboard-friendly
4. predictable, anchored palettes (they do not drift around the screen but remain in the same location)
5. plenty of space for controls (because the palette would be as tall as the document area)
6. space efficient (no wasted gaps between floating palettes and edge of screen)
7. potential extensibility (plug-ins may be able to supply additional tabs or property pages)
8. adjusts automatically to vertical resizing of parent window (vertical scrollbar would appear if too many tabs)

Disadvantages:

1. bound to one screen (what if you want controls on a second screen?)
2. Fitts' Law benefits only when tabs abut left screen edge (scrollbars block access to right edge)

Mouse functionality

Right click+drag

Right click+drag brings up a context menu with three choices:

1. Copy Here
2. Move Here
3. Cancel

This is unnecessary. "Move Here" is already covered by left click+drag. And left click+drag (Move Here) does not invoke a context menu with the option "Cancel," so why should Copy Here?

Recommendation: remove this context menu. Make the default behavior of right click+drag Copy

• Comment: It may not be necessary, but it's not irritating. Personally, I find the dialog quite useful as it is now. --C schaefer 20:46, 22 June 2007 (CEST)
  • I suggest this coming from Xara Xtreme--it does copying by right click+drag, and, in my experience, it really speeds up editing. As the pop up menu is currently set up in Scribus, to copy with the right mouse button, you need to: right-click + drag + move the mouse slightly but not too far southeast + click. It seems like needless complexity--we might as well pop up a real dialog box saying "You right-clicked instead of left. Does that mean you want to [C]opy [M]ove or C[a]ncel?" If users do goof up while dragging, they can always press ESC before releasing the mouse button (or undo afterwards.) Faramond 21:57, 22 June 2007 (CEST)

CTRL+right click+drag

This changes the pointer to a hand to "grab" the document and move it around. This is unnecessarily complex and inconsistent with other applications (most use middle button click+drag to achieve the same effect.) As it happens, middle button+drag is free in Scribus (it apparently does nothing.)

Recommendation 1a: move the hand/grab feature to middle button+drag. This would be easier to use (only requires the use of one hand) and would also free up CTRL+right click+drag for other uses (see Recommendation 1b, below.)

Recommendation 1b: reassign CTRL+right click+drag to function analogously to CTRL+left click+drag (i.e., Copy object along the horizontal or vertical axis.)

Right click+drag+CTRL

Right-clicking, dragging, and then holding down CTRL has the same exact effect as right click+drag: it brings up the context menu discussed above. However, it adds a meaningless [+] as if it were going to copy and bypass this menu. Not only do the criticisms voiced above apply here, but this is doubly confusing:

• behavior should be the same whether the user presses CTRL before or after clicking and dragging
• the [+] suggests that the operation will copy (e.g. like CTRL+left click+drag in Windows Explorer) but instead brings up a context menu (like right click+drag)

Recommendation: make the right click+drag+CTRL behavior identical to CTRL+right click+drag, i.e. to Copy object along the horizontal or vertical axis

• Doesn't what you describe just mean that Ctrl+right click doesn't have any effect whatsoever? If yes, what's the problem? --C schaefer 21:18, 22 June 2007 (CEST)
  • The problem is that: a) holding down CTRL seems to have an effect (it makes a [+] for "copy" appear) when right-clicking and dragging on an object, b) but that [+] has absolutely no meaning, and c) if I hold down CTRL first, under the impression that CTRL does have an effect, I end up with a different tool (hand instead of move/copy) than if I hold it down later. It'd be simpler if hand/pan moved to middle-click+drag (like other software), and CTRL operated on the right mouse button the same way it does on the left. Faramond 21:43, 22 June 2007 (CEST)

Unused/future mouse button assignments

The following keyboard-mouse combinations are unused/nonfunctional in Scribus:

• middle click, SHIFT+right/middle click
• CTRL+left/right/middle click
• ALT+left/right/middle click
• right/middle double-click
• ALT+wheel

These could be huge timesavers. Many could/should be assigned. Most, if not all, certainly are in other graphics/DTP packages.

Recommendation: assign unused keyboard+mouse combinations, e.g. as follows:

• ALT+click - select under (to select an object that is under another object; repeatedly ALT+clicking selects, one-by-one, all objects underneath; user stops when desired object is selected--cf. as it works in Xara)
• SHIFT+right click - delete from selection (SHIFT+left-click adds to selection; enabling this would allow users to make complex selections, selecting and deselecting, without moving their finger from the SHIFT key)
• ALT+left/right click+drag - same as left/right click+drag but overrides Snap to Grid/Snap to Guides (i.e., moves/copies object without respect to grid/guides when they are on or with respect to them when they are off. This would be analogous to how CTRL constrains dragging to the horizontal or vertical axis: i.e., CTRL constrains, ALT frees.)
• right double-click - by analogy with left double-click (brings up the Nodes palette, edits text, etc.), this should bring up a commonly-used palette/dialog, e.g. the Properties palette
• CTRL+left/right click - raise/lower object
• SHIFT+CTRL+left/right click - raise to top/lower to bottom
• middle click - show/hide all palettes
• middle double-click - 100% zoom
• ALT+wheel - go to next/previous page, a PAGE UP/PAGE DOWN for the mouse (CTRL+wheel scrolls up/down, but in a multi-page document at high zoom, this is a tedious way to go from page to page)

Still unassigned:

• SHIFT+middle click
• CTRL+middle click
• ALT+right/middle click

(Note that these assignments do not and should not conflict with the click+drag recommendations made above. This is the way things already work, e.g. with the left mouse button: click selects, but click+drag moves.)

Keyboard functionality

File|Quit/Exit

There is no consistent way to close the current parent window in Scribus:

• In the main application, File|Quit
• In the help system, File|Exit
• In the script console, File|Exit

Both menu entries (Quit/Exit) and accelerators (Q, X, E) are inconsistent.

Recommendation: standardize all menu entries to Exit (X being the accelerator)

---

Changed in 1.3.5 on 31/07/2007 to Quit after checking Inkscape, Gimp, Krita, etc --Cbradney 00:32, 31 July 2007 (CEST)

Missing accelerators

Some menu entries are missing accelerators:

• Edit: Paste Recent, Contents, Edit Text, Edit Image/Patterns
• Item: Level, Send to Patterns, Adjust Frame to Image, Extended Image Properties, Preview Settings
• Insert: Sample Text
• Page: Convert to Master Page, Manage Page Properties
• View: Preview Mode, Show Text Frame Columns, Show Control Characters, Show Rulers, Rulers Relative to Page
• Extras: Dehyphenate Text

Recommendation: add accelerators for all of these commands (ideally so they do not conflict with other commands on the same menu

Dialog boxes

There is no consistent way to OK/cancel/close a dialog box in Scribus:

• ESC exits some, but not all boxes (namely Edit|Patterns and Insert|Glyph)
• ENTER okays some, but not all dialog boxes, depending on the controls in the box
• ALT+C activates Cancel/Close in some, but not all boxes (e.g. Insert|Frame, File|Open/Save/Collect for Output/Import/Export, Script|Execute Script/About Script)
• ALT+O activates OK in some, but not all boxes (ditto, plus all the boxes that use "Save" or other verbiage instead of Cancel/Close)

Recommendation: settle on and use consistent keyboard accelerators for the dialog boxes

Tables

I've moved this section to its own page, referenced in the Scribus development category