Discussion:
[Scribus] a modest proposal on interface
unknown
2003-07-18 06:58:40 UTC
Permalink
Once again, congratulations to Franz, Paul, and all the other folks who
have made Scribus what it is. Not being a programmer, I can't help too
much in this respect.

What I can do is analyze the interface and usability of Scribus. Franz
has implemeted one or two of my ideas, but I have a whole series
waiting. I'm guessing others do, too.

What I propose is that we form an informal usability team to talk over
ideas on making Scribus easy to learn and easy to use. It's good now,
but it can be better. Please write me either off- or onlist if you are
interested.
--
Steve


PS: Sorry for posting three times in one evening.

PPS: Thanks to those who offered advice on my troublesome file. Sure
enough, it was corrupted during the upload. I've fixed it.

==
If elections are just something where you go in, you push a button,
and go home, then it doesn't make much difference which button you push.
- Noam Chomsky
unknown
2003-07-18 08:08:45 UTC
Permalink
Hi,

> What I propose is that we form an informal usability team to talk over
> ideas on making Scribus easy to learn and easy to use. It's good now,
> but it can be better. Please write me either off- or onlist if you are
> interested.

Let's hear what you're proposing on here before taking it anywhere else.

TTFN

Paul

--
Open your mind to a time where a company does not have control
Open your mind to a choice of applications which you can control
Open your mind from the closed world of those who seek total power
Open your mind to the wonderful world of Open Source
unknown
2003-07-19 05:30:56 UTC
Permalink
PFJ wrote:
> Hi,
>
>
>>What I propose is that we form an informal usability team to talk over
>>ideas on making Scribus easy to learn and easy to use. It's good now,
>>but it can be better. Please write me either off- or onlist if you are
>>interested.
>
>
> Let's hear what you're proposing on here before taking it anywhere else.

Okay. Lots of us have thoughts on how the interface/usability could be
improved on. I'd like to see a group talk about this and come up with a
Grand Unifified Plan, or a plan of some sort.

When I say improved, I mean that buttons and commands should be where
you'd expect them to be (which some are and some are not, currently),
objects should behave predictably, and configurations should be easy to
edit.

Here are some examples of things that violate expectations in Scribus...
- Line spacing is not tied to font size.
- Kerning jumps by an entire point when you click "up" or "down," which
is a huge amount.
- When I copy a box of right-justified text and paste it, the text is
left-justified.
- Linking boxes is not intuitive (simple, yes, intutive, no), nor is
there any way I know of to manifest the links between boxes.
- You can't drag an object across pages.
- Columns are terribly confusing. So is creating styles.
- Double and triple-click don't work.
- There's no "baseline" feature.
- Text attributes can only be applied to one paragraph at a time.
- And I have more (there's no "snap-to," grab boxes are proportional to
magnification, kerning doesn't show up accurately in Measurements, etc...).

Also, I've had throughts like reducing modality (i.e., the distinction
between text-box-create mode, box-move mode, and text-edit mode) by
making the cursor highly context-sensitive: a text-edit cursor when over
text, a move cursor over box frames, and a resize cursor over grab boxes
(this last is already in place). This would take almost no time to
learn, and would save substantial time and confusion.

Likewise, modality could be further reduced by eliminating the
distinction between text frames and image frames. There would simply be
a frame, and the conext menu would have two options: "Get text..." and
"Get image...", or better still, simply "Get content..."

Anyway, this is an explanation by example. Some folks will agree that
these are serious problems, other will not. These are the kinds of
issues I'd like to talk about - the problems we see, the solutions we
propose, and how to minimize the amount of code that needs to be
created/edited. All I propose is to group those of us who want to
address these issues, so as not to annoy those who aren't.

--
Steve
==
If elections are just something where you go in, you push a button,
and go home, then it doesn't make much difference which button you push.
- Noam Chomsky
unknown
2003-07-23 05:58:03 UTC
Permalink
Craig Ringer wrote:
> Hi folks
>
> I'm a relative newbie on the list, supporting a network of Mac Quark
> boxes at work. I thought I'd throw in my 2c...

At last! A response! :)

