Scribus UI/UX improvements

Previous topic - Next topic

tim_occ

#180
@CGood: no problem. ;)

The effort is not to much for me. All the feedback here is very helpful to understand how Scribus will use and where are the biggest painpoints / frictions in UI. I think to get valuable user feedback is the hardest part in UI-Design. If you have specified problems you can solve it. :D

I think it is not posible to replace only one "feature" with a new one without updating another one, because all is releated - more or less.

About the scope I think we can focus at first for property panels (content and frame) and connected features. That includes:
- color mixing and handling
- styles (gradients, color sets, paragraph styles, character styles, table styles)
- remove clutter in text editing section (focus on most important settings, all other stuff are advanced settings for a second level)

That will be a big rock, but it is dueable.
BTW: this UI updates can be make independently of the IndigoDock integration, because it will work in the current Scribus user interface too.

regards,

Martin

CGood

I think I was not very clear in my description using the term rainbow window. I have included a rough sketch to show what I mean by rainbow window. All else in my sketch is merely context and I don't mean for the rest to be a suggestion. I trust you are on a very good path towards a cleaner, faster, less "click heavy" interface.

[attachment deleted by admin]

GarryP

In the interests of simplicity - and to avoid the alienation of existing users - I would suggest that, at first, the UI isn't changed too radically when it comes to colour selection/editing. A lot could be done to improve colour selection/editing but I think some basic changes would make a big difference.

I don't have any real problem with how colours are selected via the PP. Things could be moved around a bit but the method of selecting a colour is relatively easy to understand for beginners and not a huge problem for experienced users. It could be improved but I think any changes in this area would make for a far larger change that is necessary and might have too many existing users complaining.

It's the colour editing functions that I have a problem with and my main problem is with the modality of the dialogs. Having to open a modal dialog and then another within that to edit a colour and to OK them both before seeing what a colour change actually does is a real pain, and can add many more clicks than is necessary.

If the two dialogs could be combined and that combined dialog was made non-modal - I.e. the same as the Layers palette - then editing colours would be made so much more simple. If I could leave this "Colours Palette" open and make adjustments on-the-fly it would make Scribus so much more easy to use and could even help to bring new users in as it's more what they are used to in other applications.

If this new Colours Palette was a wide window - as in some of the examples supplied - it would take up too much screen space if it was constantly open. I would suggest making it a thin vertical strip which could be docked to the side of the main window without getting in the way of what the user is doing. (See the very crudely-made attached mock-up.)

Basically, combine the two dialogs, make the combined dialog non-modal and change its orientation to vertical. That would do me fine and dandy, for now anyway.

NOTE: If the Colour Palette was non-modal - and therefore all adjustments were made "live" - there would be no need for an "Old/New" display. Imagine you move a slider and change a value to get the new colour. There's no way for the software to know which was the "real" old colour - the colour before the slider change, or the colour after the slider change but before the value change - so the "old" colour doesn't have any real meaning. So why keep it?

[attachment deleted by admin]

cloudbusting

#183
I agree with the vertical layout for the colour panel, I think it would be more economical as far as space goes. I think this is where the beauty of having a left and right panel area comes in. I can see myself having more "permanent" panels of user's preference on the left of Martin's UI, while making full use of the scrolling feature with the panels to the right.

a.l.e

hi

i really love how this thread has going on for months and that the discussion does not stalls but slowly progresses...


and now for something completely different...


but i somehow miss some sort of agreement on a general direction.
i see pixel counts in the PP draft, but i don't see any explanation on how people are supposed / are using the PP itself.

i started writing a document for myself:

https://github.com/aoloe/scribus-ui-concept/blob/master/content/general.md

but it might also be interesting for other people...

what do you think about such an approach?
it's not about replacing detailed mocks, i see it as a complement...

ciao
a.l.e

CGood

GarryP, I'm not sure I am reading your post correctly. Are you referring at all to the Add Color function? I understand that you want to "Edit" live, and in a smaller panel than I might want, but are you also saying the panel space to add a totally new color should be similarly size constrained?

CGood

In your github post you ask,"Should the list of open palettes be linked to the document or to the Scribus instance?"

