[Scribus] Usability needs attention -- time for a feature moratorium?
Sun Jan 27 09:40:18 CET 2008
Hedley Finger wrote:
> For example, you cannot copy from the layout and paste into the
> Scrapbook but must right-drag. (When was the first Macintosh released?)
I found this one odd myself. Normal left D&D would also make sense, but
right-drag is a very unusual UI action.
Some of this stuff is a holdover from very early Scribus releases. The
dev team *are* improving the UI, tidying up odditities, fixing up
performance problems, etc. Given how few people work on Scribus, many
with limited time, they're getting plenty done. However, there's a huge
amount to do. Additionally, changing something in Scribus is often a lot
harder than it looks, since some of the code is very tangled and
arranged in strange ways. This means that a "simple" UI change can
actually involve many changes across significant parts of the code,
some of which can be hard to track down or can also affect other
things. It can sometimes require significant internal restructuring or
redesign to implement what looks like a small change in behaviour.
Additionally, as Craig Bradney noted there are some changes that must
wait for the qt4 transition to be practical. 1.3.5svn is using qt4 and
fixes to make it more stable and better behaved are progressing, along
with plenty of internal cleanup work to make future changes and fixes
more practical. With luck, as the cleanup work progresses Scribus will
become easier and quicker to improve and fix.
The other thing that would be helpful is usability testing. It's all
well and good to say "but product <x> does it like this" ... and to an
extent that can be useful. If almost all other apps do it a certain way,
Scribus probably should too unless there's a reason to do otherwise.
However, sometimes it's not that clear, and there's no one common way to
handle a task. In those cases, real usability testing - with different
approaches tried out and the results observed - would be helpful in
deciding what the best way to handle something is.
> If you do something in a palette or dialogue which changes an object,
> you would think that Ctrl-z would restore the previous state but more
> often than not, the key event is not trapped by the palette/dialogue
> with focus but goes through to the layout/canvas/window where it
> undoes some OTHER state.
Undo support is incomplete, at least in 1.3.3.x . An action that isn't
recorded as undoable may have no effect on the undo system, causing the
previous undoable action to be undone when you wanted to undo some more
recent action the undo system didn't record. I think there's been some
work in 1.3.5svn on this, but I'm not sure what/how much.
IIRC some improvements to undo were also waiting on other fixes and
cleanups to the core Scribus code.
> The serious point I am trying to make is that perhaps it is time for
> a moratorium on feature building for a point release or two while
> usability issues are addressed, especially implementing orthogonality
> across objects and controls.
[Note: I've been inactive as a developer for a long while now, so I
hardly speak for the team; then again, I'm not saying anything unusual.]
That's where comprehensive UI review and usability testing (by people
who have usability testing and UI design experience) would be helpful.
If someone goes through the app and can say things like "task <x> is
done this way in dialog <a>but this other way in dialog <b>" ... that's
handy. If they can further say "<list of apps or platforms> do it this
this way; <other list> do it this way. Our tests suggest that a random
user sample with experience in none, either, or both platforms/apps find
the first way easier to use on average" than that's even more handy.
What doesn't help much is just saying "this UI element should work like
this instead" or "<app x> does it this way, so Scribus should too". In
other words, attention to detail, comprehensive coverage, and testing is
needed to make truly useful decisions about UI issues. Even if the
problem is pretty obvious, the right solution often isn't .
Of course, just knowing what needs doing doesn't make it happen, and as
I said earlier sometimes apparently simple changes are a lot harder and
more time consuming than they look.
As for a moratorium on features .... the 1.3.5svn branch is largely
focused on cleanups, fixes, qt4 porting, and architectural improvemetns
as it is. Have a look at the svn logs (you can get them using an svn
client on anonsvn) and you'll get some idea of what's going on in
development. There has been feature work but much of it is contributed
by people who've become involved specifically to work on that feature,
like the Google Summer of Code folks.
Such fixes and cleanups are really slow and tiring work, and it's work
that often feels unrewarding since it usually feels like there's just
more of the same waiting for you. That's part of why I'm largely
inactive in Scribus development these days - I find that I lack the
patience and dedication to spend weeks struggling to understand, clean
up, and document a large section of code in order to make it possible to
make the changes I truly want to work on. I really enjoy cleanup and API
design work at a certain scale, but find that often what's needed to
work on Scribus exceeds that scale, with fixes on on one area demanding
changes in another and so on throughout much of the application. So ...
don't knock the efforts of the folks working on said cleanups and fixes
(not that you were). It's seriously hard work, and the results they're
producing are becoming pretty impressive when you compare the code of
two years ago to the code today. Volunteers for that sort of work aren't
thick on the ground, either.
More information about the scribus