The False Dilemma of Novice and Savant User Experiences

In the discussion of Perl
Applications for Normal Users, the subject of installation came up again.
User experience isn't always my primary concern, and I don't mind
overgeneralizing that to other parts of the Perl 5 community.

Yet a common refrain in many (more heat than light, sadly) discussions is
that functional is more important than attractive. Yes, that's a false
dichotomy.

I don't want to restart the debate over the attractiveness of Perl 5
websites. (I'd love to see variant templates that writers, developers, and
projects could borrow and adapt for consistency of good design, but that's a
different story.)

I want instead to talk about installation. This ties in to Who Benefits from the CPAN?. Consider, for example, the amount of work required to configure a CPAN client in 2000 versus the amount of work required to configure the same client in 2009. This has improved.

Yet compare that to installing a random PHP application.

Preemptive ad hominem: if at any time you feel the need to comment here or elsewhere saying "You fool! You foolish fool! You want to turn Perl into Java, you drooling maniac!", you are a masochist and your opinion does not matter.

One commenter on the previous post praised Ruby Gems for not failing tests and not spewing
diagnostic output and asking confusing questions. Of course the thought of
not running tests on installation horrifies me (how do you have any
idea if your software works?), but the point is a good one. What information
do users need to know to install your software? What questions do you really
need to ask them?

We've optimized the Perl ecosystem for Perl developers. That's good. That
helps us. That doesn't necessarily mean that what's good for Perl developers
is good for Perl users. That also doesn't mean that we can only optimize the
experience for one group at the expense of the other.

We can do better.

I argue often for better defaults -- not just at the language level
but at every level users might see. Yes, I've overloaded the word "user".
Deal with it.

One important question for me as I ponder visions
for Perl 5 and its ecosystem is "How can we improve the default behavior
for novices and for most uses by experienced programmers while allowing
experienced programmers to customize behavior for advanced uses?" That's a
language design principle. If you analyze the design of Perl 5, you'll see
Larry's answers everywhere. The same goes for Perl 6.

I don't have complete, systemic answers for that yet. We have a lot to
ponder. As food for thought, consider the (oblique) connection between two
comments. The first comes from a
critique of Python:

Moose is good and Moose is great, but the real win would be to
automatically install modules, automatically call the OS's package manager to
install libraries and other deps, to have created PHP before php did (or after)
and have a libperl linking executable that outputs web pages (period), and most
of all, to have a sandbox mode enabled by default (tired idea, I know) where
users can write code without getting yelled at by humans, only by the computer,
even if just because the code is labeled (all is fair if you predeclare) as
"babytalk". Perhaps this would be a mix of strict, diagnostics/warnings, and a
Perl::Critic policy
that tries to help them in only the most immediate sense likely to be useful to
novices in the short term.

Tags:

2 Comments

It seems like there's been a historical default towards verbose diagnostic output during Perl module installation. Certainly, two modules I contribute to, CPAN.pm and Module::Build, have this problem in spades.

Most of the time, I don't think the user cares when things go right.

I'd like to see these quiet by default, but to make it easy to get more information when things go wrong.

A propos "automatically call the OS's package manager to install libraries" - yeah - this would be nice - but to get there is a long way. A step in that direction would be adding a way to register external dependencies just like we do for internal ones. Finding all the unmet external dependencies upfront would also improve the matter with the huge diagnostic output - for more cases users would not need to consult it. In recent practice, and also in retrospective when I recall my earlier attempts, on 'standard' platforms (like Linux) it is the external dependencies that trigger the most of the failures.