Multisite isn’t simple enough for users. And it shouldn’t be.

16 Comments

A weekly editorial, from Ryan Imel the editor of WPCandy

This may sound funny coming from someone who has written tutorials on setting up multisite and presented on the topic too, but: WordPress Multisite is not simple enough for users. Just anyone can’t enable it and run it, as well as administer it correctly. For those users who gravitate toward WordPress’ simplicity, multisite doesn’t really follow suit.

And that’s a good thing.

Every time I have given my presentation Understanding WordPress Multisite, someone has pointed out that the process of enabling multisite isn’t very simple. To be fair, while it’s not a 5 minute setup like WordPress is notorious for, I would argue that it’s not complicated.

Most users shouldn’t be using multisite. Most users should be blogging, not setting up a network of sites that they have to be responsible for.

But it’s no WordPress installation. It’s a little tougher, particularly the first time around. Enabling multisite involved editing the wp-config.php file and .htaccess files, which most WordPress users know nothing about.

Most users shouldn’t be using multisite. Most users should be blogging, not setting up a network of sites that they have to be responsible for. Running a network brings with it increased responsibility. WordPress security, backups, and proper administration become much more important. The effects of mishandling these things on a network-wide scale are much worse than with a vanilla WordPress site.

Enabling multisite could be easier to do, and it may in fact end up getting easier over time. Everything gets easier over timeβ€”it’s the way of things.

In a way, I hope enabling multisite doesn’t get much easier. Only those willing to take the extra time to read and pay attention to instructions should be able to run WordPress multisite. And for most users, that’s just not them.

