Talk:Discussion: Scribus UI/usability improvements

From Scribus Wiki
Jump to navigation Jump to search

Suggestions graveyard

Resolved

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
    • Great! Faramond 01:43, 21 June 2007 (CEST)

Retracted suggestions

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)

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)

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)
Retrieved from "https://wiki.scribus.net/wiki/index.php?title=Talk:Discussion:_Scribus_UI/usability_improvements&oldid=16014"