Why can't Scribus look and feel more like other DTP apps?: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
''Here is something from Scribus list. The question was this:''
{{FAQ Index}}
*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;<br>
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:''<br>
  # Completed: -------------------* 70%
  # Completed: -------------------* 70%


It amazes me that look and feel - ONLY- applies to computer software.
''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.''
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:
And here's the response:
{|
{| width=80%
|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  
|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.
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  
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.
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  
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  
task at the same time. They're trying to learn the "word processor"  
layout, etc at the same time, and sometimes expect the application to help with this.
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  
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.
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  
So, if you're looking at commonality in interface between Scribus and other apps, the areas to look at are:
other apps, the areas to look at are:


- Handling of general platform/computer use concepts like copy & paste
* Handling of general platform/computer use concepts like copy & paste
- General DTP operations that are comparable between most DTP apps like  
* General DTP operations that are comparable between most DTP apps like ID, QXP, etc
ID, QXP, etc
* General text handling operations as compared to word processors (especially in the SE)
- 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  
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  
little or no previous DTP, WP, etc experience and must learn Scribus  
different parts of the app. Their existing expectations are sometimes completely different to other users.
"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  
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.
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  
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.
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  
Personally, I'm impressed by how *well* software UIs work and how consistent they manage to be.
consistent they manage to be.
|-
|-
|> > But the UI of software -- oh no!  thats a patent issue.
|''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  
|That's partly because, unlike a lot of physical UI, software UI isn't trivial or obvious.
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.  


I'm not a fan of the patent system in general and especially not of
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.
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.
|}
|}

Latest revision as of 19:57, 22 November 2008


This article is part of the FAQ series.
Installation Usage PDF issues Fonts DTP Other

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.