Have people done hallway usability testing on git?
i.e. just take a smart undergrad CS major and record their screen (& audio) while they try to figure out how to use it. I think this would definitely turn up some tasks within it that are way harder than they need to be. Do people really feel confident that learning git is a smooth process, not involving a lot of swearing?
The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools! We shouldn't just keep insisting that the customer (programmers) needs to toughen up and learn (as the default answer, anyway; some things really are hard)
Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you?" every time you use a man page? I bet the success rate would be pretty low.
In general why isn't there any information about which man pages are good and which are terrible? They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. Yet there are probably ones out there which would be rated "useless" 99% of the time, and have been for 10+ years with no change.
I think you bring up some good points of open source projects vs. commercial ones. In open source projects, most of the time when seeing critical feedback by users you see those "it's open source, just change it the way you want" comments. No one makes money, therefore no one depends on users being happy about the software. That's why B2B is so attractive: Your users actually WANT to pay you such that you are dependent on their happiness.
Maybe we should invent a new model that combines open source with paid incentives for user desired changes. Let's say User A uses Gimp, sees something that could be simplified or added. He can't program it himself but what he can do is describing the feature he wants, possibly with screenshots or even an interface prototype. He then auctions this on a marketplace website. Other users can upvote or even chip in to A's auction such that the probability of a good developer implementing it rises. Developers have their profile with reputation, possibly linked with their stackoverflow reputation. The change gets implemented within a branch of gimp, installable by anyone using a modified package manager. If the maintainers of gimp like the change, they can merge it in such that everyone profits - the number of user downloads being a good indicator that the change is desired.
I agree with you. Unfortunately one thing I keep seeing in the developer community that frustrates me is this competition-like demand for learning new things. Sure I love learning new things. But I don't like learning new things just for the sake of learning things. You look around forums and websites, every time someone's asking for help and is confused about something, the average response roughly says "you are a lazy ass and you should feel bad about yourself because you didn't read the 60 pages of manual someone else wrote, oh you are also not smart enough, go learn new things, look at all these command line arguments that I have memorised..." our memory and human resources are too precious to have to deal with this stuff.
This. There's two basic types of commercial software (yes over-simplification) turn-key or custom. I work for a shop that does the latter. If I brought software to our clients with the explanation: "toughen up, read the manuals, we adhered to your spec!" then we simply wouldn't get paid. Git or DVCS in general isn't this nature though and is turn-key like MS Office for example. If some part of Office was a usability nightmare most people would simply avoid it. Some may not purchase the software altogether if they were to say take a trial of 30 days and couldn't get passed File->Save As or some rote "simple" command. That is a trite example but the analogy isn't that far off base.
I will caveat everything by saying I have drank the Hg kool-aid and will be drunk for some considerable time. It wasn't that it was SVN-like, but as I explore more complex features on my own, my hand isn't slapped in the process. I've hosed repositories in Hg and SVN. I've fixed Hg repositories from codeplex that seem eternally broken given that is the "authoritative master". It didn't take any research at the time but I couldn't recall if the knowledge was entirely latent (i.e. discovered previously) or I had researched it at some point in the past to bring it up in the future.
I'm of the notion that if you can jump to any DVCS for the most part you're doing an excellent job. It doesn't hurt that there's hgsubversion or hg-git to make transitions easy but even the more obscure DVCS' are a leg up. I don't bash Git on some crusade, as I look at OSS projects and realize if they use it I probably should too at some point but the barrier to entry is inherently steep. I look to articles like this posted to hopefully stir interest in fixing the usability problem and it's extremely comforting to know that so many people share that it most definitely has a usability problem. I'm not the only derpy one here apparently :>. I really want to learn Git but I definitely do not want to be tasked as the Git-guru of my small developer team. We use a paid hosting firm that only has svn or git to choose from and I can get away with pushing people towards Hg with hgsubversion much easier than playing tech support.
Interestingly, in my experiance the chances that a random CS undergrad is comfortable with git is much higher than the chances of a random dev who has been in industry for a while being so.
I read this post and see a number of ideas that could be turned into products by someone enterprising enough to do it, and who honestly believes such a market for them exists.
i.e. just take a smart undergrad CS major and record their screen (& audio) while they try to figure out how to use it. I think this would definitely turn up some tasks within it that are way harder than they need to be. Do people really feel confident that learning git is a smooth process, not involving a lot of swearing?
The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools! We shouldn't just keep insisting that the customer (programmers) needs to toughen up and learn (as the default answer, anyway; some things really are hard)
Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you?" every time you use a man page? I bet the success rate would be pretty low.
In general why isn't there any information about which man pages are good and which are terrible? They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. Yet there are probably ones out there which would be rated "useless" 99% of the time, and have been for 10+ years with no change.