Re: User Experience Engineering

[D Josiah Boothby]

On Sun, 8 Jan 2006, Joshua Koo wrote:
> I have no say in Lilypond development, but I do have similar thoughts I
> would like to share (well as maybe a more bias windows user).

It seems to me that part of the issue that's at play in this thread is a 
matter of porting software from a Unix-based environment to Windows. 
Unix/Linux philosophy is very accepting of finding whatever editor works 
best for the user for the given application (in this case, creating 
lilypond files), where the Windows philosophy seems to be that if it 
doesn't automatically work with whatever is already installed, then it 
must be broken. If, as has already been pointed out, there were (more) 
people helping develop lilypond for Windows, perhaps this would be less of 
an issue. But on the subject of editors, I know one programmer who likes 
using notepad for coding (but that's only because he does a lot of work on 
other people's computers without knowing if they have his favorite editor 
available already). There are dozens of programmers editors available for 
Windows. I remember liking Note-Tab back when I was still on Windows, but 
I don't know if (a) it still exists, or (b) if it's any good for lilypond.

> ...
>
> If after all the purpose of lilypond is produce beautiful scores, why 
> cant the input be visual? I dont have the answer. For me, if I wanted to 
> compose, in my mind would be thinking where the notes on the score for 
> entry, rather than what are the pitch names.

Not being the sort who can compose at a computer (I'm a pen(cil) and paper 
man), I can't really understand this sentiment. I can respect it in 
others, but I can't understand it. Typesetting software, in my opinion, is 
not the best environment for composing; it is, however, an ideal 
environment for taking something that's already composed and making it 
look professional. I'm very comfortable using Finale, at least as 
comfortable as I am with Lilypond. I still can't compose in it, in spite 
of the fact that it is a (more) visually-based entry system.

> For example, take 3d modelling/rendering software. I do appreciate the 
> beauty of pov-ray rendered images, but it seems to me very painstaking 
> to type the syntax, coordinates and everything just to generate each 
> image. Could you imagine how if its used create a 3d movie? But I 
> believe there are a couple of good frontends for it. If you have seen 
> any relatively experienced user work in 3ds max (or maya, lightwave, 
> blender3d..), its really like the mouse becomes a hand in the computer, 
> and moulding 3d models from blocks like how pots are moulded from clay.

Again, this reminds me of the Unix-ish software philosophy: different 
tools for different jobs. Pov-Ray is not ideal for all sorts of image 
work, and is certainly not the best tool for every user. It is a very 
powerful tool in the hands of someone for whom it makes sense and who will 
use it for its intended purposes.

> ...
> Till then, take your pick on the wide choices of score setting software, 
> and even if still chose lilypond at the end, you can find the converters 
> (abc, midi,musicxml, nwc.. ) or many others which can produce lilypond 
> files (lilypad, gscore, denemo, noteedit, rosegarden, harmony 
> assistance..), and issnt that the unix philosophy?

Perhaps. I've found that I have to correct a lot when I import from 
Rosegarden, and that I end up saving considerable time if I just go from 
beginning to end in whatever editor I happen to be using that day. LSR and 
the templates in the manual are more useful to me than any graphical entry 
system could be. But hitting the point of unix philosophy again, you're 
right on. Additionally, it's a matter of choice. I used the KDE Advanced 
Text Editor last week because I was in KDE and it was convenient. A couple 
weeks ago, I was using Emacs because I was editing a score that resided on 
my home computer, but I was at my parents' house. I hear jEdit with 
lilyTool is quite useful, and this is available for any OS that can use 
java 1.5.

Josiah