In doing a bit of background reading for this post, I stumbled on Sebastian Riedel’s Perl Monk post from 2008 titled "Prettier Perl websites." The discussion on that post is a fun read, as it highlights the polarization in the Perl community around Perl’s (rather lousy) public image. This comment says it all:
One thing I always liked to say about Perl-based services/sites, is that they, like Perl (and the Camel) are "Ugly, but efficient".
However, if you’re following the conversations about "Modern Perl," and "Enlightened Perl," then you know that Perl doesn’t have to be ugly to be efficient. And, in that spirit, I’m not going to debate the why, or if, improving the public face of Perl Web sites is important, as that has been covered in my previous posts.
So here are three arguments in favour of some greater consistency and some best practices when it comes to the Perl community’s public-facing Web properties:
Let’s start with something like Perl Best Practices. Why bother with documenting best practices? Well, for starters, coding best practices are generally understood to make programs easier to read, and understand; and that helps everyone.
Then there is CPAN and Module::Starter. CPAN is prior art. The Perl community often encourages those new to the language to leverage the reusable components on CPAN, before re-inventing the wheel, and that makes a lot of sense. Same goes for Module::Starter. Creating things from scratch can be a pain-in-the-ass, and these examples of best practices make things a lot easier.
Contrary to popular belief, guidelines don’t have to be a constraint. Used effectively, they benefit the entire Perl community.
So, what would be some equivalent initiatives that could serve to introduce best practices, prior art, and tools for making "Prettier Perl Web sites?" Here are three ideas:
Perl community graphic standards: A good start would include some tools to support those developing new projects, like Padre, when they reach the point of needing a graphic identity and a public-facing — aka marketing — Web site.
Like any graphic standards guide, it could include examples of how to take existing Perl-community-developed material and customize it for a new project (while keeping things consistent). Editable logo files, suggested colour palettes, and example Web site layouts could all be included here.
Perl community editorial style guide: A fair amount of the whole Perceptions of Perl conversation has focused on how the Perl community talks about Perl. Just like Perl Best Practices, establishing consistent ways of communicating about Perl publicly — at conferences, in the boardroom, and on Perl community Web sites — would benefit everyone.
And maybe this wouldn’t even take that much effort, as I would guess that O’Reilly already has an editorial style guide for their Perl-related books. That could be a starting point toward more consistency in how we write (spellings, capitalizations, etc.) and talk (editorial voice, etc.) about Perl.
Perl blogger themes: A quick scan of the blogs involved in the Iron Man Blogging Challenge reveals that many Perl bloggers are using a default, out-of-the-box, "theme" (layout and styles) for their blog. Additionally, Perl bloggers seem to favour the Perl-based Movable Type blogging platform. (Though a suprising number also use the PHP-based Wordpress too.) This presents an opportunity to say "Hey there Perl blogger, why not use this nifty, Perl-specific, Movable Type theme?" (Obviously, the theme could be ported to any system.)
What would the theme include? How about built-in links, using consistent language, to the Perl community’s main properties, automatic syndication of key Perl newsfeeds, and — most importantly — a blog design that would make any blog author proud.
This marks the end of my rant about Perceptions of Perl and Prettier Perl Web sites (hopefully!). Next up: less rant and more practical examples of how we can make things better. As Sebastian said "Don’t explain what you think would look better, just make a mockup and show us!"