>> When I say improved, I mean that buttons and commands should be where
>> you'd expect them to be (which some are and some are not, currently),
>
>
> OK, an important question here IMHO: whose expectations?

Well, that's why I want to form a group - to decide exactly this kind of
issue. Otherwise, I'm stuck making the same complaints over and over.

What background
> of user are we talking about? I see several important classes:
...
> Each of these classes of user will have different expectations of the
> interface, to varying degrees.

Quite so. What I think is that we should set our sights higher - meaning
that we shouldn't seek to copy anyone, but rather come up with an
interface that's easy for anyone to learn. We should value simplicity
and clarity over anything else. The interface should, as they say, just
work.

> Then again, has it changed in a recent release? I
> could've sworn that issue went away last time I built and tried out
> Scribus.

Maybe in 1.0. I haven't had the time or the connectivity to try it yet
(which is pretty ironic, considering how excited I was about it).

> Then again, everything you mention does strike me as very generic DTP
> stuff, or simply logical, rather than 'but this is how XX does it' issues.

Well, I'm of the school that says copying commercial software is not
what open source is about. Rather, we should pick up good ideas wherever
they happen to come from.

>> Also, I've had throughts like reducing modality...

> That would be very nice IMHO. It could be good to keep a highly modal
> interface, since this is common in some/many existing DTP apps (Quark,
> anybody?). Personally I loathe it, and if Scribus's priorities don't
> include 'easily picked up by other DTP app users' then cool, just pull
> it. How hard would it be to leave in though?

With modes, there's you looking at your document as text, as potential
text frames, as existing text frames, as graphic frames, and so on. Each
has buttons and settings associated with it. With few or no modes,
there's just you and your document (and buttons and settings that act
directly on it). What that means is that there is less learning
involved... and you can get right to work.

We'll know we've succeeded when it doesn't matter what, if anything,
people were used to before they found Scribus, because Scribus doesn't
take any getting used to.

>> Likewise, modality could be further reduced by eliminating the
>> distinction between text frames and image frames...
>
> I like :-) I've never really understood why DTP apps do this

Franz?

--
Steve
==
If elections are just something where you go in, you push a button,
and go home, then it doesn't make much difference which button you push.
- Noam Chomsky
unknown
2003-07-25 03:17:25 UTC
Permalink
If there is a group UI Design Group formed please let me know, I would
love to be one of the people in the group.

Thanks

Gary Glasscock
Associate Editor
ACM Crossroads Magazine
http://www.acm.org/crossroads



On Wed, 2003-07-23 at 01:58, Steve Herrick wrote:
> Craig Ringer wrote:
> > Hi folks
> >
> > I'm a relative newbie on the list, supporting a network of Mac Quark
> > boxes at work. I thought I'd throw in my 2c...
>
> At last! A response! :)
>
> >> When I say improved, I mean that buttons and commands should be where
> >> you'd expect them to be (which some are and some are not, currently),
> >
> >
> > OK, an important question here IMHO: whose expectations?
>
> Well, that's why I want to form a group - to decide exactly this kind of
> issue. Otherwise, I'm stuck making the same complaints over and over.
>
> What background
> > of user are we talking about? I see several important classes:
> ...
> > Each of these classes of user will have different expectations of the
> > interface, to varying degrees.
>
> Quite so. What I think is that we should set our sights higher - meaning
> that we shouldn't seek to copy anyone, but rather come up with an
> interface that's easy for anyone to learn. We should value simplicity
> and clarity over anything else. The interface should, as they say, just
> work.
>
> > Then again, has it changed in a recent release? I
> > could've sworn that issue went away last time I built and tried out
> > Scribus.
>
> Maybe in 1.0. I haven't had the time or the connectivity to try it yet
> (which is pretty ironic, considering how excited I was about it).
>
> > Then again, everything you mention does strike me as very generic DTP
> > stuff, or simply logical, rather than 'but this is how XX does it' issues.
>
> Well, I'm of the school that says copying commercial software is not
> what open source is about. Rather, we should pick up good ideas wherever
> they happen to come from.
>
> >> Also, I've had throughts like reducing modality...
>
> > That would be very nice IMHO. It could be good to keep a highly modal
> > interface, since this is common in some/many existing DTP apps (Quark,
> > anybody?). Personally I loathe it, and if Scribus's priorities don't
> > include 'easily picked up by other DTP app users' then cool, just pull
> > it. How hard would it be to leave in though?
>
> With modes, there's you looking at your document as text, as potential
> text frames, as existing text frames, as graphic frames, and so on. Each
> has buttons and settings associated with it. With few or no modes,
> there's just you and your document (and buttons and settings that act
> directly on it). What that means is that there is less learning
> involved... and you can get right to work.
>
> We'll know we've succeeded when it doesn't matter what, if anything,
> people were used to before they found Scribus, because Scribus doesn't
> take any getting used to.
>
> >> Likewise, modality could be further reduced by eliminating the
> >> distinction between text frames and image frames...
> >
> > I like :-) I've never really understood why DTP apps do this
>
> Franz?

