Re: User Experience Engineering

[Hans Forbrich]

Dear Linda,

I whole-heartedly agree with your comments about user experience being very 
important to adoption of any user-oriented computing product.

One problem with GUIs is that they MUST be tailored to the way the user wants 
to, or needs to be trained to, work.  Thus, the challenge becomes providing a 
comfortable environment - one that fits the way the developer is convinced 
will be convenient.  The spin-off of this problem is that the developer 
resources then become diverted from core functionality to interface 
functionality.

My favorite example is the plethora of accounting packages ... by GAAP 
principals, and by law, accounting within a country must conform to basic 
standards.  Therefore Simply Accounting, Quick Books, Microsoft Money, etc. 
all MUST do exactly the same thing internally.  Therefore the only difference 
is in the interface  - and that is driven entirely by perceived convenience.  
Sadly, the [lack of] quality inherent in these products because of diversion 
of scare developer resources is well documented.


Over the past 15 years, we have seen a number of changes: client-server; 
3-tier; and most recently web-services and the service oriented architecture.  
In all of these, there is a clear separation between the functionality of the 
user interface and the functionality of the service provider (server or web 
service).

In terms that might make more sense to your suggestion, Lilypond might best be 
considered a very advanced music typesetting service provider.  The API 
(application programmer's interface) happens to be one of more .ly data 
files.  

There is, perhaps unfortunately, no supplied sample user interface - as those 
of us who have spent time with Lilypond have found that manual interaction 
directly at the API level is ultimately faster and more flexible than 
attempting to use a graphical UI.  (I have also found this to be true in 90%+ 
of all applications I've used - command line IS  faster, more robust, more 
flexible, less resource intensive and less conducive to error and physical 
[health] problems such as RSI, than GUI.  It's just not as 'pleasant'.)

As long as the API is accessible, there are opportunities for others to 
develop client portions - many in fact, that would make sense for specific 
situations.  

However, I can envision no single user interface that would conveniently run 
the gambit of capabilities that are in Lilypond (therefore there would need 
to be several interfaces) .  The bickering of what is 'the right' interface 
for a situation - being heavily culturally influenced - could easily set back 
Lilypond development several years if the current Lilypond developers were to 
be involved.

My personal conclusion: Let the graphic artists and user interface specialists 
do what they do best; let the Lilypond developers do what they do best; let 
the joining come at the API level - which is defined.

Please do not take this as a negative to your comment - in fact it is the 
opposite.   I just happen to believe that the Lilypond (server) side is not 
the right place.  Perhaps at the Rosegarden (GUI) side, though.


-- 
Proud user of Lilypond Music Typesetting Tools
http://www.lilypond.org