Your first rodeo with WordPress

  1. Taylor59

    I viewed Matt's 2012 and 2013 State of the Word addresses and both years he mentioned the attrition rate of WP.
    I think a quick start guide would be a good idea for new users.
    It could be something like,
    Your First Rodeo with WordPress or
    Your Quick and Dirty guide to WordPress
    or Down on the Farm with WordPress.
    It could be info available after the installation process and it would only be 5-8 pages long. Make it downloadable incase new user wants to save/print it to follow along.
    It could highlite all the most basic settings to get your blog/site up and running.
    Then as they were using it, if they wanted to get more indepth, there could be links to the setting to learn more.
    Each setting could have an associated item: For example if a rodeo theme was chosen, the site would be the arena. A cowboy could represent the user, the bull would be the appearance setting, the rodeo clown could represent the pages etc....
    The documentation is stellar now but there is so much there it is hard to know where to start. Even the topics Getting Started and New to WP contain so much for a new user.
    This user guide would be designed to get the new user up and running and not get discouraged and walk away.
    Thank you.

    Posted: 4 years ago #
  2. marsmith

    1) Matt who? I'm new, but without a username or link to his post, I'm lost. I would, however, like to follow your reasoning, so I would like to know where this post can be found.

    2) I'm new, but not new to computing.
    The single best thing for usability: Make the documentation halfway close to real documentation, for any enterprise software.
    A good example: I just read a few documentation pages that discussed features that I know recently changed (in new releases). Yet none of these doc pages are time stamped, e.g., "Date last changed:______" or "Applies to Releases 3.5, 3.6". That a user cannot double-check doc version to software version makes it largely unusable.

    Posted: 4 years ago #
  3. Ipstenu (Mika Epstein)

    Matt generally means 'Matt Mullenweg'

    State of the Word 2013: http://wordpress.tv/2013/07/29/matt-mullenweg-state-of-the-word-2013/

    You can extrapolate where 2012 is ;)

    We're working on Documentation. there's a whole volunteer team.

    Posted: 4 years ago #
  4. Taylor59

    Thanks Ipstenu!!
    Yes, Matt is definitely Matt Mullenweg
    Didn't realize there was a volunteer team working on this. I would be interested in keeping track of how this is going or somehow being involved.
    Thanks again for your reply to my post.

    Posted: 4 years ago #
  5. Ipstenu (Mika Epstein)

    Come on over to http://make.wordpress.org/docs :)

    Posted: 4 years ago #
  6. marsmith

    Thanks to those who responded for making me feel welcome.

    Re: "Come on over to http://make.wordpress.org/docs :)"

    I wouldn't rule that out.

    I'm a rare bird in one respect--I'm an ex-product manager and (currently a) marketing guy who doesn't hate writing doc. I actually volunteered a couple times to write "small" (100-page) manuals, when I worked in enterprise software product management. However, I'll wait until I actually know something substantive about WordPress before giving advice.

    However, I would like to ask one question now, to get a feel for the lay of the land.

    The short version of my question:
    Does whoever it is that controls the WP source tree require the sort of information at code check-in that "real" companies like Oracle do?


    I've seen enough already to conclude that applying a few best practices could make a big difference. But the changes I have in mind aren't possible if what I've seen so far is representative of the general state of things for WordPress.

    Specifically, in a couple of V3.6 instructional videos I've seen, the presenters have been surprised by new V3.6 behavior i.e., different from V3.5. I assumed that there wasn't was a place where all the user-visible changes are cataloged. I reasoned that, if such a source did exist, surely the instructors would have done their job, perusing that source prior to cutting the video.

    My conclusion was easy to make. It's hard enough when developers are getting paid for their work to get them to document user-visible changes. Open source must be worse, I reasoned.

    On the other hand, the instructors in the videos I watched could have been lazy...

    So, what's the situation?

    Are developers required, as part of code check-in, to leave enough info lying about? Or must someone seeking to improve documentation first resort to software testing to cull the raw information required to merely START writing?

    Mark Smith

    Posted: 4 years ago #

RSS feed for this topic


You must log in to post.

  • Rating

    1 Vote
  • Status

    This idea is under consideration