Author
Topic: Scribus UI/UX improvements (Read 44003 times)

Martin, Very cool! some feedback: in order to get the extended view one has to click on the small arrow which is a very small target...for ease of workflow, can we extend the area of the un/collapsing function along the whole head of the panel instead ?

Hello all especially TIM_OCC,these ALL layout designs looks GREAT!!! I must say that Scribus needs UI redesign MOST OF ALL features planed because original UI is TOTALY COUNTERINTUITIVE!!! I wonder how such a UI DISSASTER could be created in this century

well, if you have seen the scribus code and have an idea about how UI decision are taken, i think it's not that hard to guess why the scribus UI is not as good as it could be (ehm ehm ehm).

- as a programmer you create a feature as a prototype. and the hardest part is to get all the edge cases right. a basic UI is enough: we can improve it later. and later is... well... later

- when the programmer does not use the product (much), he will have a hard time doing the right UI decisions. imo, the worst offenders in scribus are the choices done by completeness (there are a few features that are completely useless, but they have been added because theoretically it's the same as other features that are useful).

- in the same spirit, if you create something, which is in a similar part of code as something else, you will put it next to that one in the UI. exposed in a similar way. there is nothing that could possibly go wrong. or not?

- finally, when many people have complained about how ugly the interaction is, the programmers somehow gets it, that it's time to do some changes. but there are already so many wires behind the scene that would have to be changed, that we will do that when we do that planned feature (which needs a new UI). of course, the planned feature will take much longer to get out of the planning stage...

ah, then you will have all those user complaining because you have changed something and now they cannot keep thy crazy habits (that were needed because the UI was terrible... but now they are used to it and produced workarounds they can live with).

so: it takes much effort to create a good UI. and, sadly, we have too few people, who care about a good UI and -- at the same time -- have the patience to stay on it for a couple of years and make things change.

but one such person is here and with a bit of luck (after many months of efforts!) we will see a big improvement soon!

p.s.: the considerations above are not specific to scribus but apply to many projects where UI is a second class citizen... and there are many such projects, not only in the open source world.

When I started to learn to use Scribus I believed Scribus had a larger and faster moving development team than I now see. I could see no good reason for the large number of UI errors I kept falling over, many rather basic.

But, now that I know the team is small relative to the task at hand, several responses seem appropriate and I have adjusted my expectations from "smooth sailing" to "I can probably sort out a workaround".

After reading here and elsewhere that many substantial UI issues persist for a very long time, and seeing them remain, I think the Scribus website greatly over-promises, and then Scribus under delivers. That is not to say Scribus is not very capable, but that by setting user expectations far too high, the real Scribus can only deliver disappointment. That is a bad outcome in several ways. It must drive potential users and contributors off so soon that they give nothing back. No money, no feedback, no code...

Over-promising is easy if you already have discovered the workarounds and the features to avoid. Easy if you are familiar and know the neighborhoods to avoid. How many potential users have left when utility just wasn't there or difficult to find, and badmouthed open everything?

I wonder if it would be good to disable - just grey out - weak functions that have better implementations elsewhere in Scribus. Things like styles are a mess to create and use. (Yes, I have figured them out, but only because I fell across the answers by mistake) Can we just kill off thestyle drop downs in the story editor since they seem not to do the job? Much more experienced users than I seem to say that the story editor is a chancy tool and that if you can avoid it, it is usually best. Since the documentation seems to laud the story editor, it took me a while to start avoiding it.

Darn it, Scribus IS a worthwhile project. I find myself getting fluent and choosing it for more and more tasks. It deserves better PR, better documentation, and a more unified UI. The issues I am running into are probably driving away money and public support. Adjusting user expectations lower might help.

I think we don't have to talk about that Scribus needs a new UI, and many reworks for usable workflows. But there is to mention that the Scribus project is not developing by a high paid developing team which can work more than 8 hours per day on it. It is made by free developers which can work only in their free time. It is not like Blender or Ubuntu which have a company behind to pay for developers to work on it.I started these UI project in early 2015 - more than 1,5 years ago and it is not done yet. The reason why I did it is really simple. I wanted to work efficient with Scribus and was more busy to handle the UI than work on my projects. So, Scribus has great features but mostly unusable in daily professional work. However thats not new, but we are working on it. Not fast as could be but we do our job.

I think Scribus is in a vicious circle. Less people are interested in because of bad usability, but without a bigger community it is hard to find developers / designer which will/can work on it. You can have the best product, but with bad ads or a bad packaging nobody want it (I think only Amazon have success with bad user interface ). Ok, I believe if Scribus would have a great UI the community will grow fast and will pull more contributors in the project.

However, at the end some good news. I could implement the whole IndigoDock in Scribus but I'm currently fighting with some compiling issues. If I have more progress I will let you know it

can i suggest you to recreate the repository as a copy of the current github code and make your changes a "public" commit?currently, i have the feeling that some of your changes are already in the initial commit...

the idea is that each commit has meaningful title and introduces a "single" change. in that way one can have a look at the commits and understand what you have changed and you don't need to write down everything in the readme.

a summary of the changes in the readme is of course useful, but you can keep them shorter and reference to the relevant commits.

thanks for the hints. I have updated the repository. Now, there is only one inital commit with origin Scribus files which can be compiled and there is a second commit with IndigoDock integration which can't compiled.