Scribus UI/UX improvements

[Kunda]

Agreed! This would be a welcomed change! Thanks Martin!

[tim_occ]

Hi together,

I'm still working on a new UI concept for Scribus, but I want to share some new stuff with you.

Short background story:
The foundation for the new concept is a deeper analyze of Indesign CC 2014, Quark XPress 2015 and Scribus 1.5.1. and the most often used tasks for DPT's.
The new Interface is more space optimized and gives the user more freedoms to create a custom workspace.
Feedback or improvements are welcome.

greets
Martin

PS: Updated Inkscape file with more screens is attachted.

[attachment deleted by admin]

[Kunda]

tim_occ,
So very cool! These have been posted to Scribus's Social media
Has anyone contacted you from the Scribus team ?

[GarryP]

This just keeps getting better.

If someone could convert this kind of thing into a usable UI it would help Scribus a whole lot.

My only - possibly - worthwhile comment would be to maybe not put too much faith in an analysis of how existing software works.

For a lot of applications, they do things the way they do because that's just the way someone originally programmed them to - a lot of the time the programmers aren't the users - and since then everyone has got used to it. Things often get put where they are because it was convenient for the programmer to put them there while writing the code.

On the other hand, asking the users what they want can be a nightmare. Ask two users what they want and you'll usually get at least three answers!

Please keep working on it though. If something like it can be implemented, that would be brilliant.

[tim_occ]

@Kunda,
I've seen it yesterday on the google+ account of Scribus. Thanks for sharing, maybe we can improve it together with a bigger range of the community. So far no one has contacted me.

@Garry,
the analysis helps me to understand the logic behind things. Maybe I found some weak spots in other DPT's and we can make it better 
My goal is it to create an intuitive UI. The user should not think: "Meh! where can I find this function?" The user should think: "Ah, there is it! As I supposed."
It's a hard goal but let's try!
I think in good and simple user interfaces contains plenty of brain power. And I also think that about the user interface of InDesign and XPress. So why not benefit from it.

But yes, in the end could it be wasted time. I stay tuned.

Martin

PS: I think I have to learn working with GitHub

[tim_occ]

So, there is a new update.

I've completed the basic concept and I've defined some general design standards/rules for a consistent UI for Scribus. Have a look to the new screens.
Further you can find the UI-Mockup presentation here in this Google Slide:
https://docs.google.com/presentation/d/1M6R4ggFbgU1EXbWiL8hwppyQJhsNnUlw7_7rOA3Im1Q/edit#slide=id.ge4506b4e5_1_16

It's containing a short comparison between Indesign, Quark Xpress and Scribus and additional descriptions to the mockup screens and features.

I hope you like it.

Martin

[attachment deleted by admin]

[a.l.e]

i went through your document and i like it!

very clear and good visualisation.

some thoughts from my side?

- there is an idea floating around about separating the content part of the properties panel (which would be context sensitive) and the frame panel (which would contain the maniputations for the frame)
  - what do you think about it?
  - would it fit in your thoughts?

- how can we get to a specification (with no reference to non free software, if possible!) for the new UI?

- how can we make that code is programmed for it?

[GarryP]

A lot of good work done there Martin. Nice job.

I'd like to add a few comments (some of which I might be repeating from other posts).

1. Scrolling

I think the amount of "stuff" in any panel - for example, "Properties" - is important and can greatly affect how software is perceived and used. More specifically, the more scrolling the user has to do to find things in a panel the less professional it feels to the user.

To someone looking at the software for the first time it might look like there's loads of options for them to play with but in actual use it becomes tiresome to have to keep scrolling up and down to get where you want.

