6 ms·

It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you g

by akanet 11y ago

It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com https://www.docker.com, you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-benefit make sense? What new things can I do that I couldn't do before? They made a separate page just to address this giant "Huh?": https://www.docker.com/whatisdocker https://www.docker.com/whatisdocker, which I feel is equally obtuse. Luckily, the product itself is fantastic, so that gives you a lot of wiggle room on your website and documentation. Like, a lot.

ezy 11y ago
The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.
- akanet 11y ago
  I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ 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.
  - anonfunction 11y ago
    That one-liner won't work (for me), it's missing a slash in the awk command. I have this aliased as `docker-rmi-junk` since it's so common. 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.
    - Leynos 11y ago
      Or the marginally shorter: docker images -f "dangling=true" -q | xargs -r docker rmi
      - anonfunction 11y ago
        Looks like my `docker-stats-all` alias: docker ps -q | xargs docker stats
      - curun1r 11y ago
        You can actually go even shorter: 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.
  - vezzy-fnord 11y ago
    A clear understanding of what a tool does is critical to its adoption. The 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/Softwares/nosh.html 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.
- dragonwriter 11y ago
  Devs are people. 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.
  - ezy 11y ago
    I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
    - dragonwriter 11y ago
      > But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. "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.
    - carapace 11y ago
      You are correct, and the people downvoting you are wrong. Technical engineering decisions should be made on the basis of concrete analysis and not popularity contests. The noisy kids will come around sooner or later.
shykes 11y ago
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common for CIOs, IT directors, and various business managers to just pick up the phone to ask us (or our partners) what Docker is all about. So it's difficult to tell a story which satisfies all audiences. But I don't think that excuses everything. We are definitely better at building our product than at explaining it. One interesting side-effect is that, if you've been exposed to Docker-related marketing (in a broad sense), most of it probably didn't originate from us, the creators of Docker. This is sometimes problematic because Docker is so polarizing: depending on who tells you about it you will get such a different, often distorted picture of reality. Either Docker is a miracle cure for every disease on Earth (indicating an over-enthusiastic Docker fan, or a vendor trying to sell something to Docker fans), or it's a scourge sent by the gods of the Unix valhalla to punish mankind for techno-hipster false idols such as javascript and php (indicating a jaded Docker-skeptic, or someone trying to sell something to Docker-skeptics). Either way, it creates a lot of noise. And as you point out, there might be less noise if we ourselves did a better job at explaining when using Docker is, or is not, a good solution.
- akanet 11y ago
  Solomon, I gave a talk at lunch at your company about this very topic, but I think you weren't there, so you missed it. Ask avinson for a link to it. I think it was saved on your BlueJeans system.
- benmathes 11y ago
  Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
  - 11y ago
cbd1984 11y ago
I will echo this. I'm not ignorant. I understand VM and virtualization in general. I understand chroot. I understand how The ANSI-Standard Multitasking Multiuser OS works. It still took me a few attempts to understand what Docker even is because, frankly, it isn't quite any of those things. It's a lot more akin to what Plan 9 was doing with namespaces, but I think they take it a bit further. It finally clicked when someone described it in terms of "multiple distros on the same kernel at the same time" and then defined a distro in terms of being an init process and a userspace. That makes sense. Reading up on the clone(2) system call, which is where the 'magic' is, made it even clearer. But that's impenetrably technical unless you already have a pretty good background in operating systems. As any marketer will tell you, being technical is poison. Ideally, you should be able to sell the product in terms of what it will allow, not how it works. Except with Docker, that's hard: "Oh, it will allow me to run multiple applications at once. It's... an OS kernel? Nope, it says it's Linux. So it's a distro? Nope... uh... is it a new VM? Nope, not that, they all have to share the same kernel... what?" I guess my point is Docker is hard to market. The website is either going to be vague or rather dense, and vague seems to win.
fierycatnet 11y ago
Pretty much this. I was working on a simple Rails app to get familiar with Rails and someone mentioned Docker to me. So I went to their website, did the tutorial, didn't understand why this is essential or better and just pushed to Heroku instead. Half of the time, if not more, I have no idea why this or that technology is being pushed so much or mentioned or whatever. And the landing page is not making it easier. Sometimes I feel like web development is more complicated than it should be.

