Scribus UI/UX improvements

[utnik]

...Personally I have no preference between "brush and pen" and "fill and stroke"...

...neither have i in general – but as almost any other software for graphics and dtp use 'brush' and 'fill' in a certain way, we shouldn't change this for scribus. (a 'fill' is what we're talking about – and a 'brush' is usually what you call 'pattern stroke' – if i understand your description right...)

utnik

[tim_occ]

Guys,

just an idea. Let's say we remove the text and property panel completely as separate panels from layout and put them in a fixed place. I analyzed a bit more Indesign and Quark XPress. Both have object and context related main properties on a fix place on top. All panels on right side in Indesign or XPress are used for other categories, like pages, alignment, layers etc.

Let's say we would follow a similar concept to have all properties object and context related on a fixed place to organize other categories on the left or right side of Scribus workspace.

I made some thoughts about these concept. See attachment.

There will be an icon section which is visibile if an object is selected. In example a text frame.
Now the section show only icons for properties which can be made for these object (our text frame).
It show single icons for:
- frame properties (xyz, fills and lines)
- text properties (font, color, alignment, styles)
- advanced character (character scaling, etc.)
- advanced paragraph (hypenations, optical alignment etc.)
- shape
- etc.

The area where you can make settings for the properties will float over the document, but can't move. Just show and hide by clicking on linked icon.

In my proposal I show only two icons instead of X possible icons.

Further more there can be a section in these bar to add custom features as a shortcut to scripts or other stuff. A user can add such shortcuts by click on "add shortcut".
What do you think about it?

regards,

Martin

[attachment deleted by admin]

[CGood]

I'd like to hear other responses. I am going to think more and hope to hear arguments and opinions before I say I'm fully against or in favor of this latest idea of text properties living separately at the top, but my initial reaction is that I am wary of any new space consuming items at top or bottom constraining the workspace vertically.

I tend to be unhappy with any image or document program limiting usable vertical workspace. With the shorter and wider screens available nowdays, any spare space seems to be to the left and the right. Vertical space is in very limited supply. This is most true when working with documents that are vertical or portrait mode. I seem to always want to clean out the top and bottom as much as I can. Could I get rid of all stuff at top and bottom, I would, and I'd put it at the sides.

Were it up to me, and for my use only, I'd go so far as to be rid of all of the menus, program ID, and close/minimize/etc buttons and all the wasted space at bottom. I'd put all that stuff to the sides. Were screens less extremely horizontal, I would feel absolutely differently. I should say clearly that I am not suggesting we now engage in extreme redesign of the ordinary workspace. I would like to just register that adding things at top, and especially things that drop over and obscure the working document feel like a regression to me away from user friendly design.

I hope not to discourage out of the box thinking since while I don't like the idea of crowding the vertical space by putting a text properties floating rectangle over the workspace, I do like the idea of having near instant access to text properties. I may use them more than all others combined. But a set of properties palettes at the sides would do the same.

Button Behavior

I did not mean, yesterday, to imply that opening one secondary panel would prevent others from opening - nor the opposite.

It is an open question, if my notions yesterday have any merit at all, of how exactly the buttons and panels might behave.

One way could be quite restricted in which only one primary panel and one of its secondary panels could be open at a time. Very clean, but maybe a bit restrictive?

The vague notion I had in my mind but not as a suggestion yesterday is that one could open as many or as few panels as one wants, and soon the total length would exceed the length of the vertical space for panels - and a scroll bar would magically appear. That would allow a user to scroll up and down through the panels if that user wanted. That same user could use buttons to close panels and restore order. I tend to opt for non-destructive freedoms if those freedoms don't mess up my interface. So, today I am suggesting that.

Another mode could be allowing one primary panel and as many of its secondary panels as the user wants, but no other primary or secondary panels.

I see no benefit to all such restrictions, but the geometry of my general scheme allows many ways of doing things.

I'm voting for unlimited open panels. User freedom!

Naming

GarryP's questions about naming are important.

One idea - "Parent Panels" and "Child Panels" - that makes the relationship between upper and lower level very clear.

