Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Making Perl Monks a better place for newbies (and others)

by ELISHEVA (Prior)
on Mar 18, 2009 at 16:55 UTC ( #751522=monkdiscuss: print w/ replies, xml ) Need Help??

A few weeks ago cosmicperl began a discussion about the pros and cons of a newbie focused satellite site for Perl Monks. The suggestion of a new beginners only site was not particularly well received, and instead triggered a large number of suggestions about how the current Perl Monks could be improved.

This is only one of many threads where suggestions for improving PM have been offered. In the coming weeks, I hope to construct a list of some of the more recent threads. I will also be reviewing them and compiling a list of suggestions that people have made for improving PM. If anyone else is interested in working on this, please make yourself known.

This process (and this post) is an outgrowth of the discussion we had last week on the thread Process for Site Improvement. We have at present no "official" wish list or mechanism for prioritizing suggestions for site improvement. In that thread jdporter suggested that for the time being, one way to get a better understanding of what changes matter to us monks would be to compile a list of suggestions from PM discussion threads.

Some of the proposals in PerlMonks for newbies? are very specific; some simply point out general areas where improvement might be valuable. I've assembled a list (below) of the various suggestions from that post in hopes of stimulating discussion on the following questions:

  • Which, if any, of these suggestions do you feel are valuable enough to merit further discussion?
  • Do you see a consensus developing around any of the suggestions?
  • What suggestions would you add that aren't already on the list?
  • What do you value most about Perl Monks and which of these suggestions enhance or build upon that?
  • Which of these have in fact been implemented but need to be better publicized?
  • As we work through other threads and gather their suggestions what is the best format for organizing them? Do we want to see other "per-thread" summaries? What about consolidating all suggestions into a single list?
  • If more that one person is involved in compiling a list of suggestions (and I really hope there will be), what tools does PM provide to help us coordinate our work?
  • How would you prioritize these suggestions? What is the best way to keep track of a developing consensus about which suggestions are highest priority? Is there a way we could adapt the polling mechanism? Is a qualitative summary the best way? Some combination?
  • To the members of cabal, and pmdev in particular: What would it take to actually implement the more specific suggestions - both technically and in terms of support from the wider monk community?
  • What would you be willing to do to help make your favorite suggestion "happen"?
  • This thread gives examples of suggestions, some clear and some overly general. If you were to write a How (Not) to propose a site improvement tutorial, what would it include?
  • Was the format of this post helpful? What would you do to improve upon it?

If there is no objection, when this thread winds down, I will summarize the comments here and post the results so that we can continue to build on the discussion.

Best, beth

Note 1: My apologies in advance if I left out anyone's suggestion or misrepresented their views. If I have done so, please message me and I will make the correction.

Note 2:Many thanks to all those who gave suggestions privately and on the thread Process for Site Improvement about how to go about this task. They made this thread possible.

Suggestions have been grouped into one of the following categories:

Site look and feel suggestions

Site content and navigation suggestions

Community building suggestions

Site performance suggestions

Site development tool suggestions

Places to look for further inspiration

Comment on Making Perl Monks a better place for newbies (and others)
Re: Making Perl Monks a better place for newbies (and others)
by bellaire (Hermit) on Mar 18, 2009 at 19:50 UTC
    Nice write-up, and thanks for putting the effort forth to compile this list, I know it can't have been easy. I'd ++ multiple times if I could.

    First, I have some meta-commentary on the problem of dealing with suggestions in the first place. It seems like most of these suggestions can be broken down into two groups:
    • Suggestions for site features, i.e. things that must go through pmdev.
    • Suggestions for content or community behavior, i.e. things that could be done at any time, if enough people care enough to go ahead and do it.
    Unfortunately, it's hard to build consensus on these issues. I think that part of the problem is that the suggestions themselves are buried in various threads (for example, this one and the node from which this list was compiled). Even when they are found, it's hard to know whether they have been acted upon, superceded, forgotten, dismissed, or whatever. Case in point, the recent addition of support for [man://] markup, which was requested, implemented, forgotten, requested again, and then applied. Handling suggestions like a forum makes them difficult to find and to manage. Compiling this list in the first place is a good start, but I sense that it's going to be hard to extract consensus from the discussions, even given the current voting system. For example, many of the suggestions discussed have both proponents and detractors. Even if the pmdevs wanted to use these nodes as a basis for deciding what to work on next, they would have a hard time making sense of the discussions. In the end, things remain as they are, that is, the pmdevs work on what they personally feel is appropriate, and the gods make a further judgment on whether their efforts, once submitted, are realized on the site.

    I really don't know how to deal with this. On some other sites, there is a voting system attached to suggestions. This way, developers and admins have a clear idea of what the community wants. They don't have to search through discussion threads, mentally summing the votes for and against at various depths, or trying to interpret people who are presenting two sides of the story. Something like that would be nice, but of course that in itself is a suggestion that would require an implementation in code, unless somebody wants to pony up the cash to pay for such a service.

    The other idea I have is that there could be a new order of monks, whose job it is to solicit, facilitate, and compile suggestions for improving the site (much as ELISHEVA has already done in this thread), and do this on a continual basis. Unfortunately, since they would have no abiltiy to actually do anything about it, they'd be limited to publishing their findings as a new root node every so often. The pmdevs and the gods could take those data or leave them, as they see fit, but at least the information would be marshalled for easier consumption. After several weeks of demands for some form of WYSIWYG support (for example), perhaps they might decide it's worth looking into. Deciding the mandate for this proposed order definitely would require some extended discussion.

    Second, to address some of the specific suggestions made, here are my thoughts:
    • "Pretty sites", the "dated" look, and ease-of-use - The site, even in the default (public) view, is cluttered. Content is king, and must trump other factors, but there is no reason you can't have both an attractive, modern presentation, and the same excellent content we've grown to love. Actually accomplishing that will take effort, and I'm not sure that anyone wants to put in that effort given the objections that have been raised by the people who find nothing wrong with the look and ease-of-use. In particular, why not simplify the view that the general public sees, while leaving alone the baroque complexity of the interface for established users?
    • WYSIWYG and simpler markup - I don't particularly agree that WYSIWYG is itself a good idea, however at the very least I don't see why a more comprehensive summary of Markup in the Monastery can't be presented on node editing page. Also, non-WYSIWYG javascript support for editing markup of various types has been around a long time in heavy use elsewhere on the Internet. It should be possible to set up a non-buggy solution.
    • Preview nodes on update and for chatterbox - Especially for updates, seems like a great idea. I was actually somewhat bewildered when I discovered its absence there.
    • Content for Newbies - Not sure here. I think part of the problem is that there is so much great content already here, it's hard for newbies to know what they should be looking at. So, in that respect, a prominent "Start" node (if you will forgive the reference) would be a good idea.
    • Site Promotion Suggestions - I think that promoting the site by itself won't have an effect if the experience people have on arrival isn't improved. Going back to look-n-feel, the "new generation" of programmers see no reason for this site to have its decade-old appearance. It gives the impression that the site is a relic. If that were to change, site promotion could be quite effective indeed.
    • Community Building - I totally agree, I just am not sure what exactly to do. :) Twitter is a good start (and I just started following PerlNews, which I had no idea existed until this thread).
    • Performance - It seems to be the elephant in the room, which gives me the impression that nothing can be done. I don't want to be struck by lightning for even asking, so... moving right along...
    • Development Tools - I don't know enough about the existing tools to comment here.
    I think that's enough of me talking now.
Re: Making Perl Monks a better place for newbies (and others)
by ww (Bishop) on Mar 18, 2009 at 22:04 UTC

    Thank you ELISHEVA for putting this together, and ++.

    I can't offer any doctrine but I do have some personal views on some of the ideas we're exploring here.

    First and foremost, I vehemently disagree with those who feel we should change the "look and feel" of the Monastery, in pursuit of something "flashy" or "modern." "Don't fix what ain't broke" is valid advice to those who concern themselves solely with appearance. Being au courant is perhaps a good thing if one is peddling widgets, but it requires an unnecessary investment for a community dealing in knowledge, like this one. Further, being "up-to-date" (another phrase often used by advocates of a new look) is transitory. Today's up-to-date is tomorrow's passe.

    And if "up-to-date" or "modern" means AJAX, Flash, fancy graphics, and so on, using those almost guarantees longer download times; not a major issue for those with reasonably high speed internet access, but a huge stumbling block for users who rely on (bottom-tier) satellite or dialup.

    OTOH, I strongly agree that "content is king."

    We might make PM's content a bit more regal, if we develop a mechanism for hiding worthless or off-topic commentary on threads of more than some agreed-upon age (30 or 60 days?), so that the reader of any older thread could be confident that what's initially presented is, by consensus of the Saints or some similar group, the gold standard answer(s). It probably wouldn't take a lot more effort to give visitors the per-thread option of also viewing ALL the nodes in the initial thread, but even that would not be trivial. Overall, though, such a mechanism would be complex to develop, even were we to come to a consensus that this is a "good idea" and consensus on who gets to rate something as "gold standard."

    Markup? I suspect (but can't prove) that a large proportion of our newest users are more apt to have some passing acquaintance with .html markup than with POD markup.

    Lack of markup: I suspect the only reliable way to cure the appearance of hopelessly unformatted nodes is to develop a procedure for distinguishing among code, data, and narrative and to then invoke that procedure at the "preview" stage of node creation. In my (perhaps unworkable) vision, if the procedure finds markup deficiencies, the "create" option would remain blocked and the author would be given a message about the identified deficiencies. Wash, rinse, repeat.

    Accessibility for Beginners: As one who came here with no CS background, and little experience with what one might characterize as *nix-ish documentation (which, in my continuing view, is generally highly valuable for readers who already have a broad general grasp of any particular topic and unspeakably obtuse for the newbie), I found much of the standard documentation (perldoc -f ..., perldoc modulename) obtuse in the extreme.
    Today, some years later, I do appreciate how important it is for the newbie to learn to read such documentation, but I continue to believe the Perl community (and many others) could do far better than it does producing documentation for the innocent (not, not an "Idiots' Guide" but documentation that by structure and language serves as a foundation for further learning.
    Our Tutorials section seems to me to provide a model; perhaps some of us should develop tutorials on topics even more fundamental than appear there now.

    Welcoming to newcomers? I'd stand this one on its head. How can we better help newbies to avoid the pitfalls that sometimes win them caustic corrections?

    If a neighbor wants to borrow my chainsaw (not allowed, period) or a cup of sugar, I expect that neighbor to make the request in accordance with some cultural norms:

    • Don't ring the bell at 2 a.m.
    • Don't suggest by the manner of the request that I have an obligation to respond affirmatively (and, especially, don't suggest that I should run to the store and buy some sugar so they can "borrow" it).
    • Explain clearly what it is they want to borrow. Asking for a "some sugar" fails my test of adequate definition in the request; asking for a cup of s white granular substance fails as to particularity (and reason).

    If my neighbor were a newcomer to earth, and I were exceptionally well-disposed, I might manage a courteous explanation of how one or more of the above falls short of acceptable conduct on my doorstep. Otherwise, I believe that I'd be well justified in asking the would-be borrower to come back after 7 a.m. or with a more comprehensible request. And if said neighbor assumed that I owed him/her a cup of sugar just because that neighbor wanted it, I'd not feel at all badly about suggesting (forcefully) that the neighbor never darken more door again without having learned to distinguish between their wants and my obligations.

    Yes, we sometimes are brusque or worse in response to an incoherent question or unreasonable request, but it seems to me that most newbies (well, those who stick around for a bit) tend to take the reasonably courteous correction quite well, and most demonstrate that they actually benefited from the learning experience.

    Duty calls. Stay tuned for updates!

    Update: Upvotes in this thread will not necessarily reflect agreement with any particular proposal nor endorsement of that proposal's feasibility but rather will be cast for well-reasoned arguments.

      Well said, and we are in agreement, for the most part. Except for the appearance issue, on which I'd just like to address three things here.
      1. The desire to improve the site's appearance doesn't arise from a concern solely with appearance. It arises with a concern that appearance should be at least considered, rather than dismissed out of hand because content is more important (which we are in complete agreement on). If changing the appearance were to degrade the quality of content in any way at all, I would be totally against it. But I think it's possible to have both.
      2. You're right, what's current now will be passe in the future. But that's part of the problem: The fact that the site doesn't change is noticed. It makes it look like nobody cares enough, or that the site is not important enough, to warrant having its look-and-feel updated every few years. Also, "if it aint broke" is an irrelevant argument to the newcomers unfamiliar with the community. The site just looks like it's old and nobody cares. That's incorrect of course, but I feel that's the impression that's made.
      3. Making the appearance modern does not require flash, "fancy" images, or AJAX. The default site already loads an image largely for humour value. That same bandwidth could be used for a sprite table, rendered using CSS (just for example). It does involve taking into account best practices on usability that have been developed over the years. If you've read Steve Krug's Don't Make Me Think, it should be quite apparent that this site, in fact, requires quite a bit of thought. That might have been the norm in the late nineties, but not anymore. As I said, the actual process of streamlining would take some effort, but I think it's at least worth considering.
      That's my $0.02. When all is said and done, this isn't the most important thing to address out of this thread by far. I think more functional and content-oriented ideas should have more weight, but I wanted to make my position more clear.
      First and foremost, I vehemently disagree with those who feel we should change the "look and feel" of the Monastery, in pursuit of something "flashy" or "modern." "Don't fix what ain't broke" is valid advice to those who concern themselves solely with appearance. Being au courant is perhaps a good thing if one is peddling widgets, but it requires an unnecessary investment for a community dealing in knowledge, like this one. Further, being "up-to-date" (another phrase often used by advocates of a new look) is transitory. Today's up-to-date is tomorrow's passe.

      I must say that I disagree. Look and feel has a huge impact on the usability of the site. Also, improving the layout is not fixing. A modern looking site does not have to compromise the content in any way. I have to admit though that the designing of the PM user interface does require vision, skill, time and thought and can not be considered to be a simple task nor for the faint hearted. Making PM a better place is a worthy target and it should be the aim of every monk.

      I also strongly vote for adding more markup and linking information on the node editing page. It's cheap and easy to do ;-)

      --
      seek $her, $from, $everywhere if exists $true{love};
Re: Making Perl Monks a better place for newbies (and others)
by mr_mischief (Prior) on Mar 18, 2009 at 22:05 UTC
    There is a certain risk one takes when skimming for material rather than reading for comprehension. It seems you've taken my discussion of TinyMCE out of context here.

    What I actually said was:

    TinyMCE might actually improve a few things for a few people. However, most of its utility would not be useful for a PM-like site. It requires additional complexity in the node editing pages. It takes additional bandwidth to serve the JavaScript for it. The best feature of TinyMCE for a site like PM is the automatic paragraph breaks, which are easy to do in the code for the node engine.

    This was in direct response on a point-by-point basis to cosmicperl's assertion that "Easier to use interface (TinyMCE)" was a goal for a site friendly to new users.

    I specifically stated that while TinyMCE might be some help (the part you mention here) that most of the features it offers would not be useful here. Most of the complexity, therefore, would be for not much benefit. The best feature, as I said, of TinyMCE for a site with text content such as PM would be automatic paragraph breaks. I even mentioned that would be simple to do in the node engine without any JavaScript. Slashdot for example has a mode in which two consecutive newlines get straightforwardly translated into a paragraph break.

Re: Making Perl Monks a better place for newbies (and others)
by RyuMaou (Deacon) on Mar 19, 2009 at 19:58 UTC
    Wow, yeah, that was a great compilation of all, or at least most, of the issues. ++ indeed!

    I think "look and feel" are very subjective issues and, unless PM became unusable as a result of the redesign, I don't think I care much one way or the other about cosmetic changes.

    The "making PM friendlier to newbies" issue, though, I think is not that much of an issue. Sometimes, answers can be abrasive, sure, but mostly, I found this place no less friendly than anywhere else on the web. In fact, I think PM is less hostile than some places I've been! Granted, I try to do the basic leg-work upfront so when I ask a question I don't sound like idiot, but I learned to do that because of the harsh comments I read.
    I suppose if there was a section specifically for basic tutorials or people who specifically hadn't read a Perl book or any kind or something like that, it wouldn't be a bad idea. But, other than that, I honestly don't think it's all that necessary.

    So, there's my two cents, for all that's worth in the New Economy.
Re: Making Perl Monks a better place for newbies (and others)
by ig (Vicar) on Mar 19, 2009 at 22:17 UTC

    I wonder if an RT queue might be a good tool for keeping track of requests and suggestions. It works well in other contexts and requests could be linked back to nodes on PM for discussions.

    A few items from my wish list:

    • I too wish there was a preview on the update page.
    • I wish there was a preview on the scratchpad edit page.
    • I wish there was an easy way to find responses to my own posts. An optional filter on Newest Nodes so that it only showed nodes in threads I had posted to would be very nice. A count of responses on the list on Perl Monks User Search would also be helpful.

    update: actually, there is a preview on the scratchpad edit pages - I just didn't see it because I never thought to look down for it instead of up top where it is on the comment edit page, and it was always just off the bottom of my screen.

      While wishing, may I/we have some sort of killfile feature please? Such a feature would allow to avoid display of nodes based at the very least on title (regular expression, possibly length) & author; if feeling generous, possibly on the length of the body if not content (regular expression based).

        Hiding all posts by an author can be done through CSS, by using for example the .pmnote-5348 rule to highlight or hide all posts by user 5348. We Stylin'! and PerlMonks CSS HOWTO also contain CSS references.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://751522]
Approved by jettero
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (10)
As of 2014-07-23 11:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (140 votes), past polls