Scribus UI/UX improvements

Previous topic - Next topic

tim_occ

Yes Garry, it is exactly what I wanted to describe. :)

In the color picker there is a "plus" button next to the color palette to send custom brushes to the list for a global usage. You can edit colors in palette by double click. The only thing what I have to think about is how can a user cancel the editing of a color in palatte to create a custom new one.

About the Line and Border wording... it is the same. In Scribus 1.5.3 you can use gradients for Lines as well for Fills. In my mockup I renamed "lines" to "border" because it is an often used wording in other applications for such settings. But I can rename it back to "lines". We can also use "contour". But wording can be a part of refinements afterwards if we have the basic concept done.

regards,

Martin

CGood

Just to be sure I am on the same page as others.

"Lines" properties such as thickness, dashes, corner profile, flat cap... currently apply to individual lines as well as borders of frames, so it applies to objects with line like behaviour. I assume that whatever the name for that panel, it would assign appropriate properties to single lines and to frame borders.

I want to be able to name colors when I create a new color - and - to be able rename them when my edit changes essential nature of a color. It sounds - GarryP that you are saying this too: "One thing I can add at this point is that I think it might be good to have an extra "Send to Standard Palette" button on the "Colour Picker" to allow a custom brush to be used globally. The user would give the brush a name, the brush would be inserted into the standard document palette, and the local custom brush would be changed to use the new standard brush."

I really like the idea that color edit changes be immediately reflected in the Scribus document. Several less steps.

Martin said: "The only thing what I have to think about is how can a user cancel the editing of a color in palatte to create a custom new one." A simple revert or cancel button to undo changes in mid process might suffice. I suspect no issue as long as the numeric color definition of the original color was to be held in memory to be reverted to.

GarryP - I am very fuzzy on the implications of the word "Brush" with respect to color in Scribus. Is "Brush" synonymous with "a tool to assign color" with respect to Scribus?

Outside the scope - I think - of the discussion so far is the idea that I'd like to be able to add colors to my default or persistent palette even if I have a current document loaded into Scribus. I suspect that may be outside of the scope of this current project but not knowing the code involved, I mention it. Perhaps in some future iteration - Scribus 3.0...?

On GarryP's assesment of the modal / non-modal behaviour of the color selection/ editing dialogs or panels..  "What I am proposing is that the "Colours" dialog - currently shown by menu "Edit -> Colours" - and the "Edit Colour" dialog - currently shown by pressing either the "New" or "Edit" buttons on the "Colours" dialog - are combined into one single non-modal dialog (or palette, depending on how you want to call it)", it would be wonderful if color picker/edit panels would not prevent interaction with the Scribus document while the dialog is visible. I understand that is called non-modal behaviour? I like GarryP's ideas for that very much.

I also like GarryP's concept that color edit / pick dialogs be resizable.

I believe it makes sense to have to select whether one is modifying color/pattern.. properties for fill or for line.

Martin: " My basic idea is to replace all color picker / mixer in Scribus with a common one. You are right patterns and gradients are not available for all objects - the color picker have to be context specific." Agreed on all points.

Again - this all feels like dramatic progress in making a happier interface.

tim_occ

Quote"Lines" properties such as thickness, dashes, corner profile, flat cap... currently apply to individual lines as well as borders of frames, so it applies to objects with line like behaviour. I assume that whatever the name for that panel, it would assign appropriate properties to single lines and to frame borders.

Yes, exactly.

Maybe we should define some more wording terms to be on the same side.

Global Color Sets
Global color sets are external color libraries, like the "color swatches" in Scribus ressources: https://github.com/scribusproject/scribus/tree/master/resources/swatches

Document Color Set (local color sets)
It is your individual color set what you use in your document. If you make changes there it will affected only your local document.

Local Color
Is a color which is not contained in a color set. It is just local in a single document object, like a rectangle frame.

Global Color
Is a color which is contained in a color set. By changing the gobal color all linked objects will update the color.

Modal Dialog
A modal dialog is a single window which lock all other windows / UI elements of an application until a "confirmation" action in the modal was made.


If you agree we can use these wordings to explain things.
----

