Thoughts on Workflow and Speed of Design Iteration

[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 wheel¹
• 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!

---
¹ 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.
² 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.

[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]

0017144: PATCH: ctrl: move image orthogonally inside of the image frame
https://bugs.scribus.net/view.php?id=17144

[NathanUp]

Sorry about the delay in response - I meant to get back to this and it just didn't happen.

martin is proposing a new widget for colors. would you mind discussing with him, a way to integrate the color creation in there?

Sure, I'll open a new topic.

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)

What sort of things do you think ought to be mentioned? IMO it ought to work just like raster images in frames. I agree with you on the colors list.

linked vector graphics:
that's probably a sub task of vector graphics in frames... i guess.

Yes, I suppose so. Now that I think of it, an option to link or embed (convert to Scribus curves) would be useful. I suppose a big hurdle here might be the lack of a good QT SVG renderer (Like KDE is dealing with when generating SVG thumbnails for dolphin). Linking is imminently useful because you can open end edit with your preferred vector editor, save, and the linked SVG updates in Scribus)

https://bugs.scribus.net/view.php?id=15560 ? if it's that please test the patch (if possible) and / or comment on its description

No, what I meant was something like this: When moving an image inside of its frame, you can hold shift / ctrl / whatever key to constrain image movement to only the x or y axis. That way, if you have already positioned an image vertically, you can hold a key and drag it horizontally only without losing the vertical position.

snap to bleed:
scribus does snap to bleed...
more reliable snapping]:
what is missing for you?

Since writing my original post, I have upgraded my system to Plasma 6 (and thus, wayland). I haven't experienced any weirdness with snapping since, and the framerate when dragging items seems much improved also.

dockable paragraph / character styles dialog:
for editing the styles or applying them?

It would be nice to have a panel that displayed a list of styles. From that panel, the user could make a new style (this could open and use the existing styles dialog), apply a style to either an entire text frame or selected text, clear style overrides from text frames / selections, delete, duplicate, and rename existing styles. To be honest, this functionality could even be incorporated into the text properties panel.

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.

Yea, now that I think about it I agree with you on that one.

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.

This will make a big difference in speeding up workflow! Having to directly set up styles in the styles dialog really slows me down when I'm just trying to play around and see what works before committing. (Of course, I know that I could play around anyway, but I'd just have to duplicate all of that work in the styles dialog)

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

Yea, I'll need to explore Mantis a bit more. I'm used to other platforms and I find it quite difficult to search through Mantis.

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

YES - I'm doing a lot of work in 1.7.0SVN from the AUR at the moment (yea, I know I shouldn't haha); what an amazing difference! Scribus really is becoming not only capable, but a joy to use.