I don't know if I am answering your question or muddying the waters if I say 99% of the time I want the text properties to be want is open first. I use the XYZ far less than text properties. To me having the XYZ open by default is one more place where I have more clicking that gets me to the workspace I wanted all along.

I am a creature of habit and would prefer Scribus to open either to a default place I choose - Text Properties - or to where I left off last time. Does that make any sense?

CGood

A further response to GarryP's post. If we do use a Color Edit structure like GarryP's recent post, please let the sliders be long enough that incremental fine tuning is easy.

tim_occ

Hi guys,

a.l.e. I like the idea of an onboarding screen, where the user can choose options what he wants to do. The concept remembers me to photoshop, as seen here:
http://pe-images.s3.amazonaws.com/basics/cc/2017/interface/recent-files-panel/photoshop-cc-start-screen.jpg

Some other applications include directly some tutorial videos there too. What is also nice for beginners.

About your open questions in the Git repository:
Quote"Should the list of open palettes be linked to the document or to the Scribus instance?"

If I get you right, you are asking of storing the workspace layout (palettes layout etc.) into the document file, like blender do it?
I think it should be linked to the Scribus instance and load from user profile. Lets say someone create a file with his own workspace layout and give it to someone else - it could break his workflow because of arranging the layout that fits to him.

What do you mean with "resource Window"? Is it the symbols/scrapbook palette in Scribus? I thought it is not document related, and I think it should be part of the user profile workspace. Or do you mean the ressource manager?

regards,

Martin





tim_occ

#189
What's about this picker?

You can extent the dialog if you want to use the color palette or you can change the color picker mode. I agree with Garry, if there is a live manipulation you don't need much big color preview or old/new color.

regards,

Martin

[attachment deleted by admin]

MrB

@tim_occ: This stuff is looking very good!

We're very close to releasing 1.5.3 and once its out, we want to concentrate on 1.5.4 with integration of IndigoDock and palette redesign. We need to sync up on design and proposals etc. Maybe email me mrb@scribus.info and CC jghali@scribus.info

thanks
Craig

CGood

Martin, that looks like it addresses a lot of the shopping list. I like it!

GarryP

CGood:

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

If the dialog (palette) is designed correctly then it could be resized as the user wants. My recommendation was that it should be able to be sized to fit into a vertical strip that can - if the user wants it to - be docked or simply placed to one side of the main canvas. If the user wants to make the dialog as short as possible then that would be up to them. Conversely, if the user wants to make the sliders as long as possible then they should be able to extend the height of the dialog to accommodate that.

CGood / a.l.e / Martin:

I'm not sure what "Should the list of open palettes be linked to the document or to the Scribus instance?" means. What "palettes" are being talked about - colour palettes or UI palettes (e.g. dialogs), or something else - and what constitutes an "open" one?

If palettes refers to UI palettes (dialogs) then I would agree with Martin that their constitution - open/closed, position, etc. - should not be linked to a document. There are many reasons for this, and Martin has already given one, but one specific case would be if someone using a very hi-res screen (e.g. 4K) passed a document onto someone else with a much lower resolution screen. The main window and the dialogs could have positions/sizes that are outside the lo-res screen area which could render Scribus unusable.

If, on the other hand, palettes refers to colour palettes then I think it would be nice if Scribus could handle multiple palettes within the same document. For example, if someone has a newsletter where the colour scheme changes by season - e.g. orange in summer and blue in winter - then it would be good if the user could easily switch between different variants of the same palette. In this way, the colour "Primary" could be orange in the "Summer" variant and blue in the "Winter" variant. Having this kind of functionality would also mean that the user could test lots of variations of colours while being able to revert back to a particular saved scheme without having to write down the colour values.

Martin:

I don't know how your "Colour Picker" dialog is supposed to work but I think the inclusion of gradients and patterns may have some problems. Gradients and patterns can only be given to fills and not outlines, therefore the user should not be able to choose either a gradient or pattern for outlines. How would you achieve this? Would the dialog "know" that you were picking a colour for an outline and not a fill?

I like the idea of keeping all of the colour stuff together, I just don't know how you intend it to be implemented. Maybe I have just not properly understood what you are doing.

General:

I think some confusion might be starting to creep in here about different dialogs for different things.

