View Issue Details

IDProjectCategoryView StatusLast Update
0014512ScribusUser Interfacepublic2017-01-02 19:08
Reporterchristoph_s Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Platformx86 64OSLinuxOS VersionopenSUSE 42.1
Product Version1.5.3.svn 
Target Version1.5.4Fixed in Version 
Summary0014512: Re-order Text Properties items so that they make sense
DescriptionEven after the separation of the Text options from the PP, the new "Text Properties" palette doesn't make much sense (and is still too big), because it mixes at least three different formatting areas (actually four; see below) almost everywhere. These are: character options, paragraph options, and text frame options. They should be separated to avoid confusion.


I suggest to regroup them accordingly:


1) Character options: font, font size, font family, tracking, kerning, character style, colours & effects, OpenType features, baseline offset, manual glyph scaling;


2) Paragraph options: Linespacing, alignment, writing direction, paragraph effects, hyphenation, language, paragraph style, glyph extension;


3) Text frame options: First line offset, columns & text distances, orphans and widows, optical margins.


Some options, like Language, could be available in both character and paragraph styles.



"Path Text Properties" shouldn't be there at all. The appropriate place is Item > Path Tools.


Moreover, the Text Properties palette should use a horizontal layout à la InDesign or XPress (see: http://what-when-how.com/digital-desktop-publishing/creating-your-document-the-world-of-desktop-publishing-part-3/) with three buttons on the left side of the dialogue to switch between character, paragraph or text frame options.


The necessity to distinguish between the three formatting/layout areas became clear to me after I watched a generally very good Scribus 1.4.x video training by an experienced DTP trainer, who even after careful preparation struggled with the chaos in the Text tab of the PP in the videos.
Tagsindigodock
PatchNo

Relationships

child of 0013906 acknowledged Metabug: UI enhancement proposals (1.5.x.svn) 

Activities

ale

2016-12-28 10:54

manager   ~0043234

i'm not sure that an horizontal toolbar by default is a good idea.

i normally work on vertical documents on an horizontal monitor (and i don't think i'm the only one...) and vertical space is scarce.

imo:

- first get a good vertical layout,
- then implement an horizontal ribbon.

there are few details that i'm not sure that are correct in the sections above... but, i think that such discussions probably first need a concept for the palettes being written and published.

christoph_s

2017-01-02 10:26

administrator   ~0043279

ale, there are reasons for InDesign and XPress using a horizontal layout. As you wrote, you are working on documents on a horizontal screen, which means there's more horizontal space than vertical (which is one of the major usability issues in Scribus with its vertically oriented PP). Also, a user interface is not the same as the general document orientation!

Feel free to list the details you think aren't correct. I'll gladly incorporate them into a UI mockup file.

tim_occ

2017-01-02 12:13

reporter   ~0043281

I think it is not an easy challenge to tackle vertical and horizontal layouts in one move.

Basicly the IndigoDock support currently vertical and horizontal panel directions, unfortunaly the panel content itself not yet.

The difference to InDesign is that they have a fixed layout for all (panel sizes, allowed panel directions, fixed position/size of control elements). That makes it a lot easier to create a working UI in all cases. Furthermore they have only one UI-theme in different shadings for all operating systems.
But Scribus have to support different operating system themes (Windows, Mac, KDE, Gnome, etc.). Every OS theme has different sizes, spaces, etc.

In some cases it makes no sense to have Scribus's panels in horizontal layout, e.g. if there is a long list view.

To achieve vertical and horizontal directions we can try to group all elements in smaller "blocks" which can float.
But we have to remove the lists from user interface. See my screenshot for a proposal.

Short facts: the UI will show only an access control element, like "choose color" and than you have a "floating overlay" or a "popup window" to modify the values. That could work for vertical and horizontal UI-layouts. But you have one step more to edit.

Floating_Controls.png (77,849 bytes)
Floating_Controls.png (77,849 bytes)

tim_occ

2017-01-02 15:10

reporter   ~0043283

Here is an example as a web application (Lucidpress) which comes without horizontal panels.
https://youtu.be/-CCYr_VKP8A?t=2m23s

Cool thing here, they found a way to optimize all the stuff for one screen because of usage in a browser.

Kunda

2017-01-02 15:14

updater   ~0043284

+1 for floating overlay

louisdesjardins

2017-01-02 19:08

developer   ~0043291

This issue relates to a previous discussion about Typographic Colour and I believe we should connect the two. Here’s the reference. The discussion is worth reading, I think.
https://bugs.scribus.net/view.php?id=9848

This dialog will allow more space. It’s a very specific task that don’t need to be delt in the main dialog and it implies many settings that work together to achieve one specific result. Once it’s set, there is no real need to get back to it so often. This will ensure very decent results (if not perfect) on the typographic front. Not a small victory!

A general thought about a working UI is gather the settings where it really makes sense, according to the complete process. The idea is not to have tiny portions of settings in distincts palettes or tabs, as many as there are options (this is the à la InDesign way and it is underproductive). Opening and closing tabs in the PP palettes doesn’t make things more efficient only because they are gathered in main palette. Yes, the settings are organised from a listing perspective, but they are not organised to make people’s work efficient. Basically, what I think we need is a deep understanding of the full formatting and layouting processses, as a whole.

It’s more complicated than simply putting things in order. However I agree that making the list is part no. 1 of that more complicated task.

This needs more thoughts than just gather "text" or other settings together.

The Typographic Colour set is part of what I envision here.

* * *

In paragraph, we need a couple options to manage what needs to be kept with next/previous paragraph. One good case example for this is you need a way to keep a subtitle with the next paragraph. In no way you want a subtitle to be left alone at the bottom of a page. This is not a widow/orphan case. They are disctinct paragraphs, not part of a paragraph.

* * *

There is a need for a "create style" dialog from the current settings. The user has only to determine whether it is a character or a paragraph style.

* * *
If someone feels I should create (or revisit) specific bugs/feature request for some of the items proposed here, just let me know.

Issue History

Date Modified Username Field Change
2016-12-27 07:25 christoph_s New Issue
2016-12-27 07:26 christoph_s Description Updated View Revisions
2016-12-27 08:56 FirasH Relationship added child of 0013906
2016-12-27 11:38 Kunda Tag Attached: indigodock
2016-12-27 11:38 Kunda Target Version 1.5.4.svn => 1.5.4
2016-12-28 10:54 ale Note Added: 0043234
2017-01-02 10:26 christoph_s Note Added: 0043279
2017-01-02 12:13 tim_occ File Added: Floating_Controls.png
2017-01-02 12:13 tim_occ Note Added: 0043281
2017-01-02 15:10 tim_occ Note Added: 0043283
2017-01-02 15:14 Kunda Note Added: 0043284
2017-01-02 19:08 louisdesjardins Note Added: 0043291