So, the color picker have a color mixer to mix new colors by set color values or by picking a color from color map / color slider. Below the mixer there is a local color set which will only used in your active document. Next to the local color set there are buttons to load full external color sets or just single colors from such external color set into your local set.
Further more you can save your local color set as an external one to use it later in other documents.

You can have local colors and color sets which you can extend by importing external ones or you can "convert" local colors and color sets to global ones.


regards,

Martin

GarryP

(Here we go, it's another long post with a lot of different ideas stuffed into it...)

Martin:

Thanks for confirming that I'm thinking along the right lines. I was concerned that I might have got it all the wrong way round.

As for the naming of lines/borders, a "border" as the word is used in English has connotations of something that surrounds or divides things - which could be confusing - but a "line" is just a line, whatever it's used for. Continuing a similar logic, a "contour" could be confused with the "contour line" which is used for text flow.  Might I suggest, following on from my use of the word "brush", using the word "pen" instead?

A "line" is something that is drawn through various points. (This could also be called a "path" but that would be confusing to users.) If we want to detach the concepts of points of a line from how the line is drawn then we could say that the user draws a line with a pen. The line stays as the collection of points but a concept of "pen" could be used to say how it is drawn.

Most graphics APIs use similar concepts and I think it's a good analogy for Scribus to use. People are used to drawing lines with a pen in the same way that they are comfortable with using a brush to paint an area.

Currently, Scribus uses "Line Styles" to say how a line is drawn and I think the concept of "pen" could be used in exactly the same way but it would also avoid the confusion of mixing it in with the other text styles. (I've always thought that line styles were defined in a confusing place.)

Basically, if the user knows that a "brush" - a solid colour, or a gradient, or a pattern - is something they can use to cover an area and a "pen" - a solid colour (or gradient as of 1.5.3) with a width, arrows, etc. - is something that is used to decorate a line, that would make things easier to think about. They could even be presented to the user using similar dialogs which would give a more consistent UI. (Maybe pens and brushes could also be applied to text in the future?)

Obviously, as you say, the wording can be argued about once things have progressed further. I just think it might be worth putting in a bit of time to get the overall concepts sorted out in case some optimisation can be achieved.

CGood:

I think I've tried to make it clear above how I think line/borders should be treated. Essentially, the stuff that is currently related to "fills" - solid colous, gradients, etc. - should be treated as a "brush" and the things that are currently related to "lines" - solid colours, width, dotted, etc. - should be treated as a "pen". If I've not explained it well enough or you think it's wrong in any way - especially if there is an exception or problem that hasn't been covered - then please say so. I am in no way saying that I think I'm right and that it's the only way to do things. I'm just saying that I think it would be sensible to look at things that way but I could be totally wrong.

Naming pens and brushes - what are currently called colours, gradients, patterns, line styles, etc. - is a very important function and should, as you say, be kept in Scribus. It would be very bad if users couldn't name things like that as there would otherwise be no way of keeping consistency between objects.

Immediately applying changes "live", especially for basic things like colour changes, has to be - in my opinion - the way forward for Scribus. In this modern world users want, and should expect, to see changes like that happen immediately. There are really only two reasons why this shouldn't happen: 1. The hardware being used can't handle the redraw fast enough, or 2. The developer doesn't know how to do it. I'll leave the people reading this to consider each situation for themselves. (There is a third reason, which is that the developer has their hands tied by the API or other bits of the software but that's really just another way of saying point 2.)

As for a "persistent palette", you might have a point there. There seems to be various types of "palette":
1. The "saved palettes", the ones you can import from;
2. The default palette (I can't remember where this is set as I've never bothered to change it);
3. The saved document palettes (which can also be imported);
4. The current document palette;
5. The custom colours within the document.
There might be a way of managing all of these more consistently - and maybe there should be - but I think you're right that it would probably be something for the future. It would be nice to be able to easily save palettes outside of a document so they can be reused. Or maybe what we've got is enough. (Edit: See below where I've answered pretty much the same question but in a slightly different way which could even look like I've done a U-turn!)

Martin (again):

I started writing this before your latest post came in so I'll just append my extra comments here.

I like the idea of having some definitions now that things are getting a bit more complicated. If I could just amend/expand your definitions a little:

Global Colour Sets
* are a set of named Global Colours;
* are self-contained files;
* are supplied with Scribus as resources;
* are not related to any specific document;
* cannot be editable by the user.

Global Colours
* are named colours;
* are defined in Global Colour Sets;
* can be imported from a Global Colour Set into a Document Colour Set as a Document Colour;
* cannot be editable by the user.

Document Colour Sets
* are a set of named Document Colours;
* are defined in a Document;
* are only available for use within that Document;
* can be editable by the user.

Document Colours
* are named colours;
* are defined in Document Colour Sets;
* can be imported into other Documents;
* can be editable by the user.

Local Colours
* are not named colours;
* are defined in the object to which they are applied;
* can be converted to a Document Colour;
* can be editable by the user.

Documents
* are SLA files containing a user document;
* have only one Document Colour Set.

Document Windows
* contain a visual representation of a user document including rulers.

Scribus Main Window
* contains one or more Document Windows;
* also contains the toolbars.

Dialogs
* are single self-contained windows which Scribus can display separate from the Scribus Main Window and Document Windows.

Modal Dialogs
* are Dialogs that do not change the document contents or appearance until the action has been either confirmed or cancelled by the user;
* disappear upon confirmation or cancellation by the user.

Palettes
* are Dialogs where the action of the user is immediately reflected in the document window;
* are non-modal, meaning that they persist on screen until the user specifically closes them.

I hope that's made things a bit clearer. If not just tell me what I've got wrong.

Is there anywhere we can store this glossary so it can be easily amended? It would be nice to be able to point people to it where there is confusion. Maybe a "Glossary.MD" file could be added to the IndigoDock project?

I don't think that the user should be able to create their own Global Colour Sets as I would like to think of "Global" as meaning that they are the same throughout the world. Every Scribus installation has them and they are all the same so if someone says "Use Napier Green from the Classic Kit Global Colour Set" then everyone can do that and it's always the same thing.

Having said that, maybe there is a need to have an intermediary between Global Colour Set and Document Colour Set, "Persistent Colour Set" perhaps? I like the idea of the user being able to define their own colour sets that can be shared between different documents and it would also be nice if a change to a "Persistent Colour" would propagate to all of the documents that use that colour. I.e. You change a Persistent Colour in one document, then load another document that uses the same Persistent Colour and it has already been automatically changed.

The problem I have with Persistent Colours (and Sets) is that I think it would be difficult to manage them in a way that is easy for the beginner to understand them. Global Colours (and Sets) are fairly easy to understand; they are non-changeable but can be imported into anything. Document Colours (and Sets) are even easier to understand as they are the things most people use on a day-to-day basis. It's the concept of having a colour that can change between documents that will be difficult to get across to the user. I am imagining people getting in a real mess by using the "wrong" type of colour and not being able to figure out why another document has changed. Maybe I'm not giving people enough credit though.

Phew, I think that's probably where I should stop for now. My typing fingers are getting tired. If I've said anything that is wrong then please tell me.

a.l.e

hi garry

good idea with the glossary.

this is a bit the direction i want to go in the work i'm trying to do in the UI github repository i've linked a few days ago.

i will try to integrate (and possibly extends) your thoughts in there...

thanks for sharing the list!

a.l.e

tim_occ

Yeah I like the glossar idea and I have add it here too:
https://github.com/nitramr/scribus-indigo/wiki/Glossar

Again about lines, contour and border, I agree with lines. I think if we talk about different styles for fills we can use "brush" as term as well "pen" for line drawing. Because if we would take a look into the Scribus source code it is already there. Qt provide some classes for drawing.: brushes for fills and pens to line drawing.

But I think in case of the UI we can split the "brush" into the more specific versions, like: solids, gradients and fill patterns (as it is).

regards,

Martin

CGood

Regardless of some minor quibbling on my part here, the majority of changes concocted so far are real improvement and I support them.

Naming of color properties imparting tools

Re Brushes and Pens VS Strokes and Fills. I find the "Strokes and Fills" terminology as workable as any other. I feel that "Brush" and "Pen" implies functions we are not talking about - like caligraphy and drawing, when in fact we are setting color properties for predetermined areas and line like objects. Clunky as heck but would "Area Color Properties" and "Linear Color Properties", or "Area Color" and "Line Color" be appropriate? A border or periphery is a line that wraps around an area.

I am not sure that we can count on Scribus users to have much vector app experience to draw upon to make the pan and brush naming seem intuitive.

Perhaps - if brush and pen are adopted - the resulting confusion could be limited by mouse pointer hover help by saying "fill area w/ color", or "color this line", regardless of the formal naming.

Defining Sets Of Colors And their Functions

Can we avoid definitional conundrum by adding a name for persistent groups of color added by an individual user - by calling them "User Defined Colors" or similar?

Global Color does sound like perhaps the extended default set of colors Scribus arrives with.

I'm willing to bet many users will understand that changing a user defined color would change it in all documents, but that some will get blindsided.

I have no idea if what is stored - currently - in a document is the numeric definition of a color or the name. I don't know if changing my colors currently will propagate into other documents.  In the new scheme a pop up hint or hover help to tell the user of what happens to a changed color influencing other documents would / could prompt the user to define the edited color with a new name if the new color was really only needed in the current document. I think that could resolve user confusion with the new user.

No matter how it is done, all users have to commit naming and process to memory and there will be learning curves to surmount. We can at best make the process a bit more intuitive.

I do not want to have to re-make or import colors to get away from the raw default Scribus colors. The default colors are quite reasonably chosen very strong general purpose colors but they are not generally comfortable for me. I'm a painter so maybe I'm too picky about color. Perhaps if a really fast way of importing colors were there?

I would like:

Global Colors = default Scribus color sets
User Defined Color Set = persistent colors I have created and named that will be available to all my documents without an importing process
Current Document Colors = colors that are not available to other documents without some import process
Maybe for un-named colors an default color name could be auto generated? Color00001, Color00002 Color00003... even if these be only part of current document and would need to be imported to other documents.

Maybe a button to make a color - and it's changes - persistent and propagate across all documents?

But, reading in this forum has taught me the value of listening very carefully to GarryP's thoughts. So as I am not sure of the value of un-named colors, GarryP can you speak to the value of un-named colors and of not making all named user colors persistent?

I am 100% on board with GarryP's concept of faster acting color edits - regardless of naming etc. And hope we can eventually (or sooner) be rid of other modal dialogs etc in other processes.

Maybe the process of changing what colors are persistent etc is an issue for future updates? I suspect one may have to implement changes well below the level of interface to change a color database functionality?

tim_occ

That is how colors will store in the document file:
<COLOR NAME="Cool Black" CMYK="#990000ff"/>
<COLOR NAME="Green" RGB="#00ff00"/>
<COLOR NAME="Registration" CMYK="#ffffffff" Register="1"/>


I think it should be possible to create colors without give it a name. Sometime it is necessary to use colors in gradients which you have not definied in your color set, so you need local colors again. Would you give such color a name if you use it only one time in your gradient?

In my opinion color names making only sense in case of color brands, like "Blender Orange", "Coca Cola Red" or "Pantone 7740 UP". Colors without a name can just show the color values, like Indesign do it: C50 M48 Y20 K0 or R128 G0 B28.


CGood

One way to look at it is that if I want to add a name to a color, but I will not have to? I am happy with that.

tim_occ

I made a test to check if the new panel design is useable in the Scribus Workspace.

If you would use a Full HD screen (1920 x 1080 px) you can use the "content (text)" and "frame panel" in one column without scrolling. Check out the presentation to see more details about the content panel and give feedback here. ;)
https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1b39926b0d_0_4

In my opinion the text settings are still take a lot of space. Any ideas how to reduce it?

regards,

Martin

[attachment deleted by admin]

GarryP

This might be starting to get a bit more complicated than I thought it was going to be so can I try and put some points across that, hopefully, might help?

The first time I used the word "brush" in this thread it was only as a shorthand for saying "solid fill, or gradient fill, or pattern fill". I had to use the same phrase a lot so I thought it was a good way of being precise without being overly verbose. It seemed to be a reasonable word to describe these things as a group but it also seems to have added a bit of contention, so could I add these as glossary terms? (The glossary wasn't my idea by the way, but it was a good one.)

A FILL
* is a visual decoration that can be applied to an object;
* covers the entire AREA of an object;
* may or may not be named.
(Do we really need to define AREA? Maybe.)

A SOLID FILL
* is a FILL that uses a single COLOUR.

A GRADIENT FILL
* is a FILL that uses a GRADIENT.
(Someone else can properly describe a GRADIENT if they want to but I think we all know what we mean.)

A PATTERN FILL
* is a FILL that uses a PATTERN.
(Again, if someone wants to define PATTERN further then please do so.)

I think these definitions are reasonable - to start off with - and everyone knows what is meant.

As for "pen", that was just a logical extension of using the word "brush" earlier. Maybe that was a mistake, so can I offer the following for addition to the glossary?

A LINE
* is a set of POINTs;
* has a starting POINT;
* has an ending POINT;
* may or may not be a closed construction.

A STROKE (replacement for Line Style?)
* is a visual decoration that can be applied to an object;
* is used to describe how a LINE looks (this needs to be defined much better);
* may or may not be named.

A SOLID STROKE
* is a STROKE that uses a single COLOUR.

A GRADIENT STROKE
* is a STROKE that uses a GRADIENT.

A PATTERN STROKE
* is a STROKE that uses a PATTERN (these were in 1.5.0, no idea if they're still in there).

Personally I have no preference between "brush and pen" and "fill and stroke" as long as whichever is chosen is used consistently across both the documentation and UI. (And even better still across the code too, but that ship probably sailed years ago.)

The naming of colour sets still needs some thought but I agree with CGood that the names should properly reflect/describe what they contain so that there is no confusion. For example "User Defined Color Set" could be mistaken for the colours that the user has defined in the document. It's tricky but I'm sure we can come up with something good. Once it's done properly then it doesn't need to be done again.

After more thought, I also agree with CGood about what I called "persistent colour sets" (the ones that are shared between documents). They're probably an extra complication that isn't necessary at this point (and may never be). Can we all agree to drop them so things don't get too far off track? No point adding extra complication if it's not needed.

As for un-named colours, they would be very useful. To add to the example given by Martin, I often just want to experiment with colours, temporarily adding them just to see how things look. Currently I have to specifically create a named colour before I can even start to do what I want to do. An un-named colour would allow me to create what I want and then play around with colours, rather than having to create the colours before I really know what I want to do with them. I can end up with a lot of junk colours that way and I would prefer not to have to delete stuff that I didn't want in the first place. Being forced to name every colour induces extra work for the user when it's not necessary. As long as a local colour can later be converted to a document colour for use elsewhere then that would be fine.

The same goes for un-named fills. In fact, that's how Scribus currently works. You can't currently use a fill in different places without using the eyedropper. Being able to name fills would give the user more control.

Martin: I don't have enough time to look at your latest offering but it looks great so I'll put some proper time in to have a think about it over the next few days.

CGood

#206
Hi Garry - Perhaps I took your previous use of "brushes and pens" terminology too literally. I am in agreement with your newest glossary.

Martin. My own take on the space used by the Text Properties Panel or dialog is that I don't think it is too large.

I have cobbled togther a notion - attached - that might be able to reduce unwanted space useage by any given extended panel by enabling the quick and convenient opening or closing of secondary related topics.

Please do not take this as anything but an idea for quick opening and closing of primary and secondary level properties panels or dialogs. My general idea is based on designs like LibreOffice - a set of small buttons to open properties panels or dialogs.

I do not intend to be suggesting here actual levels of what constitutes a top level category or secondary... So I offer an idea of functionality - not taxonomy. If I have anything at all to offer here it is the idea that small buttons might be able to represent two levels of detail and do so without visual confusion. A way to reduce clutter.

The very thin vertical yellow bar denotes second level properties accessed to the right of it. And that the topic directly above is primary.

All that said, I have no idea whether my notion is a good match to the beautiful scheme that is coming into focus in these pages and in your work.

EDIT: I should note that no other portion of my illustration is intended to offer suggestions about interface - they are there only to provide context.

[attachment deleted by admin]

cloudbusting

#207
Do you think those secondary buttons for text properties are really necessary, though?
My understanding was that we were trying to do away with those dialog-inside-of-dialog steps that the current Scribus ux suffers from. The text properties panel is probably the main improvement I'm looking forward to with Indigo as the current dialogs are already so fragmented...  How can we come to an agreement on the most important or primary text features?

For example many designers will be interested in advanced typography features, but I know not every user will have use for these. I think finding a balance between one user's clutter and another user's primary features is vital for the type panel

EDIT****
Sorry CGOOD, I didnt view your mockup closely enough!
For a minute I thought all those secondary properties were separate panel buttons!
I think this could be a good way of organising the advanced features

CGood

cloudbusting - Thank you - Notwithstanding your rereading and subsequent positive assessment - I think your initial questions, criticisms, and concerns are absolutely pertinent. I present my notion as just one possibility for a visually and spatially compact way for a user to be able to open or close panels or dialogs quickly. That ease of closing part is perhaps most important since it could be a key for the user to de-clutter.

It is something of a trial balloon. I am not sure it would fit anyone else, while I could work with it happily. I have lofted the notion as a way to see if others like it or not. Perhaps the one part that is truly novel is that yellow vertical stripe that connects a number of secondary topics within the primary topic directly above the yellow.

Just like in politics, it is the details of what-does-what that counts; the exact way the pieces interact. In fact, your excellent questions got me thinking outside the confines of my initial notion. Such a set of buttons could behave in various ways I had not given thought to.

In my initial conception, all secondary buttons are visible, and to open a second level dialog one clicks on the second level button. Clicking there again closes that same  panel.

In another way to make things work - even the secondary level buttons are revealed only when the corresponding primary panel is opened. See my attached image. Less clutter - but secondary buttons must be discovered by the user. It would be a trade-off. The interface could stay very clean. But more clicks. But what do other people think?

There is one factor that has not received much attention - that simplifying where one goes, not just how one goes, makes an interface more usable since that step of remembering and deciding to go to this menu, or that icon, or another panel button is changed to just knowing I move the mouse pointer to a single zone.



[attachment deleted by admin]

GarryP

I think I need more time to think about this new idea, but it looks very interesting.

As has already been mentioned, the way that the current PP UI behaves like a graphical Matryoshka doll can get very confusing. As I said on the first page of this thread, there can be scrolling sections within scrolling sections and that makes things look very ugly and difficult to navigate.

I would prefer that - on most people's screens - no scrolling was needed at all within the PP. Having used Inkscape for a while - with what can be a seemingly endless "scrolling tool window" (or whatever it's called) - I think scrolling is bad for this kind of thing. Just having "Arrange" and "Align and Distribute" and "Fill and Stroke" open on a 1080p screen means you have a scrolling area. To me, that's not right. (Yes you can "iconify" things but I think it's confusing. Maybe it's just me.)

If I have understood the proposal correctly it would mean that - for sections that have sub-sections, e.g. Text / Optical Margins - there would only be one sub-section displayed at any one time. This sounds okay but I have the feeling that there should be a "priority sub-section" that is always open when that section is open (e.g. for Text, you would always show font, size, justification, etc.) regardless of which other sub-section is open.

IMPORTANT: I think this would be a good point for us to get some kind of handle on what these things are called. If some people call them tabs and sub-tabs, or sections and sub-sections, or areas and sub-areas it will get very confusing. Is there a proper word for these "sections" / "sub-sections"? Can we agree on a naming convention? Do any other applications call them something nice that we can use? The names would have to be something short that would give people a good idea of what they do. For instance, calling them things like "priority functional area" or "secondary sub-functional panel" will be horrible. I have no ideas at the moment so I'm totally open to suggestions.

All in all though, this idea could have merit but I'll need to let it rattle about in my brain for a while to see if I can think of any situations where it could make things worse. (I can't think of any at the moment.)