* Daniel Barkalow <barkalow@iabervon.org> wrote:

quoted text
> > also, the first natural thing i did was to just type:
> > 
> >  $ git-merge ~/linux-2.6-x86.git/
> > 
> > which i naively assumed would sort things out for me and provide 
> > some reasonable default behavior - but instead it just gave an 
> > annoyingly unhelpful error message:
> > 
> >  /home/mingo/linux-2.6-x86.git/ - not something we can merge
> > 
> > there should really be a consciously established "route of failure 
> > resolution" - directing people towards relevant sources of 
> > information or commands when the git command-line utilities return 
> > some error due to user incompetence. Otherwise users just guess 
> > around and get frustrated.
> 
> I'm not sure we can figure out what the user actually meant in this 
> case; there's just too much overlap in namespaces to determine 
> reliably that you were giving it a remote repository on the local 
> filesystem rather than anything else.

well, current git got to /home/mingo/linux-2.6-x86.git/ which is a local 
path. (it is printing it in the error message above) So i think it was 
rather unambiguous what i meant and Git knew about it, right?

but even if it _was_ ambiguous, i think tools should generally default 
to a minimal amount of hassle for new users and should try to pick 
reasonable "action" versus any "inaction". (as long as the behavior is 
still deterministic and reasonable even to the long-time user)

but more importantly, i think this whole problem area has to be handled 
with a slightly different kind of mindset than other, more technical 
aspects of Git.

Humans, and in particular males, when they see or learn new things, are 
very emotion-driven. The first 1-2 minutes (often just the first few 
seconds) have a very strong influence on whether that person 'likes' a 
new topic, tool or gizmo he is checking out - or not. Males often think 
of themselves as being objective when shopping new items - while in 
reality more than 90% of their purchasing decisions are emotion-driven 
and it's all set and done in the first 10 seconds of visual contact. 
(this ration is far higher than for females)

Command-line tools like Git are at heavy natural disadvantage compared 
to say GUI tools because the "first impression" is so minimalistic and 
relatively unremarkable. A GUI can get people hooked by making the first 
10% look easy just via old-fashioned, dishonest visual deception.

so basically for 90% of the new users, we've got 2-3 shots or we lose 
their "sympathy". Starting with an error message is bad. Being 
uninformative about what happened is bad. Making the user wait without 
signalling why he is waiting is bad. Etc. etc. I think this experience 
of mine was a reasonable simulation of a first-time user reaction (by 
virtue of me having forgotten certain Git details).

And the moment a negative first-time impression has settled in it's very 
hard to overcome that emotional mindset and barrier. People might still 
think "Git is quirky" even if we do all things perfectly from that point 
on. The same holds for the other direction: a positive first-time 
impression is harder to destroy, even if it turns out to be not that 
simple later on.

A tool's reaction back to first-time users is like a decision tree: 
every negative reaction, every error message, every unreasonable wait, 
every uninformative output is a way for the user to exit our ecosystem 
and to never discover the true strengths of Git.

So i really think that maintaining this aspect of Git and in essence 
Huffman-optimizing the interface and the learning curve for first-time 
Git users is perhaps the most important thing. Especially since some 
users like me will often re-learn Git details that they use rarely.

Getting these details right is _extremely hard_, because the people who 
are capable of fixing these details have long forgotten the first-time 
annoyances they had! (if they had any - often developers are 
statistically lucky and never hit any pitfalls.)

It's doubly hard because Git developers work on Git exactly because they 
_like_ it, so one's own positive experience has to be contrasted to the 
prospect of negative first-time experience.

It's triple hard because it might also mean changing some things that 
have been done in Git since the start of the project. A negative 
experience that isnt some technical problem in the strict sense - it's 
an emotional thing that is much harder to define and much harder to 
agree on and improve.

So i think it's really hard mentally - and i'm positively surprised by 
the many constructive and positive reactions that my mail generated.

Improving this area is perhaps even harder than adding new functionality 
- but i think it's a key and extremely strategic aspect of Git, because 
it affects the very heart of the Git project: it maximizes the influx of 
new users (who also include future Git developers btw.) and minimizes 
outflux of existing users.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html