---
[This E-mail scanned for viruses by Mail Server Anti-Virus]
unknown
2003-07-25 06:58:45 UTC
Permalink
Hi,

> If there is a group UI Design Group formed please let me know, I would
> love to be one of the people in the group.

There isn't a group as such, generally everything to do with Scribus is
discussed on here.

TTFN

Paul

--
One OS to fool them all
One browser to find them
One email client to bring them all
And through security holes, blind them...
unknown
2003-07-29 02:54:31 UTC
Permalink
Ok, there's me and Steve Herrick, but who is the third person of this
group?


On Fri, 2003-07-25 at 10:54, Steve Herrick wrote:
> Gary Glasscock wrote:
> > If there is a group UI Design Group formed please let me know, I would
> > love to be one of the people in the group.
> >
> > Thanks
> >
> > Gary Glasscock
>
> Three constitutes a group in my book. If more want to join us later,
> that's great. If either of you is short on time or interest, I'll
> understand.
>
> I was reviewing my Jef Raskin recently, and I was reminded of one his
> principles: A well-designed interface does not need to be divided into
> "beginner" and "expert" subsystems. To me, that indicates that Scribus
> should equally understandable to users of PakeMakers, InDesign, and
> Quark, and people new to DTP. It should be as accessible as it is powerful.
>
> Being modeless should be a goal (Raskin again). It's possible this could
> be disconcerting, however, as it could mean doing away with the idea of
> having an active frame or a selected object. High context sensitivity
> should be able to more make up for this with the convenience of acting
> on an object directly with no thought for selecting it first or choosing
> a tool (mode).
>
> Here's an example of what I mean by that. Say there's a frame with an
> image in it. Clicking and dragging grab boxes crops it (for the moment).
> Left-clicking a grab box presents a contextual menu with two options:
> "Use to resize image" and "Use to crop image." Mousing over "Use to
> resize image" activates a submenu: "...with frame aspect ratio" and
> "...with original aspect ratio." Choosing one of these means you've
> applied two decisions with no tool selection, no menu selection, no
> object selection, no searching about for settings, a single click, and
> minimal mouse movements. Click and drag the grab box to resize the
> image, then click and drag the frame border to move it - no switching
> tools. Almost every click and movement acts directly on the document.
>
> Here's another example, in text. I like how InDesign handles columns -
> as an attribute of a text frame, not a page. So, left-clicking in text
> could bring up a menu including a Columns option, with the following
> suboptions...
> Number -> One more (unavoidable pop-up asks for gutter width; column
> width is 1/x of the remaining frame width) [ | One fewer (only visible
> if there are multiple columns already)]
> Widths -> Even | Uneven (pop-up asks for column widths)
> H Balance -> Yes | No
> (Things would be even more streamlined if only changes were offered:
> Make widths uneven; Balance columns horizontally.)
>
> Left-clicking would only change text attributes (font, size, color,
> linespacing, style, etc.) if the text were selected. Otherwise, the
> options provided would act on the frame (columns, border, select
> (paragraph | all text in frame [ | all linked text]), X flip, Y flip,
> widows, orphans, etc.
>
> Another thought is to have mousing over make things "light up" if they
> are left-clickable. This would eliminate guesswork on the user's part.
> It would also all the user to click "through" layers (acting on elements
> completely beneath other elements without altering the order).
>
> I haven't had time to apply this approach to everything in Scribus, but
> if you think it makes any sense, I would try. The idea is to smooth the
> learning curve - it might take you a second to figure it out, but it
> immediately becomes second nature. Hopefully. I accept that it won't
> always work (like with precise numbers), and I realize this is a fairly
> big change, but I think it just might be better. Let me know if you
> think I'm nuts.

---
[This E-mail scanned for viruses by Mail Server Anti-Virus]
unknown
2003-07-29 04:24:56 UTC
Permalink
Gary Glasscock wrote:
> Ok, there's me and Steve Herrick, but who is the third person of this
> group?

It's Craig from Australia, but maybe he's not interested after all.

I had meant for that message to be off-list, but if it strikes a chord
with anyone, I'm trying to create a UI group. I'm currently developing a
fairly detailed proposal along the lines of what I wrote before. It's
already gone through several iterations, and may go through one or two
more before I present it. Its major problem right now is that it's not
very keyboard friendly.

--
Steve
==
If elections are just something where you go in, you push a button,
and go home, then it doesn't make much difference which button you push.
- Noam Chomsky
unknown
2003-07-29 14:57:16 UTC
Permalink
On Mon, 2003-07-28 at 20:24, Steve Herrick wrote:
> Gary Glasscock wrote:
> > Ok, there's me and Steve Herrick, but who is the third person of this
> > group?
>
> It's Craig from Australia, but maybe he's not interested after all.

I'm a Scribus newbie (Page Layout newbie, in general), but I would like
to help out on this one. Perhaps the opinions of a DTP virgin would be
useful. :)
unknown
2003-07-31 05:35:53 UTC
Permalink
I have my own domain so I could setup a listserv there if need be. I
agree though on the suggestion to see about getting one from the same
place as the Scribus listserv.

