View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0014533||Scribus||Usability||public||2017-01-02 13:00||2017-12-20 20:58|
|Target Version||Fixed in Version||1.5.4.svn|
|Summary||0014533: Text properties dialog should get a context menu item|
|Description||In addition to ticket 0014519 it would make sense to add a corresponding menu item to the context menu of a text frame. I think many users are accustomed to simply opening the context menu of a frame, selecting "properties" and editing them, so this would add to a consistent workflow.|
|Tags||No tags attached.|
|related to||0014519||closed||cbradney||Text Properties Palette not assigned a Function Key|
|has duplicate||0014674||closed||jghali||Text Properties should be available in the Context Menu for text frames|
|has duplicate||0014818||closed||jghali||No text in properties|
|has duplicate||0014857||closed||jghali||Could the new text properties panel be accessible via the context menu when in a text?|
not sure this is a good idea.
i somehow agree with your reasoning, but i still would prefer no to "clutter" the context menu even more.
on the one side, putting the PP in the context menu would for sure help people discover it.
on the other side, using the/a keyboard (or keeping it always open) is a much better workflow for the daily business.
and having the user to find it in a "common place" (like the suboptimal window menu) will help her discover other important tools (arrange and distribute, layers, ...)
for sure, the discoverability of the PP has to be improved, adding it to the context menu is in my opinion not the best way.
I see your point, but I think there are some counterarguments:
- One pp can be reached via context menu, the other one can't - and both of them, from a very basic point of view, influence the way the text area looks? Seems inconsistent to me.
- Not all users have an affinity to keyboard shortcuts. Many of them like their mouse (in fact, almost all - and I know a lot...). This is especially true for "non-professionals" - and Scribus is a great tool for distributing work also between those since it's easy to handle. Providing many ways of using the software to me is a key feature - it makes people use Scribus who wouldn't if it wasn't easy to use. And for them, easy to use also means using the context menu as they do in all the other major programs they use (office etc). I understand your point of view, coming from a developer angle myself, but I know my users... the more low-level the user approach, the bigger the acceptance.
- putting everything directly related to the feature I use into the context menu is common practice
- To me as a scribus user the context menu doesn't feel cluttered at all - 16 items is not very much and putting the text properties right above "properties" wouldn't impair the readibility.
So, please think about it - I think (hope?) it wouldn't be too complicated to implement, but I know for sure it would improve usabiltiy very much.
i skipped to fast on your description and did not notice that you were talking about the text palette.
anyway, my stance still applies, and i'd prefer the PP not to be in the context menu.
(and the context menu should be not as hierarchic as it is now)
anyway, the text palette is -- hopefully -- very temporary and i hope that it will be integrated in a content palette that switches its content based on the type of frame that is currently selected.
and, as said, i really hope that we will have a better way to show / hide the PP (and the content PP)...
the work being done in the indigo branch (you can google for "scribus indigo") seems to be promising there (that is: a list of icons, one for each palette on the right side of the palette itself).
I support the idea of Andreas_Mueller since this situation is confusing for beginners and for those who come from 1.4.6.
My first thought was: no direct text formatting any more.
Please add that entry. Or even simplier: restore the old properties menu. When I can change everything else via that menu, why not text properties?
no, for discoverability, the solution is to show by default the properties palette and the text palette.
not to add things to the context menu.
and, of course, the team and/or martin should present what they want to achieve with the split of the text and PP.
a long time ago, there was a concept floating around, with a content palette (which would automatically switch according to the selected item) and a frame palette (you have to manually switch)... but i'm not sure anymore if this is what is still the goal.
||And its all going to change again in 1.5.4.. even more drastically.|
|2017-01-02 13:00||Andreas_Mueller||New Issue|
|2017-01-02 14:55||Kunda||Description Updated||View Revisions|
|2017-01-02 14:55||Kunda||Relationship added||related to 0014519|
|2017-01-11 10:08||ale||Note Added: 0043321|
|2017-01-11 11:23||Andreas_Mueller||Note Added: 0043323|
|2017-01-12 10:54||ale||Note Added: 0043327|
|2017-03-13 07:39||jghali||Relationship added||has duplicate 0014674|
|2017-05-24 23:25||jghali||Relationship added||has duplicate 0014818|
|2017-06-08 09:00||jghali||Relationship added||has duplicate 0014857|
|2017-06-08 13:48||Scriber||Note Added: 0044019|
|2017-06-08 14:08||ale||Note Added: 0044020|
|2017-06-09 21:32||cbradney||Note Added: 0044023|
|2017-07-21 12:06||jghali||Assigned To||=> jghali|
|2017-07-21 12:06||jghali||Status||new => resolved|
|2017-07-21 12:06||jghali||Resolution||open => fixed|
|2017-07-21 12:06||jghali||Fixed in Version||=> 1.5.4.svn|
|2017-12-20 20:58||cbradney||Status||resolved => closed|