[Scribus] Look and feel
Sat Feb 2 08:20:42 CET 2008
> 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.
More information about the scribus