Gary


On Thu, 2003-07-31 at 00:58, Steve Herrick wrote:
> Gary Glasscock wrote:
> > Steve, there is a bit of a problem, I think anyway, with creating a UI
> > as you suggest. For one, there are standards that need to be followed
> > when implementing a UI, no matter the platform used. With this in mind,
> > I think that our group should concentrate on enhancing the present UI
> > and making sure that it stays well within the standards set forth for
> > KDE/Gnome. I know that this is probably something that you didn't want
> > to hear, however, I felt compeled to point out the standards issue.
>
> No, it's OK, I'm open to criticism. Frankly, I never expected the
> near-modeless idea to catch on. I wanted to present it, however, partly
> as an academic exercise (basically to see if I could do an entire UI
> that way - it's probably 75% done), but more as a blue-sky model to
> orient us for the future. The more I read Jef Raskin, the more I like him.
>
> > Basically, the way I see it, your proposal is a very good one, however,
> > it is a bit advanced and more to an extreme departure of the standard
> > UI. I think your proposal would be better served as a proposal for
> > changes to the current UI standards that are already in place, and not
> > in a singular program as yet.
> >
> > This is my humble opinion of the matter.
>
> I'm not up to proposing new standards to the entire open-source
> community - it's all I can do to stay afloat when people start talking
> techie on this list.
>
> That said, a lot of my ideas could appeal to people if I drop the idea
> of never selecting anything. I'd prefer to keep tools (modes) to a
> minimum, but I could be convinced to meet somewhere between what we have
> now (many modes) and my ideal (no modes). If it were, say, three, I
> could live with that.
>
> This would allow us to consolidate palletes and make the contextual
> menu... well, more contextual. Even accepting some modes, there's a lot
> that can be done to simplify the interface. I propose this be one of our
> goals.
>
> > Gary Glasscock
> >
> > PS. any feedback on my suggestion to set up a listserv for our little
> > group?
>
> Could we arrange to get one from the same server as the main Scribus
> list? If not, I'll set one up at Yahoo.
>
> Note: I'll be on the road for the next week, so my email availability
> will be spotty.

---
[This E-mail scanned for viruses by Mail Server Anti-Virus]
Loading...