[scribus-dev] Who is going to kill the style dialog ?
louis.desjardins at gmail.com
Mon Nov 1 04:44:46 CET 2010
2010/10/31 Alexandre Prokoudine <alexandre.prokoudine at gmail.com>
> On 10/30/10, Louis Desjardins wrote:
> > Can we simply get rid of this dialog and have the style created at right
> > hand click ? Bug 300 or so by Lyam, back in 2004 or something.
> > Please do us a favor and kill this dialog.
> Unfortunately this is exactly where you are to be reminded that I'm
> subscribed to this list and therefore have many amazing ways to annoy
> you :)
> The big issue as I see it is that UI of Scribus is a patchwork.
> Everybody wants to make this app rock. Sadly, this is not enough. Yes,
> in an ideal world little elves would take a vacation from Santa's
> factory to do the work for you. In the real world Santa's factory is
> called Adobe and all the elves are slaving away for it 24/7/365 and
> are jolly glad to do so.
While I agree that at some point we need a critic mass of people working
together on a vast project in order to achieve large work, I do not think
that the resulting work is going to be better only according to the number
of people working on it but rather it’s the quality of the work of a few
people that is going to clearly make a difference. But I guess we can agree
on this easily. :)
Adobe can be wrong. I hope we agree on this.
> So you've got that extra bit of work that is
> called "spending all our spare time on unpaid project only to be
> annoyed by some clever wannabe-usability dick who never wrote a single
> line of code" :-)
> We've just had a hot discussion at #scribus,
If you have a mean to send us that discussion, I will gladly read it.
> and I'd like to reiterate
> that before any further changes to UI are made, the team should take
> one step back, look at the whole thing and come up with a new design
> for UI. When I say "should", I really mean the nasty heartless
> attitude towards people who work on the project in their spare time
> :-) And when I say "design", I don't mean icons on buttons (whose
> style is eclectic again now that new Render Frame icon is introduced),
If only this Render Frame could work on a Mac...
> I really mean design as in God-like "thoroughly analyzing things,
> constructing bones and adding them some meat and muscles and only then
> -- the skin and, finally, make-up". (Not that your basic god is
> expected to approve make-up in principle, but I digress.)
> Let's agree that before things get implemented they should be analyzed
> for whether they are going to contribute to consistence of user
> experience. Whether they will provide the fastest way to get the job
> done. And so on and so forth.
Well... I have to say here that IF we would have applied and followed that
rule in the last years, many (not so great) ideas would not have make it so
easily into the Scribus code and UI. The fact is that the coders themselves
can do most anything and if they don’t want to care about the others’
advice, they simply can do without it and go their own way.
> Here is a couple of main principles I can come up with while I'm still
> awake that should be used as reference whenever you start coding
> 1. In typography everything is experiment (therefore all aspects of
> layout and typesetting can be changed at any time, on the fly).
> 2. In a document and between documents everything is reusable
> (therefore any kind of objects can have styles and be cloned).
> 3. Every change can be undone within same session, and as many changes
> to shape and look of objects as possible are non-destructive.
> 4. The way to get the job done as fast as possible is to focus on
> content, not ornaments (therefore modal dialogs and sidebars are
> weapon of last resort).
Actually, to get a job done quick is to be able to apply repeatedly on large
chunks of texts and pictures and other graphic elements the desired settings
that were previously set in intensive try-and-error sessions. Once those
settings are settled and even if they have to change after, closer to the
deadline or on the deadline even, we need powerful enough tools to achieve
this. So, focusing on content will never be enough.
And this is exaclty why I say that in this particular case of styles we
should not need any further interface than the one we already have in front
of us: the actual page! Why an extra dialog is beyond me.
But as you mention it further down in your post, getting past the habit of
living on trees is difficult for most of us... :)
I don’t buy the "habit" argument either, as you have understood.
Please don’t unsubscribe.
> In my anything but humble opinion it's rather pointless discussing any
> details until things like this are understood, agreed and settled. A
> special remark for Christoph: I know you still want details, but you
> won't get any until the first stage is passed. Also, note how
> following those would shape the long-suffering document format in
> certain ways already.
> Oh, by the way, I've already heard the
> but-people-have-different-habits argument. I don't buy it. We'd be
> still living in rainforests on trees if we all sticked to our habits
> as if we had nothing better to stick to.
> And now you unsubscribe me :-)
> Alexandre Prokoudine
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus-dev