Even most programmers are distributed like this. My team recently was doing usability tests of a networking library that I work on. We screen recorded a few random programmers try to install it and then make a simple app with it, giving them access to our tutorial and Hello World demo.
It was painful to watch them stumble about, trying to debug installation errors that seem obvious to us. Just like trying to watch a lay person try to use a computer, watching these other people made me want to blurt out the answer.
Any of the lessons that you take away from designing simpler UI for lay people applies just as much to professionals. Write a better API, a better library, and better documentation.
Case in point: while Java Swing where popular, noobs, including me where looking to Graphics2D and Image when we first wanted to insert a picture.
The correct solution was jLabel.
Since then I have learned a lot but man pages and docs without examples are still annoying. (BTW: used rsync manually for the first time in a while yesterday and the man page was good, src and dst syntax was described. : )
The problem there being that few people are going to see JLabel in a class list and think "oh, that must be something to do with my image-related needs!" Especially if they've used other GUI tookits, which as far as my experience goes use "label" exclusively to mean "some static text".
Well, except WPF, where you can re-template anything you like, but even there, the default Label is just a text container.
Or web developers, who know that the obvious way to insert an image is to take a block element originally used for text and style it with a background image...
The problem there being that few people are going to see JLabel in a class list and think "oh, that must be something to do with my image-related needs!" Especially if they've used other GUI tookits, which as far as my experience goes use "label" exclusively to mean "some static text".
In Tcl/Tk you would also use a label to display your image with. Tk was one of the most popular toolkits at the time Swing was designed.
Being blunt, it's also possible that your library was garbage from a usability perspective. It's nearly impossible to recognize how painful it is to work with your own code since you are so intimately involved in writing it.
That's most likely true. Most libraries are horrible to install and configure and only make sense to the people who wrote it.
I gave up on learning PHP and Laravel recently when I went to install Laravel and they recommend Homestead. So I went to install Homestead, but they require Vagrant. Of course Vagrant requires VirtualBox, and VB can't find my kernel source code on RHEL 6.5. Okay, so let's skip Vagrant... Okay, now I need to install Composer instead of Homestead... what's this? SSL operation failed... failed to enable crypto... operation failed in command line code...
Yeah I give up. Yeah, I could take the time to work through this nonsense, but I shouldn't have to. Getting multiple layers deep of having to install dependency A to satisfy dependency B which satisfies dependency C is not my idea of fun.
> It was painful to watch them stumble about, trying to debug installation errors that seem obvious to us. Just like trying to watch a lay person try to use a computer, watching these other people made me want to blurt out the answer.
I see that all the time. Programmers aren't necessarily expert computer users.
The number of people on my team that don't use, say, WebStorm's regular expression search & replace to quickly refactor, or find usages, or anything in the refactor menu, or even the NPM scripts I made to quickly update the project -- any of the less obvious features to make their own lives easier is more than half of the team.
And they also like to work on one monitor, maybe two.
Just watching them try to debug something with their cargo cult methodology is frustrating.
Shit, I have people on my team who click Edit -> Copy and Edit -> Paste. Sometimes they might right click and paste, but keyboard shortcuts are foreign to them.
Isn't it common knowledge though, that the setup is a really big chunk of the work?
And the problems encountered are probably not all too exotic, so you'll be much better after doing it a few times. However this is not a task you do often (at most once or twice per project). It's no surprise to me that years of practice work wonders on reducing the setup time.
If you add research of suitable tools it becomes probably even more dramatic (finding, installing, testing, uninstalling, repeat until you think you might have the best or a suitable solution)
> It was painful to watch them stumble about, trying to debug installation errors that seem obvious to us
At least they were trying and did not dismissed the error messages as soon as they appeared
It was painful to watch them stumble about, trying to debug installation errors that seem obvious to us. Just like trying to watch a lay person try to use a computer, watching these other people made me want to blurt out the answer.
Any of the lessons that you take away from designing simpler UI for lay people applies just as much to professionals. Write a better API, a better library, and better documentation.