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' usabilty. 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 that of other 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.

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.

Cleanliness/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.

Complexity and superfluity

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:

Closing documents

There are four 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

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

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

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

• Insert Text Frame
• Insert Table
• Edit Contents of Frame
• Edit the text with the Story Editor
• Link Text Frames
• Unlink Text Frames

Graphics tools would include:

• Insert Image Frame
• Insert Shape
• Insert Polygon
• Insert Line
• Insert Bezier Curve
• Insert Freehand Line
• Rotate Item

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

• Select Item
• Undo
• Redo
• Cut
• Copy
• Paste
• Eye Dropper
• Copy Item Properties
• Measurements

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

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

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