For example, in the Properties/Text tab, if you have a few of the sub-tabs open - unless you have a very large monitor - you have to scroll up and down to find the thing you want, e.g. Colour, Style, Columns, Advanced, etc. (See the image I posted earlier in this thread.) This can also have the effect of the user inadvertently making changes with a scroll wheel if the pointer happens to be over a control that accepts scroll wheel input. (Also, this sort of inadvertent change can be difficult to track down if you weren't watching.)

It is better to keep scrolling within panels to a minimum. By way of two examples, if you look at GIMP and Blender you will see that their controls are arranged in such a way that the user - even on smaller screens - has very little scrolling to do no matter where they are in the control panels. There are more panels to click between but they are each small enough to fit on the screen without scrolling. This can give the user a much better experience.

2. Content/Frame Split

I would be generally in favour of splitting content properties from frame properties as long as it was done well. (Even now, after using Scribus for a few years, I still find myself - every now and again - going to the Colours tab to change the colour of text. Stupid I know but my brain thinks "colour" and automatically moves my hand to point to the "colour" tab which is always visible.)

My main concern with this would be implementation. For instance, "XYZ, Shape, Group, Line and Colours" are all frame properties while "Text and Image" are content properties. So how would the two things be split? How would putting them in separate tabs in the same panel affect the UI? Would there be two separate panels instead? How would that affect screen space if they were side-by-side? If they were one-above-the-other that might cause major scrolling issues. Would a context-sensitive toolbar - as in Inkscape - be a good option instead? This would need a lot of trial and error which - I'm guessing - the developers won't have time for.

On a related note: How easy would it be for someone to put some kind of non-functional properties UI together that people could mess around with in Qt? I've no idea how much time this would take but it could help more people be involved and might allow for a quicker solution in the end.

3. Compression

I think the road Martin is going down is correct with a "compression" of the controls within the panels. At the moment, Scribus is quite "newbie-friendly" with lots of space and long control names/descriptions but it makes for a lot of unused screen real estate (and tool-tips are usually available to give more explanation).

For example, in the "Shape" tab, the "Disabled, Use Frame Shape, Use Bounding Box, Use Contour Line, Use Image Clip Path" options could all be compressed into the space of just the first two by putting them in two columns and omitting the un-necessary wording, e.g. "Disabled, Frame, Bounds, Contour, Clip Path".

For an example of a good lean UI I always point to the GIMP Toolbox. The toolbox and toolbox options give the user a whole lot of control but manage to fit all of that into two panels which can sit unobtrusively to the side of the main window. I haven't counted but I'm fairly sure that GIMP puts way more tools and options into one small double-panel - which seldom needs to scroll even on smaller screens - than Scribus puts in one panel that needs a lot of scrolling.

I realise that a toolbox isn't the same as a properties panel but the same sort of layout design could be used.

Getting a nice UI that is both streamlined and easy to use is difficult but any improvement would be good.

[tim_occ]

Hi together,

I like the idea about a splitted Property windows. If we separate the content Property from frame properties we have some options:

• create a second Property window that contains text and image settings (might be grouped in tabs as seen in my mockup)
• create two single windows

But I think in every case it should be context sensitive.
For Text:

• by double click on text frame show Text Property window (probably the user want to edit the text)
• get focus by press F3

For Image:

• by double click on image frame show Insert Image Dialog if image not set
• by double click on image frame show Image Property window (probably the user want to edit the image) if image already set
• get focus by press F4

@Garry
I have caught myself as I wanted to set the text colour in the colour window. I think it's a good idea to merge both colour settings. See in the attachment the new version of colour tab. It should be also context sensitive. That means if a text frame is active the text colour widget is shown additionally. In other cases it's hidden.

In general, the Property window will be reduced by two tabs (text and image).

@a.l.e
Did I understand you right, you are searching for instant libs? I made a short research about it, but I doesn't found useful stuff. Further I checked the Qt board widgets, I think it's necessary to create a custom widget.
I think for tabs in Property window it can be used the Qt TabBar. The tab bar allows to reorder single tabs and supports icon only labels. Contra: the icons are rotated by 90° for vertical tabs.
However in my opinion the important part is to clean up the single windows (panels) at first, like Property window. After that it can be implement the new docking widget (or we have to find a better solution).
The DockingWidget supports vertical tabs but only with text labels. Also it's not possible to move a stack of grouped panels to another place. I found in Libre Office Writer a good solution for grouped panels in an icon bar but it's only one window and the user can't split the single panels from parent window.

[attachment deleted by admin]

[Kunda]

Fantastic!
Posted your mockup updates to social media:
Twitter
g+ scribus page and g+ scribus community page

[morgajel]

I was glad to see the comparisons with work-alike programs. UI is one place where Scribus could use some help. Just remembering which panels were left open would be a welcome change (I'm looking at you, text panel- Stop closing every time I click on something else, then return back to my text area!)

While I know Scribus is not a text editor, text formatting (specifically applying styles, bolding, and italicizing) is a big part of my usage and I'd love to see it streamlined.

[corebots]

Great to see these designs, and the study behind it! however, to me there is still a lot of 'gray-space' between some elements, and the panels especially - some panels could be combined, or perhaps made 'semi panels' so they don't stretch across the whole side if they're not populated completely with icons/controls? it's just I don't like a panel taking the whole screen-side with only a few icons on it and a lot of empty gray space.. also, all the borders could be like max 1pix wide keep up the good work! and please implement asap.

[cloudbusting]

I just registered to say how great this is  Excellent work! I'm dying to switch from Adobe completely at some stage. I just hope these features make it through. How likely is it that this will be adopted for 1.6.x?

[tim_occ]

Hi Guys,

I finished first version of the Property panel designs. See the whole set in attachement. I named the new UI Indigo UI. Becasue, it's a blue color like the main color of Scribus and it contains the word "Indi" the abbreviation for "independent".

While my spring-cleaning I removed the group tab. I think it's not needed all settings already available in Shape and Transparency tabs. Furthermore I separated the Text and Image tabs of Property panel in to single panels (content editing). These reduction of tabs in the property panel (frame editing) save more space in smaller tab views, like Shape Tab.

What else? I've created a Full HD view of the new UI to see unused space... some elements needs an optimization. Perhaps should the Property Panel completely split in to single panels. What are you think about that idea?

@cloudbusting
I think if we can finish the UI details and someone of the dev's grab these ideas it's possible to implement this in Scribus 1.6.
The other question is if the majority of the community vote for this new interface. But I think yes if I read the current feedback

Otherwise Scribus 1.5 got already a new panel docking extension. And it's to much to rework these again. But Panel clean up should be possible (and is neccessary).

Let's see

Martin

[attachment deleted by admin]

[cloudbusting]

Great work again, Martin!

I agree that the properties panel should be split for each section. It would make more sense; some users/designers may never need to use a particular property, so it would allow more space to view the doc if split up.

And yes, it's much needed. I'm new to Scribus, so perhaps users that are unfamiliar with other software don't see some of the hindrances. But a clean UI like this with minimal fuss and mazes of menus to get through would be much more useable. Especially when working on a large project where the same tools are used again, and again.

Who do I have to sleep with to get this implemented?