Why can't Scribus look and feel more like other DTP apps?

Here is something from Scribus list. The question was this:

I even think some guy with money & lawyers was claiming a patent on what's generally called a "task progress bar". (Wonder where that case is now?).

If that falls through, we wouldn't have the right to see things like:

# Completed: -------------------* 70%

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. But the UI of software -- oh no! thats a patent issue. I'd love an explanation of how antidiscrimnination and anticompetition meets look and feel.

And here's the response:

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.