[Scribus] Look and feel

[Craig Ringer]

Roger wrote:
> It amazes me that look and feel - ONLY- applies to computer software.
> Cars and each of their components, fridges, tv's, cranes, bulldozers, 
> lawnmowers, toasters, injection molding machines, shovels, rakes, in fact most 
> of the things used in life have virtually identical "Look and Feel" to their 
> competitor's offerings yet competition abounds.
>   
It's worth noting that people demand vastly greater functionality and 
control from computer software than they do from any other device 
they're likely to use. The user interface presented by most software 
would, if implemented as a physical device, be considered impossibly 
complicated by most people. Software interfaces, to remain usable, have 
a vastly harder job to do than most physical interfaces, managing their 
complexity to be both functional and usable to a variety of users with 
different backgrounds, expectations, and levels of experience.

In fact, there's quite a bit of difference in user interface in many 
consumer hardware items. TVs, for example, are practically never the 
same, they just share the same general concepts - "on", "off", "channel 
change", etc. The remotes vary a lot, as do the on-device controls (and 
their presence or absence). I'll grant that there is a common "icon set" 
used, though, and that helps a lot. On the other hand, OSDs are rarely 
even remotely similar and figuring out how to perform the same function 
on 3 different TVs takes time. Still, the fact that the basic concepts 
are few, simple, and translate directly to things we perceive in the 
physical world mean that people can acquire the concepts easily. People 
accept the varying UI because the devices are simple enough that they 
can easily associate the familar concepts with the way they're presented 
by that device; they can just muddle through.

With software, people are often also learning the concepts behind the 
task at the same time. They're trying to learn the "word processor" 
concepts and how OpenOffice presents those concepts at the same time. 
Ditto DTP and Scribus or Quark or InDesign etc. They're also often 
learning the background skills regarding writing and style, good page 
layout, etc at the same time, and sometimes expect the application to 
help with this.

UI commonalities are useful when the user already has some understanding 
of the ideas represented by the UI or can be assumed to be used to the 
same interfaces in other places. So, for example, Copy & Paste really 
must be consistent since it applies to almost all apps in a similar way. 
On the other hand, really highly app-specific functions like preferences 
rarely have any commonality with other apps, and don't particularly need it.

So, if you're looking at commonality in interface between Scribus and 
other apps, the areas to look at are:

- Handling of general platform/computer use concepts like copy & paste
- General DTP operations that are comparable between most DTP apps like 
ID, QXP, etc
- General text handling operations as compared to word processors 
(especially in the SE)
- ...?

However,  you must also consider the experience for a user who has 
little or no previous DTP, WP, etc experience and must learn Scribus 
"from scratch". These users primarily need a sensibly laid out UI with 
commonly needed/used options more prominently displayed, and they need 
the UI to be consistent in behavior, appearance, etc across the 
different parts of the app. Their existing expectations are sometimes 
completely different to other users.

This will result in conflicts. Sometimes you can do things either the 
way the other DTP apps do it, or a way that makes sense to users just 
learning DTP, but not both. Often the DTP-style and WP-style approaches 
to UI for the same task are very different even if the task its self 
isn't particularly, and you just have to pick one. If you pick the DTP 
style, WP users will complain. If you pick the WP style, experienced DTP 
app users will complain.

I guess my point is that software UI has a very hard job to do, must be 
much more complex than most physical devices a user will ever encounter 
(unless, say, they're a commercial jet pilot, they operate a 
harvester/planter, etc) and must be accessible to users who lack an 
existing conceptual foundation suitable for the task they want to use 
the software for. They must also manage conflicting expectations, 
skill/experience levels, etc.

Personally, I'm impressed by how *well* software UIs work and how 
consistent they manage to be.
> But the UI of software -- oh no!  thats a patent issue.
>   
That's partly because, unlike a lot of physical UI, software UI isn't 
trivial or obvious.

I'm not a fan of the patent system in general and especially not of 
software patents - but honestly, *really* clever UI is probably one of 
the few (only?) things software patents might be semi-legitimate for. 
That doesn't mean they're a good idea, though, or that the existing 
patent periods are in any way sane for software, be it UI or any other part.

--
Craig Ringer