16 thoughts on “Multisite isn’t simple enough for users. And it shouldn’t be.

  1. And also – just imagine if it were one-click in the backend?

    How many users woudl click that button, then FLOOD the support forums screaming their subdomains don’t work? that’s advanced server setup. the hurdles are there as checks to make darn sure you read up on it.

    just like the reasoning behind why custom post types aren’t built in the backend, I am all for this not being easier. “Most” users wind up misusing it, if all they wanted was something simple. I’m seeing questions now for people who only want two blogs. One int he root and one in a folder off the root. this can be done in one install, sheesh! πŸ˜€

    Man. We really need to wind up at the same wordcamp.

    • I’m sure the onslaught in the support forums would be a mighty one indeed, and you would catch the bulk of it!

      In a sense, is there a point of diminishing returns, when it comes to making things easier? Particularly advanced things that shouldn’t really be done by those that aren’t willing to accept the responsibilities. Multisite and custom post types are good examples that make this tension evident. Trying to think if there are others…

      Re: WordCamp, I’ll be at Louisville next week, and trying to do Phoenix in January. Let me know where you guys will be next, I’ll plan on it!

  2. On the one hand, I think you are totally right, but I can’t help but thinking that this “don’t get any easier lest the idiot assclowns get their hands dirty” contradicts the very principles that WordPress was created on.

    Don’t misunderstand me, I like elitism as much as the next person (I am a Mac user, a film snob, a label whore and I like to take smug satisfaction in being more technically literate than almost everyone else I meet), and I understand the very real support reasons for not wanting to make something easily exposed or a one-click option.

    Having said that, I fundamentally believe that the way to solve that problem — and it is a problem, I’ll grant you — isn’t to disregard the need for real UI and UX work. I’m not saying you are arguing that — I really don’t think you are — but too many people confuse a solid UI or natural user experience with “being easy” rather than being right.

    This, I think, is one of the downsides when a more technical project like MU gets merged into a consumer facing web app like WordPress. Yes, it makes sense technically to share the codebase and keep it all the same, but the at the same time, when you make the two products one, I have a hard time with the argument that all the MU — excuse me, multisite — features should be hidden and have to be kludgily enabled to work. And it is a kludge. It might not be hard, but it’s inelegant and there are better ways to do it.

    The real solution — the only real solution — to preventing people from flooding forums asking about features they don’t need and will screw up enabling is proper education. That’s it. That doesn’t mean you stop all of the people who come to you for help. That doesn’t mean you stop all the idiots from trying to enable multisite without needing it, but to me, that’s the only solution. Have better documentation, better explain WHAT multisite is and who needs to use it.

    Same for custom post types. The biggest problem with CPT was that it was explained in a really shitty way all the way around. It was NEVER explained properly and theme developers, plugin developers and end users never got the idea that was intended by the core team. That’s why custom post formats are here — in large part.

    My feeling on WordPress is this: If you’re going to tout simplicity and ease of use and development, you can’t have it both ways. You can’t make some stuff hard to find or enable and other stuff straight forward. That’s not WordPress. That’s not why WordPress has been so successful. I might criticize WordPress, I might prefer the technical merits of other CMS solutions — but WordPress is WordPress because it is consistent. Lose the consistency and you might as well go to Drupal and get a better framework.

    Educate users and developers about what features do and who they are designed for. A bunch of confusion would be solved if there was a well-written FAQ on multisite that explicitly states who it is not for and describes very specific scenarios for when it should be used.

    If you obscure usability to try to pre-select your user base, you run the risk of having no end users. If multisite were a distinct project or spin of WordPress, I’d be more inclined to agree, but given that it is a feature of a consumer-focussed project, I think it’s dangerous to try to weed out the idiots by making stuff harder than it should be. The idiots are already here. The only way to improve the situation is to educate.

    • Christina writes, “You can’t make some stuff hard to find or enable and other stuff straight forward. That’s not WordPress.” Very true, that’s Windows.

      I had the good fortune to see Ryan present on WP Multisite at WordCamp Detroit. I see where it makes sense for certain people.

      I’m as much of a geek as the next tech gal (or guy), and I have no fear of the command line or editing files. I understand the benefits to those who manage multiple sites, and I will set it up for some of my clients (although mainly it’s a way to make my life easier).

      I like learning more about how and why something works, which is why I got into this business in the first place.

      It took me about 45 minutes to follow the instructions at the WordPress Codex to install a test of multi-site after seeing the introduction. Certainly it will get faster the next few times I do that, but I would certainly appreciate a more streamlined installation process.

      Enough background.

      I agree that more education is the right solution.

      Sadly, many people don’t want to learn how something works. How many people have absolutely NO CLUE about how to change the oil in their car? Or why they should? The automotive companies (and myriad oil change centers) work hard to educate people about the need for maintenance. Yes, I can change my car’s oil (and have), but I choose not to because the tools that make it easy are too expensive and I prefer to use my time in other ways.

      Making WP multisite readily available is akin to putting the keys to a Saleen Mustang in the hands of someone just starting driver’s training. They make get from point A to point B quickly, but the potential for a serious accident is much higher than in a base model Ford Focus.

      People won’t die from a website crash.

      This may sound cruel, but the best incentive for some people to get education may be for them to wreck their website. There are plenty of people (like the ones commenting here) who can help them pick up the pieces.

      • “It took me about 45 minutes to follow the instructions at the WordPress Codex to install a test of multi-site after seeing the introduction. Certainly it will get faster the next few times I do that, but I would certainly appreciate a more streamlined installation process.”

        Just as a point of reference, you can get the current method of install down to under 10 minutes. I’ve done it. I do it often. I think that fastest was 5 minutes for a multisite install, where a single WP install I can do in 3.

        On a familiar setup I’ve timed (and tweeted) setting up a new install and mapping a domain to a sub-blog in 15 minutes, not counting DNS propagation. πŸ˜‰

        Not bragging, just giving anecdata that with experience, the current method CAN be done quickly.

      • Good points Todd. Heck, I’ve crashed a number of multisite installations. Anymore, I feel like if I’m not breaking WordPress sites every now and then I’m not really pushing myself.

        I think you pointed out one of the primary issues, which is that many users don’t want to learn. Or at least, they typically aren’t willing to take the time to learn. The challenge is how to best educate people that may not really want to be educated.

    • Good points. I think you spoke for the other half of my opinion on this pretty well :).

      A couple of things I thought of while reading this. One, I think the issue is more complicated that what WordPress does or doesn’t do—because a large part of how multisite functions depends on the hosting setup. Since that can’t be relied on to any degree I think it hamstrings the effort to make it simpler. Until hosting for the average consumer gets better (which I think we can all agree, it can stand to be way better across the board) I think this will hold back just how simple the multisite installation process can get.

      Second, I do think it’s acceptable, at least, for certain features to get easier on a slower time table when they are arguably niche features. I use custom taxonomies, custom post types, custom taxonomies for custom post types, multisite, etc. But I am part of a relatively small percentage of WordPress users. It’s more important to make the process of internal linking (for example) a better experience than improving multisite, because it’s serving a larger group of users. In that sense, I wonder if the difficulty of multisite is really pre-selecting a user base, or just a reflection of the reality of use cases.

      Pretty sure we agree, in general. We just each argued one side of the discussion. πŸ™‚

    • “A bunch of confusion would be solved if there was a well-written FAQ on multisite that explicitly states who it is not for and describes very specific scenarios for when it should be used. ”

      I actually write this often, and update the codex as much as I can. anyone is welcome to add to the codex in WordPress as well. πŸ™‚

      There are plans for a handbook, and I’m even authoring a section in a REAL book on it! πŸ™‚

      the instructions in the codex, the sticky in the multisite section in the forums – my blog which deals specifically with multisite – all those can be there, but there’s still a percentage of users who do not read it. And like a previous commentor said, it’s usually the ones who don’t want to learn. they want click & go & easy.

      It’s just not.

      • You’re absolutely right — it’s not click and go easy and I don’t think anyone expect (or frankly, wants) it to be that way. I also think you do a great job of adding documentation on the site and the Codex.

        What I guess I would suggest would be to have something BEFORE you get to the Codex — (which I know is being overhauled but currently causes many people, well intentioned or not, to glaze over when looking at it. That’s not to pick on WordPress, I think documentation is one of the hardest parts of ANY technical project) — a feature landing page, so to speak. I don’t know if that would deter the crazies or not, but I’m just saying, I think you are going to have the idiots regardless of how convoluted the install process is.

        As Ryan points out, a huge part of the multisite barrier is with doing all the stuff with your host. If you don’t manage your own server or have knowledge of where the tools are and what the options are for your host, you won’t get that far anyway — and that’s something that can’t really be fixed by WordPress.

        Again, I don’t think we’re really disagreeing – and please don’t see this as me criticizing those that do so much for Multisite — I just think that sometimes making something “usable” is confused with making something “easy.” The two ideas aren’t one in the same. As an example, Apple’s Xcode is a very, very usable IDE — especially in the 4.0 preview — but the fact that it has good UX and the controls, features and layouts make sense doesn’t mean that someone who has never done object-oriented programming will suddenly be able to use the app. If you don’t know Cocoa or Objective-C, it’s not like Xcode will teach you.

  3. Some things you can’t really teach. Website administration turns out to be one of those things. And why can’t you teach how to administer a website? Because it’s not a thing that follows simple instructions.

    To run a website, you have to actually understand and grasp each part of the system, what it does, and how it interacts with other parts.
    You have to understand how Apache configuration files work.
    You have to understand what rewrites and htaccess’s actually are.
    You need to understand how to read the documentation, and believe me this is indeed an arcane art.
    You need to understand what CGI is, how it works, and how it applies to using PHP.
    You need to understand PHP configuration and INI files.
    You need to understand unix-like systems, file permissions, repositories of all kinds, apt or yum, .deb or .rpm.
    You have to understand DNS, how it works, how BIND works, how domain names work.
    You have to understand IP addressing, and how domain resolution works with regards to Apache and Virtual Hosting.

    And that’s just the beginning. Running a web server is all the complexities of running a “server” added to the complexities of running a “secure” server added to the complexities of running a public facing website.

    This is often way too much for somebody who just wants to write some words to handle. What’s more, it’s *definitely* too much to ask somebody to teach you how to do.

    Certain kinds of people like myself can pick this sort of thing up easily. I have a degree in Computer Science, I’ve worked with *nix systems for 15+ years, and I’ve been programming systems of all sorts for 25+ years. It’s not really a problem for me to sit in front of a new system I don’t understand and learn it in the space of a few hours.

    But that’s me; I’m not “normal”. So when somebody asks me “how do I make X work” and the answer is “I have no idea, you sit down and figure it out by reading the documentation and learning something”, then that answer really often doesn’t satisfy. The people asking that question are the kind of people who probably can’t learn it on their own. They don’t have 20 odd years of background to draw upon. And unfortunately, this sort of stuff is arcane knowledge which requires at least some background to be able to do.

    I can’t tell a blogger how to run a website. Not really. It’s too much explanation, it’s too much effort (especially for free). The best I can do is give small pieces of knowledge for specific questions.

    And that’s why multi-site will always be “hard”. Running a multi-site install involves a whole lot of knowledge outside of WordPress that not only I don’t know off the top of my head, but which takes a hell of a lot of background knowledge to understand in the first place, much less explain. A newbie simply can’t learn it all in one go.

    • But making it usable doesn’t equal making it easy — that’s my only point. People who don’t get it still won’t get it if it’s less of a pain in the ass for the people that do.

      My only point is that to say, “it has to stay hard to keep the dumbasses out” misses the point (I thought) of WordPress.

      Teaching also doesn’t have to be “this is how to do X” — it can be educating, “unless you know X, Y, Z ignore this.” Good education is as much about identification as it is instruction.

Comments are closed.