My original terminology does not have the same clarity - "Primary Panel" and "Secondary Panel" - which Primary goes with which Secondary? Well, the geometry of the buttons would help, but the naming does not point one's intuitions quite as neatly.

[CGood]

To make my notions a bit more concrete I have made an image that might help everyone visualize my thoughts.

[attachment deleted by admin]

[GarryP]

utnik:

I haven't used any other DTP software for a long time so I have no argument about what other applications call things. If "brush" (for how lines look) and "fill" (for how areas look) are the "industry standard" then I would be behind a decision to make that the way Scribus works. The less people have to re-learn when coming from other software the quicker they can get into it.

The icons in the Colours tab of the PP seem to already be that way but the rest of the UI doesn't really match up, e.g. the "brush" options are under the "Line" tab and they're also controlled by "Line Styles". It's confusing for beginners if there's both a line (tab) and a brush (icon) but they relate to the same thing. My point in trying to get a consensus on what they were called was to get consistency across the UI (and documentation). In other words, "brush" means the same thing everywhere and everyone knows what it means.

If everyone is happy with "brush" and "fill" then I'm happy too.

Martin:

Your context-sensitive floating toolbar idea sounds very nice in theory. (I can only say "in theory" as I've not used it, since it doesn't exist yet.) I think it would certainly help people who are coming over from other software, such as word processors, as it's something like what they are more used to. (Now and again we get questions from beginners who have trouble with the concept of the Properties Palette.)

I'm not sure if I'm 100% sure about splitting some functionality between the PP and a toolbar. It might be better to keep it all in the same place (for consistency) but, then again, it might not. Having to go to one place to do some stuff but then another place to do other stuff related to the same thing might be a bit confusing. I've thought about this sort of thing myself in the past but have never come up with anything that I was really happy with. Maybe an expansion of your idea would lead to something really great, I just don't know.

This is one of the big problem areas with UI design: everyone's different and wants things differently. While one person might love using toolbars (or something similar), someone else will hate them (for whatever reason).

