Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Beautiful is better than ugly 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I absolutely agree to everything you said! As a full-time Perl developer and part-time web designer I'd really love to help renovating the appearance of Perl. I've recently done a redesign for catalyst.perl.org which got the approval of the core dev team (sadly, it's still not online though). So ... what's the best place to start offering help? :)

    • Step 1. Politics

      If we're going to start redesigning websites wholesale it needs buy-in from the appropriate people who built and own the websites, so that anything we create is suitable for purpose and reusable across all of the websites properly.

      • it needs buy-in from the appropriate people

        Which also means some technical constraints*, because it has to be able to run on the existing hardware budget if not the existing hardware, and scale to the size of known traffic peaks. Yes, these sites can end up on the front page of slashdot, so the "static" pages better not be making umpteen calls to a database to generate their content.

        * constraints are good. A good artist uses constraints to channel their creativity and inspire them. Well, that's my story an

        • I don't know the current infrastructure, but IMHO it'd be a good idea to utilize some sort of flexible and static content generating CMS (Bricolage comes to mind ... Maybe we can even get David Wheeler to help with the setup and planning of the site)?

          • I think you're missing the point. Adam is talking about presentation and layout design, not a CMS or whether we're using a flavour of the month framework. Templates and CSS can be integrated into any site. Ruby on Rails largely got peoples attention because the initial websites looked well designed, and had nothing to do with the backend codebase.

            The problem is that many of us are decent coders, and can put together a functional site pretty well. However, we're mostly not website designers and that's what w

            • I think I DID get the point that first and foremost an optical change is needed. nicholas brought up technical constraints which is why I thought about switching the backend as well. I didn't know that the sites which look like they can be dated back as far as 1985 had a decent CMS that sports a separation between backend and presentation ;-) Anyways, does anyone know why exactly the TPF doesn't invest some money into a professional web designer to polish Perl's appearance? This stuff really doesn't cost a

            • The main reason Digital Craftmen didn't manage a full implementation of our proposed glossy design for www.perl.org is that combust (the perl.org CMS) requires apache 1.3 and mod_perl 1 to run... we don't have any servers that out of date, and we couldn't spare one to downgrade for the build and test.

              While I agree that the back-end shouldn't be the driving force in an aesthetic redesign, it seems that it can sometimes be a very effective brake.

              --
              Perl is Alive
              http://perlisalive.com [perlisalive.com]
              • To be honest, I also really don't see a problem with starting from scratch to set up a more friendly www.perl.org with a modern CMS and/or backend framework. If the backend holds back any new development, it's time for a change. But guessing from other posts this is not gonna happen in the near future ... In any case, there's way too much information on perl.org ATM which is only remotely useful. That's why I think the main emphasis should be put into some conceptual work to restructure the whole thing and
                • I think there's just a general feeling of caution amongst experienced developers about 'changing the cms' being the first response to any issue with a website. We all like playing with new technology, but sometimes all that's really required is to put some effort into coercing the old technology to behave better.
                  --
                  Perl is Alive
                  http://perlisalive.com [perlisalive.com]
                  • Being responsible for a 10-year-old legacy web application on a daily basis, I fully understand these concerns :) But there's always the possibility of a gradual transition ... I'd start from scratch and design a new perl.org primarily targeting new users with the usual "Getting started", "Download", "Documentation", "Community" and so on sections. From there we can always link into the guts of the old (content-heavy) sites.

                    • I have intended The Perl Beginners' Site [perl-begin.org] to be the (unofficial so far) first-stop for Perl beginners. About two years ago, I've adapted an OSWD template for its look, which should have made it attractive enough. There's still some problem with the testimonials section being lacking, but I plan to correct it when I find some time to dedicate to it.

                      Contributing and building upon Perl-Begin is very easy because the sources are available in a publicly-accessible Subversion repository, and the licence is CC-b

                • This isn't necessarily about perl.org specifically, or about this CMS or that CMS.

                  ALL of these websites are crap, run by a dozen different people/groups on a dozen different platforms, have all degraded or rotted, regardless of the sophistication of the backend.

                  I've managed to do a perfectly acceptable job of operating a site (and been complimented for it a number of times) with nothing but a plan HTML editor, an svn repository that 20 other people have commit to, and a cron job.

                  http://strawberryperl.com/ [strawberryperl.com]

                  A

              • You don't need to dedicate a server to running a different apache. You can run as many different apache/mod_perl binaries as you like on a single machine.

          • We at Plus Three (http://plusthree.com/ [plusthree.com]) are big contributors and users of the Krang CMS (http://krangcms.com/ [krangcms.com] and http://krangcms.com/screens.html [krangcms.com]) which was originally designed to mimic Bricolage in a lot of ways but is now considerably different. We have a clustered setup of the CMS and other servers to serve the content for our clients and we would be willing to help out if anyone needs it.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.