Thoughts on Workflow and Speed of Design Iteration

Previous topic - Next topic

NathanUp

I was just reading through this old thread where a user is struggling to select colors. This in combination with seeing the outstanding work on the UI that's being done on the SVN version made me think about one of my biggest wishes for Scribus: increased design iteration speed, or the ability to create and change designs quickly.

That speed of iteration is a big difference from working in something like Adobe InDesign, which I did for many years. With InDesign, I could very quickly create and iterate on designs using features like
  • the docked color wheel1
  • vector graphics in frames
  • linked vector graphics
  • axis-constrained dragging of images in frames
  • snap to bleed
  • more reliable snapping
  • dockable paragraph / character styles dialog
  • right click to update paragraph / character style
...and other little things that, when combined, enable the user to work at speed.

As a result, I would do much of my print design directly in InDesign, whereas now that I've moved to a FLOSS workflow, I have to create my initial design and iterate on it in something that has a much faster workflow, like Inkscape, and then I execute my finished design in Scribus so that I can have a reliably print-ready file. This isn't ideal because you can't really do this with longer documents, and when you do, you don't get the power of Scribus' text tools. Also, as a long-time print designer, I would strongly prefer to do as much of my design in Scribus as possible because it allows me to create precise, technically correct, and neatly set-up documents that are a joy to edit in the future (once the design aspect is complete), and I would of course prefer to only have to create my document once! Feature-wise, Scribus is wonderful, more than capable of good professional work, but the workflow speed is, I think, something that trips up many people.

At any rate, I just wanted to submit my thoughts and maybe start a conversation on the idea of "speed of design iteration" in hopes that my input as a design professional would be useful. I love Scribus and remain eternally grateful to the people who put their time into making it the power-house that it is, and I am very excited to keep following its development, and maybe one day, being able to contribute where I can!

---
1 When working on a design intended for 4-color process, I'll often just select random colors to play with, and then I can refer to a swatchbook afterwards and replace the color values with ones that look good in my swatchbook.
2 On that note, if anyone on the Scribus team ever wants to discuss workflow, have someone test a feature, or consult on a UI/UX matter, I would be delighted to help.
EndeavourOS | Down with Adobe!

a.l.e

hi nathan,

nice list!

a first reaction from my side:

  • the docked color wheel:
    martin is proposing a new widget for colors. would you mind discussing with him, a way to integrate the color creation in there? (you can open a ticket in the bug tracker or a topic in here...). personally, i'm not sure that a third colors dialog (a dockable one for fast prototyping) is the right way to speed up the color creation...
  • vector graphics in frames:
    see https://bugs.scribus.net/view.php?id=393 it would be nice to have somebody create a list of detailed feature (my pet feature would be to keep the imported colors inside of the frame and not pollute the document's colors list)
  • linked vector graphics:
    that's probably a sub task of vector graphics in frames... i guess.
  • axis-constrained dragging of images in frames:
    https://bugs.scribus.net/view.php?id=15560 ? if it's that please test the patch (if possible) and / or comment on its description
  • snap to bleed:
    scribus does snap to bleed...
  • more reliable snapping:
    what is missing for you?
  • dockable paragraph / character styles dialog:
    for editing the styles or applying them?
  • right click to update paragraph / character style:
    https://bugs.scribus.net/view.php?id=579 / personally, i'd prefer a button in the palette, rather than a context menu.
    i'm currently working on a proposal for the simplest use case: creating a line style based on the selection. if i get it to work, i'll propose it to martin and see if/how he can integrate it in his UI work. ()

it's not easy to get specific features to be added to scribus.

maybe, the best thing one can do is to comment on the patches that have been done and help the brave ones that do make patches to improve them.
and, when the patches seem to be ready, help convince the team that it's now time to review the code and give feedback : - )

sadly, creating conceptual UI / UX papers has only worked once in the history of scribus...
and it only worked because the persone having written the proposal got proficient enough in c++ to create a prototype of it and, then, step by step also programmed real widgets that can be integrated into scribus.
it took years, but it's one of the best things that have happened to scribus in the last many years!
(thanks martin for all your work!)

proposing small incremental feature that seem to be easy to implement has also sometimes worked.

Nermander

As for vector graphics in frames (and also linked), would it not be possible to implement as an extension of render frames? But the rendering engine would be an internal function instead.

(I have to confess that since I have never used render frames I am not sure they support linked content, but I think that would be fairly easy to implement.)

a.l.e