Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/. There's a clear, two sentence explanation of what it is:
A dynamic, open source programming language with a
focus on simplicity and productivity. It has an
elegant syntax that is natural to read and easy to write.
There's an example embedded on the page. There's also recent news that intermediate users might be interested in.On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about?
The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images":
docker rmi $(docker images | grep "^<none>" | awk "{print $3}")
Any business that interacts with other humans needs to concern itself with messaging, and I don't think computer industry types are exempt in any way.Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first place.
Devtools exist to solve a problem. You should not evaluate devtools based on the webpage or how many people are using it. That way lies Oracle enterprise. :-)
The problem with Docker's website is not that it exists. It is that it substitutes sales & marketing for just simply explaining what it is to a developer. While one could classify this under the category of "marketing", it would be a mistake -- kind of like classifying man pages as sales pitches. Just tell me what the fuck it does for god sakes and I'll decide! I could give a rats ass whether Facebook uses it, etc...
To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage.[1]
Ruby was not adopted because of its webpage or its user base, it was adopted because one person bothered to look into it, liked it and decided to build a very popular web framework around it. Others saw the value in that domain and it exploded. Similar situation for Linux, which started from an FTP site and usenet posting. :-)
"The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy."
Unrelated to what I was talking about entirely. Affordances to the user is a merit of the tool itself. Docker could be considerably easier to use in some regards, and that would improve it's usefulness as a dev tool. However, this has nothing to do with attempting to gain marketshare with no direct relation to merit.
[1] But then Docker, the organization, is selling something, aren't they?
What exactly do you think Marketing is? It's not all about BS, it's about communicating a message. If that's a simple webpage, then so be it. Often an idea or product is far too complicated to explain through 2-3 lines of text and needs more.
That sounds rational and it's what I used to think, but I think this talk (https://www.youtube.com/watch?v=FzzL_QDKv0c) makes a good case that fuzzy human factors always play a role in technical decisions, and that's not necessarily bad.
Eg, which is better, Angular or Ember? Ruby or Python? Go or C++? Haskell or Common Lisp? You can accomplish the same things in either tool. Which you like better has a lot to do with what you already know. And popularity may seem like a shallow measure, but it affects whether you can get questions answered, find blog posts and books, locate a library to do something for you, and hire developers who already know the technology.
Popularity is probably also weakly correlated with stability. If my custom jQuery code doesn't work, there's a 99.999% chance that it's the fault of the code I wrote (used by 1 person) rather than of jQuery (used by thousands). When jQuery was new and used by tens of people, there was a higher chance that it was jQuery's fault.
dhh is a brilliant marketer.
docker rmi -f $(docker images | grep "^<none>" | awk "{print \$3}")
I agree with everything else you're saying completely. Although messaging a value prop is hard when you have so many use cases. We faced the same issue and ended up trying to segment users as quickly and high up in the funnel as possible so we could speak directly to their needs. docker images -f "dangling=true" -q | xargs -r docker rmi docker images -qf dangling=true | xargs -r docker rmi
Along with: docker ps -aqf status=exited | xargs -r docker rm
You've got two essential Docker aliases for cleaning up your dev environment. docker ps -q | xargs docker statsThe definitions of "clear" differ depending on who the target audience is. If you're assuming a heterogenous group of unknown faces, then you aim for colloquial and simplified language.
When marketing to programmers, however, the use of technical jargon and specific concepts is an absolute necessity for something to attain clarity. It's the avoidance of such that obfuscates meaning.
Here's an example of a good software overview: http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy
This is a straw man. Introductions can be concise or detailed, but they must convey some of the technical intricacies and underpinnings regarding the software. Using marketing language, clouds of buzzwords and too many dumb copy-paste examples leads to cargo cult development and people who jump on bandwagons as opposed to surveying for what is technically superior.
Furthermore, there's nothing wrong with your one-liner.
Getting people to use things requires communicating to them what the things is for, and how it is better than other alternatives, and how to use it to realize that benefit.
Therefore, devtool adoption requires messaging related to what the devtool is for, how the devtool is superior to other alternatives in the same space, and how to use the devtool to realize that superiority.
Actually having the tool is a start, but its not the ballgame if no one can understand what its for, why they should use it over other things that serve the same purpose, and how to use it.
Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
"messaging" isn't a condescending idea, its simply having clear, coherent means of communicating some message, with awareness of the audience that message is directed to. Like, what your product is for and why people should (and how they can) use it.