by akanet 11y ago

ezy 11y ago

The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.

akanet 11y ago
I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ 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.
- anonfunction 11y ago
  That one-liner won't work (for me), it's missing a slash in the awk command. I have this aliased as `docker-rmi-junk` since it's so common. 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.
  - Leynos 11y ago
    Or the marginally shorter: docker images -f "dangling=true" -q | xargs -r docker rmi
    - anonfunction 11y ago
      Looks like my `docker-stats-all` alias: docker ps -q | xargs docker stats
    - curun1r 11y ago
      You can actually go even shorter: 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.
- vezzy-fnord 11y ago
  A clear understanding of what a tool does is critical to its adoption. The 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/Softwares/nosh.html 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.
dragonwriter 11y ago
Devs are people. 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.
- ezy 11y ago
  I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
  - dragonwriter 11y ago
    > But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. "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.
  - carapace 11y ago
    You are correct, and the people downvoting you are wrong. Technical engineering decisions should be made on the basis of concrete analysis and not popularity contests. The noisy kids will come around sooner or later.

shykes 11y ago

Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common for CIOs, IT directors, and various business managers to just pick up the phone to ask us (or our partners) what Docker is all about. So it's difficult to tell a story which satisfies all audiences. But I don't think that excuses everything. We are definitely better at building our product than at explaining it. One interesting side-effect is that, if you've been exposed to Docker-related marketing (in a broad sense), most of it probably didn't originate from us, the creators of Docker. This is sometimes problematic because Docker is so polarizing: depending on who tells you about it you will get such a different, often distorted picture of reality. Either Docker is a miracle cure for every disease on Earth (indicating an over-enthusiastic Docker fan, or a vendor trying to sell something to Docker fans), or it's a scourge sent by the gods of the Unix valhalla to punish mankind for techno-hipster false idols such as javascript and php (indicating a jaded Docker-skeptic, or someone trying to sell something to Docker-skeptics). Either way, it creates a lot of noise. And as you point out, there might be less noise if we ourselves did a better job at explaining when using Docker is, or is not, a good solution.

akanet 11y ago
Solomon, I gave a talk at lunch at your company about this very topic, but I think you weren't there, so you missed it. Ask avinson for a link to it. I think it was saved on your BlueJeans system.
benmathes 11y ago
Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
- 11y ago

cbd1984 11y ago

I will echo this. I'm not ignorant. I understand VM and virtualization in general. I understand chroot. I understand how The ANSI-Standard Multitasking Multiuser OS works. It still took me a few attempts to understand what Docker even is because, frankly, it isn't quite any of those things. It's a lot more akin to what Plan 9 was doing with namespaces, but I think they take it a bit further. It finally clicked when someone described it in terms of "multiple distros on the same kernel at the same time" and then defined a distro in terms of being an init process and a userspace. That makes sense. Reading up on the clone(2) system call, which is where the 'magic' is, made it even clearer. But that's impenetrably technical unless you already have a pretty good background in operating systems. As any marketer will tell you, being technical is poison. Ideally, you should be able to sell the product in terms of what it will allow, not how it works. Except with Docker, that's hard: "Oh, it will allow me to run multiple applications at once. It's... an OS kernel? Nope, it says it's Linux. So it's a distro? Nope... uh... is it a new VM? Nope, not that, they all have to share the same kernel... what?" I guess my point is Docker is hard to market. The website is either going to be vague or rather dense, and vague seems to win.

fierycatnet 11y ago

Pretty much this. I was working on a simple Rails app to get familiar with Rails and someone mentioned Docker to me. So I went to their website, did the tutorial, didn't understand why this is essential or better and just pushed to Heroku instead. Half of the time, if not more, I have no idea why this or that technology is being pushed so much or mentioned or whatever. And the landing page is not making it easier. Sometimes I feel like web development is more complicated than it should be.