Re: problems with learning lilypond

[John Sellers]

(sorry to copy the whole thing back, but it seems appropriate some how).

I hear your pain.  I'll do what I can, but it may not be much.  I'm currently taking violin lessons from Jeremy Cohen (Grammy nominated this year), and Julian Smedley (Berkeley Hot Club and others), and Guitar from Jimmy Luttrell (Entered the Western Swing Hall of Fame this year.) 

So, needless to say, I am working very hard and am very busy.

But I do have some ideas, and maybe we could have an on going dialog at such a pace that would not be too much of a burden to either you or me.

My first thought out of the box?  Would be to start working on a low-overhead system for capturing and redirecting stuck and frustrated users at the point they get stuck or frustrated.  Feedback systems are often too high overhead to your side or the user side to be really effective.  Most attempts to create such a system are also not so easy to do right because it is really hard to get both sides of the picture without too much effort, and if the effort isn't spent, then you end up with something less than successful.

But for starters a carefully constructed "first contact" in-context link might be a first step on this path.  You want to get the feed back without pigeon holing the user and at the same time, not overburdening one's organization with umpteen Jillion "feedbacks".  One way might be that the feed back box is fronted with a carefully constructed explanation about your resource limitations, asking the user to go the extra mile to boil down and re-boil down their feedback to make it clear and precise about their problem.  One way to do this would be to use something like the Google Idea Contest template, but boiling it down to the specific purpose of getting unsticking/frustration fixing feeback, carefully structuring and limiting the form to a certain size while explaining to the user exactly why they need to be clear and precise.  Googles form is wonderful  guide to structuring ideas in a constructive form...this same concept could be adapted to your purposes.  What Google's feedback form lacked was immediate feedback on "size limitation" as the person typed...in other words it wasn't until the person filled out the whole form and discovered their text was too wordy. (just like I am now...lazy me...see you don't want this...you should limit my comments to a clear title, a short explanation of my idea,  a larger  description...etc....see the Google form if you can find it.  Google's form would have been perfect if they had had an automatic character counter on each field to tell the user when the limit was reached....and perhaps explained even more (in context) why clarity was needed.

If you were to do this in a way that can be clearly understood, I think you will be surprised how much work people are willing to put into making their explanation of their problem clear for you.

Taking this feedback form, if it is structured right, would enable the lilypond employee/expert/helper quickly recognize exactly what kind of remediation is needed.  I would expect this remediation be simply a link other already written documentation.

Step two, after some experience with this kind of feed back, would likely lead to the "I'm frustrated/stuck" link being replaced with a SPECIFIC SHORT LIST of ramediation which completely covers the knowledge presented.

Step three, after a lot of experience with this kind of feed back....taking from the very outset to plan a systematic way of presenting the kind of topological sort of dependencies and compiler and all that other fancy stuff....down the road....we put together a world class back end to your documentation which was able to ramediate anything and everything that is compiled....oh yea...minor detail...if and when you every reach that stage, it means putting in place an infrastructure for the programmers to enable them to do the programming and the documentation of the logic of that programming at the same time so there is a one to one correspondence to what liliypond compiler does and the documentation which describes that particular part of the language does.  Just as the compiler has to know what the language means in order to turn it into music, the user has to know that same thing in order to know what to type in order to turn it into music.  See the parallel???  But that is way down the road, first you have to understand from experience how the user's needs work, and you aren't going to get that except from the feedback...thus starting with the "frustration/stuck" links.  Eventually understanding how users get stuck and frustrated looking at a particular piece of code will tell you how to use the compiler parser for that particular piece of code to automate feeding them back to the documentation to get them unstuck, and in fact, what kind of documentation is needed to get them unstuck...a long row to hoe....but just think...a chance to be the best in the world.

End of another tirade....so....are you stuck or frustrated?  shoot...I'm game for a long-term constructive dialog....but keep to the point of going forward with this...if you are game.

Carl D. Sorensen wrote:

On 11/21/08 4:56 PM, "John Sellers" <address@hidden> wrote:

  

I have no argument with what you say about the documentation compared with
many kinds of technical documentation, as long as you stick close to home.

The Lilypond folks work hard and do a lot of nice stuff, including
documentation.

However, that doesn't change the facts of what I say.

The origin of the problem is that developers don't have to walk the path of
the newbies from beginning to end and it is very difficult to provide a whole
documentation structure that is truly responsive to those kind of needs...so
most technical documentation the world over never does successfully do so.

HOWEVER, MAY I POINT OUT DOING SO IS PROBABLY THE MOST PRODUCTIVE THING YOU
COULD DO TO LILYPOND TO ASSURE ITS FUTURE GROWTH AND SUCCESS!.

Good wishes, John Sellers
    

John,

If I didn't make it clear in my earlier post, I'll try to make it clear now.

I DON'T KNOW HOW TO DO WHAT YOU ARE ASKING ME TO DO!

(to the rest of you, I'm sorry about the shouting, but I felt the need to
respond in a way that John seems to understand).

Won't you please help us figure it out?  You seem to have some good ideas.
Why don't you share them in some specific way so that we can get a clue?

Thanks,

Carl