[Scribus] Usability needs attention -- time for a feature moratorium?

[Craig Ringer]

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.

--
Craig Ringer