The change in functionality that I was suggesting for the "Colours" and "Edit Colour" dialogs - combine and make non-modal - are, in my mind, not to be confused with any kind of "colour picking/choosing/selecting" dialogs/panels/panes/windows.

To me, for DTP purposes, the act of defining/editing colours should be a different function to choosing/picking/selecting colours. The user should define the palette that they want to use and then choose from that palette as needed. A little like going to the DIY store to get the paints you want (defining the colours), then putting your brush in the right paint pot (choosing the colour).

Maybe there is a way of combining the two functions but I don't know how that could be achieved or how effective it would be. I think it would be better to keep the two functions separate. This forces the user to think about how they apply colour to their documents rather than just using whatever they want. I realise this way of working is a bit of a throwback to the old mechanical printing processes but I think it's important that Scribus keeps to this tradition even if most people don't get their documents printed the "old fashioned" way.

tim_occ

Garry,

correct me if I'm wrong but you can set gradients for borders. (tested in nightly build 1.5.3.).

So, let my try to explain what are my thoughts about the color picker. 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.
Here is a showcase how the color picker looks like in different contexts:
https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1b2d6150d9_0_19
(Slide 9 and 10 show the color picker, slide 15 - 17 show the contexts)

The color picker itself contains a color mixer and one local color set (color palette) for the document.

You can access these color picker on different places:
1. global as it is via menu bar: Edit -> Colors and Fills...
2. in property panel if you set a color for: Fills, Border, Text

1) If you open the color picker via menu bar you can only edit your local color set by mixing new color, remove colors or import colors from other sets, becasue there is no context object. Further more you can edit gradient palettes or your patterns. This mode is for all users which want to have a global management.

2) If you open the color picker via property panel you will have a context object which tell the color picker which options have to be hide/disable. In this case you can also edit you local color set, but you can edit the object color too. In such case you will have a realtime color preview in your object. You can use a custom color by mixing the color directly in the mixer or you choose a color from your predefined local color set.

I hope I could explain it clearly. :D

regards,

Martin

GarryP

I have no idea what's going on in the 1.5.x versions so I can't comment on gradients for borders. I'm not sure what constitutes a "border" and why it's different to a line (as currently exists), or are they the same thing just under different names?

I think I can understand where you're coming from now but it might take a while for it to properly sink in. It goes against what I said in my previous post but if it's a better way of doing things then I'm all for that.

In what comes below I've used the term "brush" instead of "colour or gradient or pattern" as it seems to be a reasonably prevalent term and it's more concise.

So, if I've got it right so far:
1. The "Edit -> Colours & Fills" dialog allows the user to create a standard palette of named brushes that can be used globally throughout the document.
2. The "Colours & Fills" dialog allows the user to create, edit, delete and import named brushes.
3. Any changes to the named brushes in this "Colours & Fills" dialog automatically affect any objects using those brushes.
4. Essentially the "Colours & Fills" dialog is an extension of the "Document Setup" dialog but in a different place.
5. A separate dialog - the "Colour Picker" - will be available.
6. This "Colour Picker" will be available when an object is selected.
7. It will look like the "Colours & Fills" dialog but will act differently, as below:
8. The user will be able to select from the standard document brushes or create a new custom brush.
9. The new custom brush will have no name and cannot be used elsewhere in the document (except if the user gives the same values or uses the eyedropper, of course).
10. The standard document brushes cannot be altered in this "Colour Picker" dialog, they can only be selected.

Do I have a basic understanding of what's going on or have I missed something? If I have it right then it sounds like a good way to do things. Neat and understandable.

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. A big time saver.

I also have another suggestion: Would it be possible for these dialogs, when displaying a colour (not gradient or pattern), to have an extra rectangle to each side of the current colour? These rectangles could each display a user-selected colour (from the existing list) - defaulted to black and white - which would help the user to choose a colour in relation to colours already created. It's not a high-priority item or anything like that but I think it would be useful (if the whole thing is going to change then why not take things further?).

All in all, from what I've seen, this looks like it could be a massive leap forward for Scribus. It's "basic" things like this that make all the difference to using an application. If the basic stuff is difficult or time-consuming then it puts people off. Making something like colours much easier to use will make such a big difference.