If    I was being forced to make a decision about this, right now, I would probably come down of the side of just making the PP more usable. It's less of a controversial option and it's what existing users are used to. That's not to say that the toolbar option is "wrong" or anything, but it's probably just a bit of a step too far at this point. I think its one of those things that you've got to actually use in practice to see what you prefer and that's probably not practical (there could be a whole lot of work that may have to be scrapped if people don't like it).

Having said all of that, I can see the benefit of having some of the most used options readily available via a toolbar (font, size, fill colour, etc.). The only problem with that is: "Who says what the most used options are?" What I use most might not be what other people use most. This is a very tricky area that has no perfect solution. All you can do is try and come up with something that the majority of people are okay with.

CGood:

I have the same issues as you when it comes to vertical space being used by the UI. Most displays now are wide screen, as you say, and I find that - especially when working on single-sided documents - I have a lot of unused space to the left and right. I normally fill these up with the Align and Layers palettes (because I use them a lot).

On the other hand, (there's always another hand) what about people who use their screen in a vertical orientation? A lot of DTP professionals - and others - use a vertically-oriented screen because that's the orientation of the pages they're working on. For these people, the horizontal space is more precious than vertical space. A big PP off to the side will fill up quite a bit of their display. I realise that most people are working on horizontal screens but it's worth keeping this in mind if Scribus is presenting itself as a product for professionals.

Basically what I'm saying is that what's right for some won't be right for others. If the UI can offer a solution that can be changed according to the user's individual requirements then that probably the best solution, but it's probably a lot more work.

As for primary and secondary panels, I agree that the user should be able to say which panels they want to be open. If they want everything open then that should be allowed. Conversely, if they only want "the basics" open then that should be allowed too. Let the user decide.

As for naming, I'm trying to get away from using "primary and secondary" and, probably, "parent and child" and, if possible, the words "panels" "sections" and others. It's difficult to describe but an analogy would be with cars. The driver has a "dashboard" which has most of the controls on it. Within the dashboard there is the "centre console" and the "instrument panel" and the "heater controls" and the "media centre", etc. These things all have different names and it would be nice to be able to give each of the things in the PP a specific name so we don't have to use sentences like "open the PP Text tab, then expand the Columns & Text Distances sub-panel and press the Tabulators button". We could just say "go to the <thingy>", whatever the <thingy> was called, and it would be obvious where that was.

This might be a very difficult thing to do, and it could be completely pointless in the end, but I think it's worth thinking about as it might give some insight as to a better configuration for the PP. Then again, it might not, but it's worth a try.

[CGood]

Some thoughts:

Naming

Maybe there is no perfect naming for the contents of controls for properties? While I'm uncomfortable with brushes and pens - if those have wide industry support in this context then that is worth considering. If only for the purposes of explanations, the wiki, and tutorials, we do I believe need to name the more central properties and those more subsidiary. Martin's original project and his analysis of what "contains" what, and the question of naming all have me thinking again of the "tree" of essential, central properties, and those that are subsidiary. Another way to look at that is to look at what properties are shared by many or few objects.

The "tree"

I have been thinking about what properties "belong" to what objects and which way one might imagine the parent vs child sorts of relations might be described or defined. I have put together and attached a rough notion to illustrate my  initial conception. Working with databases has taught me the importance of identifying what belongs to what very clearly. I found that first my impressions can be less than accurate. So - what have I missed here and what needs a re-think?

I think this is important. Understanding what belongs to what might help naming and structuring properties palettes (and buttons if they be helpful), structuring what really belongs in what menu eventually - pretty much everything.

Where to put properties palettes

I was wondering if the assumption was that everyone is using really large screens horizontally. The thought of screens in portrait mode hadn't occurred to me. I wonder if it might be a good idea to consider folks with smaller than optimal horizontal screens. I'm not sure it can be assumed everyone has a big screen. For instance I use a laptop since I am on the road a lot, and the laptop has become my primary tool despite minimal screen.

Looking to the future...

Would it be possible to envision as a Version 2.0 of an enhanced interface, the ability to drag the properties palettes to any of the four sides or detach them and float into second monitors etc? That would give the user a high level of freedom to make the workspace their own. I assume this is a few steps too far for the current project - too much new code.

[attachment deleted by admin]

[MrB]

Some old screenshots for posterity's sake:
http://web.archive.org/web/*/http://ahnews.music.salford.ac.uk/scribus/*

One of the original PPs: http://web.archive.org/web/20060526200503/http://ahnews.music.salford.ac.uk/scribus/docs/images/spec_gnu_100.png

[CGood]

I suspect the post I made the other day left people scratching their heads.

I am trying to sort out what controls - panels, dialogs, menus, or buttons - should control what. The question appears obvious and trivial, but logical structure tends to be economical and useful in the long run. Bad structure drags one down.

I want to get a clear idea of hierarchy - what are the most primary objects and properties, and what would be secondary objects and properties. What object or property subsumes what? I think that is clarified by asking what is the irreducibly minimal set of properties intrinsic to a given object? What is not irreducible? That all sounds academic, but it feels important.

[tim_occ]

CGood,

I think the UI should support both small and large screen sizes. Because you can have only large screen on a desktop, if you would travel by train you can't have a really big screen (if so it is unusual). If we want to give freedom to the designer to be work at his favorite place we should make the UI flexible.

I think such feature/tool hierarchy will help to clean the UI and to show only important things on small screens and more advanced stuff on large screens (if wanted).
In my visuals I was trying to apply a new kind of hierchary in UI. This layout based on my personal often used features / tools and on that what InDesign/XPress show in the property panel. I believe these guys made already such list of important features. Why not benefit from them?

For the hierachry of features I prepared a document. If you want you can add your thought there (or anybody else).
https://docs.google.com/document/d/17aFErWh8TnLeXW1q6U3KAzbKDODqnq7e0W8_T4_AvEo/edit#

regards
Martin

[CGood]

I apologize for my digressions on the hierarchy of objects and properties. My goal was to understand the nested Russian dolls of nature of program objects and object properties. But after all that, I don't think it revealed anything to me that everyone else didn't already know. My understanding just felt fuzzy and unclear. And I didn't feel like I could stand behind any hierarchical scheme of controls until the  big picture fell into place. I think Martin and GarryP probably everyone understood the big picture better than me.For what it's worth I post my scheme below. There will be no great revelations.

My perspective of the hierarchy of Scribus objects - from user level:

The objects one uses to build documents starts at the page level, and then below that are frames (and framelike objects - lines), and then below that live the contents.

In more detail:

1)     Top level - Pages - which can contain frames (and lines) - i.e. there are particular Page properties even when no frames exist. Page properties would be Number + Size >>>     Pages can contain frames or be blank

2)     Second level - Frames  - which can contain their kinds of contents - but there are frames properties even if there are no contents. All Frames have XYZ - Size - Location - Orientation - Layer - Level properties and while a frame with no contents is silly, it is possible and has frame properties.

3)     Third level - Contents of frames - in the case of text contents the immediate contents are text and paragraphs. Frame contents are particular to the type of frame.

                 Image Frames - Image Frame contents are image files and have particular image file rendering properties, i.e. scaling.
                 Text Frames - Text Frame contents are constructed from text and paragraphs and have particular types of text and paragraph properties. Text frames seem to be the most complex objects in Scribus. here is where breaking up elementary and advanced properties make most sense.
                 Shape Frames - Color/Fill/Stroke
                 Table Frames - Tables have their particular table types of contents properties.
                 Render Frames - Render Frames have their particular types of contents properties.
                 Lines are frame like - Color/Fill/Stroke and have their particular Line properties.

[CGood]

Martin says: "I think the UI should support both small and large screen sizes."

Agreed.

[cyberlizard]

this will be my first ever post.  It took me so long to read through the thread that it actually logged me out.

I am neither a programmer nor a designer, but simply an end user.  To be blunt, the current interface, particularly the properties tab is to put it politlely, dire.  To make sure I was not deluding myself, I showed my twelve year old the current properties tab (1.5.2) with the video mock ups Martin has produced.  I will let you guess what he preferred.  His comments were that the 1.5.2 properties tab was simply to big, with too many words and way to much wasted space.  He also had the opportunity of seeing the InDesign CS6 version that is on my windows machine and simply said, why can't it be like that... that is much easier to understand.

So on behalf of my son who has no axe to grind, I would like to ask, why can we not simply have two options to download, both the current (1.5.2) and the proposed Indigo style and let people decide for themselves which they prefer.

Many thanks.


Steve (cyberlizard)

[tim_occ]

Hi Cyberlizard,

thanks for your feedback. It is great to hear that you have tested the UI mockup with someone which is really fresh in this topic.

About the Indesign UI, I'm sure that we are not allowed to clone the UI. It is like Microsoft's Ribbon UI which is used in their Office suite. It is copyrighted / patented. Furthermore Scribus has some different settings as Indesign which can not easily fit into the same UI. A good example here are gradient options for fills and lines. Indesign doesn't support so much possibilities. That is the reason why we will have much more settings.

I think to have two different UI's makes no sense. The developer have to maintain both and from UX perspective it will solve only symptoms. A solution would be to fix the problem and to find one UI which fits to most users.

I can imagine to have a beginner and an advanced mode.

Beginner mode could be like MS Word to create basic layouts without any specialized settings like, micro typography etc. Could be work for professionals too to create a rough basic layout, and after switching in advanced mode the user can make all the specialized things.

regards,

Martin

[Eneen]

To make my notions a bit more concrete I have made an image that might help everyone visualize my thoughts.

Just a thought: with large displays you can make newspaper using two pages at once, so possibility to swap top-side would be nice.

[Eneen]

just an idea. Let's say we remove the text and property panel completely as separate panels from layout and put them in a fixed place. I analyzed a bit more Indesign and Quark XPress. Both have object and context related main properties on a fix place on top. All panels on right side in Indesign or XPress are used for other categories, like pages, alignment, layers etc.

As I remember, quark displays only part of settings on quick bar. To adjust more advanced settings you have to dig into options anyway. It will take lots of time and testing to select which options go there which don't. I like scribus approach where all controls are available so I see all my tools. Currently I only miss option to dock two columns of panels next to each other on the left or right side, so I have both text properties and properties open.
What I mean, that I like to see all settings that are connected to element then only part of.