For years, I’ve been using PayPal and although I don’t hate the service as much as many (in fact, I have very few complaints), I really dig Stripe for its simplicity, design, and ease of integration.

On top of that, I’ve used it in a variety of client projects but I’ve never actually done anything with it myself.

But this past weekend, I finally had the opportunity to integrate Stripe into a page on my site, and I used the WP-Stripe plugin by Noel Tock.

This morning, I tweeted the following:

This tweet sparked an excellent conversation in WordPress user interface design.

I’ll be the first to admit: I’m one of the most critical when it comes to theme and plugin developers deviating from the WordPress user interface. A fellow tweep (and WooThemes developer), Coen Jacobs brought up an interesting point:

Which is a fantastic question. Though you can read the entire conversation on Twitter, I thought I’d summarize my thoughts here:

Noel’s balance of design and the native WordPress UI is fair. Perhaps the biggest deviation is the font and the table of purchases.

But I’d say that when there’s no example on which to base your work (such as displaying results from a Live and Test environment), you have to forge your own way.

I think Noel has done a stellar job of that.

When building products on top of WordPress, there are a finite number of elements that we can use for reference – various input types, tables, tabs, fonts, etc. But when there’s nothing to reference, it’s the developer and/or designer’s responsibility to handle the solution as elegantly as possible.

In the case of WP-Stripe, you have the ability to toggle between the Live and Test environments and you can view purchases from both. Currently, there’s nothing like this in the WordPress admin.

As such, it had to be created:

WP-Stripe

One of the downsides of having such a lively, open, and welcoming economy is that you have to accept the good with the bad. This means that for every well-architected, beautiful WordPress-based product, there are going to be those that are less than stellar.

As developers and designers, it’s our responsibility to make sure that we’re adhering to the native WordPress admin experience. When faced with a new challenge, we need to handle it elegantly – not just take the shortest path to delivery.

Of course, that’s just my thoughts. Would love to hear what the rest of you think about this.

Category:
Articles
Tags:

Join the conversation! 22 Comments

  1. While I’ve seen the work of Noel on happytables (which is amazing and inspiring), I’m more of a fan of sticking to the design unless it is with a completely broken usability. There is a chance that some of his work is to be noticed by the core guys and embedded into 3.6 or 3.7 which is worth a try as long as it provides some extra usability (like less clicking, better management for non-experts and more).

    • I agree, when you show how something can be done there is a much higher chance you will see something like it in core. However, WordPress has been changing her administration panel looks so often in the past years, that I hope they settle for how it is now and only improve it.

      • From the looks of it, the current WordPress UI is generally where it’s gonna stay. Following Trac shows enhancements but nothing has drastic as we saw from 2.x to 3.x.

        Anyway, see my comment to Noel to see where I stand with experimentation.

        The short of it: it’s good to do it, but I think it needs constraints.

  2. IMO I think WordPress should have a UI Kit and Style Guide like iOS and Android. There needs to be classes for toggles, etc for developers even though the core might not use them.

    Andrew Ozz hinted that this is coming in a bug I filed with the last beta. http://wordpress.org/support/topic/backwards-two-column-layout-support-in-34#post-2873687

    Things like WP List Table class need to be public and not marked as private as well.

    In the example above the author has recreated a UI element that already exist, the vertical tabs. From my experience the biggest issue is this is potential conflicts. All it takes is for someone else to bleed bad css onto your settings screen. If the author had used the built css classes you could avoid this since most developers build plugins to work with the native UI and can spot a conflict in development.

    • It has – http://dotorgstyleguide.wordpress.com/

      Agree, Noel could create similar settings page with existing styles and that would fit core UI much better.

      Everyone could use WP List Table class, but on his own risk, because as private class it might not be backward compatible on update and that could brake your plugins.

      • I think that styleguide hasn’t been updated for quite a while now and there are a bunch of images 404ing in the main articles like ‘Navigation’. That’s too bad for such an important document for the CMS WordPress has become.

        • Guides are important – be it for documentation, usability, styles, whatever – but one problem, at least in my opinion, is that in documentation is over looked in open source software.

          Because it’s open source, people tend to think of open source code when in fact it’s important to view the documentation as a literal part of the product just as much as any given feature.

          Unfortunately, this doesn’t happen enough so it gets left in the dust with the core application moving forward.

          I know my local developer’s group has discussed spending an evening working on the Codex to do exactly this.

          Regardless, perhaps greater awareness on this needs to be raised. How we do it outside of the typical WordPress-programmer-type is a mystery to me :).

    • TL;DR: I generally agree with your point, but there is room for introducing new styles for experimenting if you do it the right way.

      The potential conflicts *can* be managed if the elements are properly classed. I know this from first hand experience, but this is definitely *not* the norm.

      Again, because WordPress has such a lively economy we have to take the good with the bad and though I typically agree withs ticking as tightly as possible to the WordPress-core UI, experimentation like this isn’t bad if it’s done the right way.

      Unfortunately, this isn’t the most common practice and we’re instead left with plugins and theme options that junk up the margins, paddings, and fonts of the admin UI.

  3. Thanks for the post, always an important discussion.

    I think it’s easy for people to take a plugin like this out of context. On a basic level, it matches the overall color scheme (being light gray and white, you’ll also notice the pushed in table header will match the left nav quite closely). Apart from that you’re looking at a few tweaks, mainly that posts aren’t transactions and can’t be treated that way. Please see the following for more on those thoughts:

    http://www.noeltock.com/web-design/wordpress/custom-post-types-are-not-posts/

    More importantly though, it is my opinion that we need to experiment often with everything related to UI. I have this chance with WP-Stripe because 1) it is not the official Stripe plugin, and 2) it is not relied upon a large user-base such as woocommerce. If it were either, I’d tone it down, but it isn’t. It’s a plugin with less than 3000 downloads, a great place to experiment, the same as:

    http://wordpress.org/extend/plugins/hammy/screenshots/

    If we’re not trying to break admin in different ways, we’re not really going anywhere. Along those lines, it’s also important that we get involved on a core level (something I’m guilty of not doing) here: http://make.wordpress.org/ui/

    Just my 2 cents :)

    • I tend to agree with you that experimentation is important, but I think it needs some parameters; otherwise, you get these crazy options pages or busy plugin menus that do a better job of confusing the user than anything else.

      To me, your work on WP-Stripe is an great example of experimentation without drifting too far from the core.

      But you’re right, at the end of the day you absolutely have to know your core audience. But this raises the question: if WP-Stripe grows to an excessive user base or happens to take off at an exponential rate, then do you reign in the experience so that it’s tighter with WordPress?

  4. Well I spent a few days at Stripe last week and we discussed how the official Stripe plugin would look like, so I know for a fact that I would never grow to a large user-base in the long run. I’m trying to help charities with this plugin, not necessarily every single business out there.

    I’m still not too bothered by slight UI differences though. We have bigger fish to fry to be honest (plugins with bad security, conflicts, UX problems etc.). In other words, I’d look at the UI again when I hit 50k downloads.

    • Congrats on working with the team. I’m a huge fan of theirs – sure you guys are gonna come up with something awesome.

      And you’re right, there are bigger things to worry about. But still, I dig the work on the design and am eager to see what you and Stripe come up with.

  5. Glad to see this discussion.

    The challenge we’ve been running into lately at tri.be is when core wp patterns as applied to plugins simply fail usability tests. With an avg of 3-5k new users a week (http://wordpress.org/extend/plugins/the-events-calendar/) the first experience is a huge aspect and we’ve begun to refine it carefully.

    As a basic example, in our last test, only one first-time user easily found the plugin settings panel. It was placed in the WordPress settings menu as dictated by the ux team guide. The rest of the users simply never found it or took a ridiculous amount of time. We moved it to the cpt events submenu and in the next test everyone found it immediately.

    When talking to the core team at wcsf, I got varied responses. Jane said that it belongs in the settings menu and that the user just isn’t finding it because plugins are doing all kinds of things. Otto said that the cpt submenu was the right place and that there isn’t a defacto standard but rather that it depends on the plugin and what it does.

    I’m not I totally agree with either opinion. WordPress plugins are a major part of the workflow for the average user (I think most sites have 5+ plugins on). For users to have a cohesive experience, they need somewhat consistent patterns. That said, those patterns have to pass muster.

    • I love the fact that you covered the results of your usability tests. Fascinating stuff.

      You hit on the core issue with this:

      For users to have a cohesive experience, they need somewhat consistent patterns. That said, those patterns have to pass muster.

      There’s obviously room for this to grow and I think it’ll get there in time as WordPress continues to grow and people began to treat products built on top of it as actual software rather than small scripts to enhance some aspect of blogging.

    • “Jane said that it belongs in the settings menu and that the user just isn’t finding it because plugins are doing all kinds of things.”

      I find this as a major problem coming from a ‘UX designer’ as Jane describes herself in her Twitter bio. I don’t understand why she makes the excuse that a user isn’t finding it because plugins are doing all kinds of things. This shows the blatant need for more requirements as far as plugins are concerned.

      Now, I’ve been using WP for quite a few years and when I install a plugin I can expect the settings panel to either be somewhere within the CPT menu that the plugin creates or within the Settings menu. But….were I a first time user I would surely expect to find settings within the CPT menu.

      Your test alone proves that the current Settings menu placement just doesn’t work as users just don’t expect the option to be there. But this also leads to the larger problem of the entire UX/UI of the admin section. If you’ve watched any of the user tests setup by lessbloat on the Make UI blog: http://make.wordpress.org/ui/tag/discovery-cycle-2/ you can really see just how confusing it is for a first time user to WP to navigate around.

  6. You nailed it Tom. I feel like WP has the opportunity to stop using pull ups and wear big boy undies. The question I asked Matt at the keynote though is key: who the heck is going to define core usability guidelines? Does the core team do that? Do the most popular plugins drive it? Does automattic get involved? Ultimately, some form of cohesive direction is needed.

    btw – my article on the topic came out on smashing today > http://wp.smashingmagazine.com/2012/08/08/help-us-help-wordpress

    • I don’t necessarily think that WordPress is in a situation of pull-ups versus big-boy undies more so than there are higher priorities right now.

      Case in point, they have the 3.0 UI overhaul, mobile compatibility, and now retina compatibility to introduce (all of which are covered in issues in Trac).

      Providing UI/UX guidelines for Theme and Plugin developers is something we really need because it keeps us from having to debate and where and how to do certain things.

      For example, I view guidelines like an “API for design.” There are a handful of ways to serialize options to the database but we have the Settings API. To me, that’s the end of discussion – use the Settings API, you know?

      Personally speaking, I think the Automattic should be driving the UI/UX guidelines with input from those who wish to get involved via Trac (after all, this is open source! :)

      There are a number of people already pushing for improvements in both UI and accessibility (such as Helen Housandi) who are opening and contributing to tickets around this very topic.

      Strides are being made, but there’s room for cohesion. Perhaps the #wpcs guys will touch base on it, too.

      Regardless, we gotta continually focus on this stuff. My team and I did usability testing during the last release of our product and it was extremely enlightening – so much so that we couldn’t resolve all of them for the initial release.

      Seeing you guys do the same is awesome (and killer post on Smashing today)!

  7. I promised I’d take a look and comment, so here goes! Initial disclaimer: I represent myself, not the WordPress project at large, and while I am heavily involved in UI for core and am currently helping to lead and guide the group in the 3.5 cycle while Jane is taking a step back, I am a developer by trade and generally very pragmatic.

    My overall view at the moment is this: in the pursuit of powerful tools and a base on which developers like to build, we have lost or ignored the sense of workflow for the end user. Many of the problems I see in the user testing that’s been written about would be helped along by creating funnels for various workflows and better new user experience (NUX). In fact, take a look at the instructions you/we have to write for the user tests – why aren’t those flows obvious to the user in the first place? Written instructions are often compensation for a lack of something else. Achieving workflows isn’t easy by any means, but it is what I’ve been seeing a need for over and over again. I don’t have an answer as to how to solve it, but I am a believer that identifying an issue is a huge first step.

    On the initial subject of the post (the Stripe plugin interface): I know that I like to see experimentation, and there’s no effective way to move forward unless experiments are happening and there’s the possibility to open your eyes to more ways of accomplishing the same task. It’s very easy to get lost in what exists when it’s your everyday work. That said, I think that it is still important to consider the common design patterns within an interface. In this case:

    • The page title: convention is grayscale icon + dark heading, as opposed to a lighter bold heading alone.
    • The horizontal tabs: there is an existing pattern in the UI that, while not perfect, could at least inform the usage here. I do like dimming the inactive ones with a gray background, for what it’s worth.
    • The amount of border-radius
    • The convention that destructive actions (delete, trash) should be indicated as being destructive, which in most places in core is as a red link.

      Allowing these things to inform experimentation would go a long way toward providing a cohesive experience while still driving interface patterns forward. I certainly don’t think core provides a pattern for everything imaginable, and I can’t imagine that it ever would, because we are not so vain as to think we can anticipate anything that might be done. However, I think a common goal for all additions to any extensible piece of software should be to have a consistent interface – this generally helps users in that it lowers the learning curve by providing at least some familiarity.

      As for the comments, I have some questions:

    • Shane: where is the guideline that a plugin’s settings page must be under the Settings menu? This is a genuine question, not one being asked just to be contrary. My own personal feeling here is that any guideline in that regard, written or unwritten, is probably related to not having plugins create top level menus unnecessarily. An events/calendar plugin is surely going to have a top level menu, and so in that case it seems to me that it does make sense to put the settings there. You asked individuals, and so you are getting individual answers :)
    • How does one imagine UX guidelines being written or outlined? How do we communicate in semi-permanent words how to provide a usable interface, short of writing a book along the lines of, say, The Design of Everyday Things?
    • Why would Automattic be directly involved in driving UIX in the WordPress open source project? Are you saying this because you think that they have the resources or because you see Automattic as a direct influence on WordPress.org?

    In terms of working on core, we are thinking about how to better relate the developer-y terms of options, settings, and preferences, and whether or not we are confusing end users by continuing to use all three terms in the interface. We are also exploring ways to better discover related settings on any given screen and, really, to discover anything anywhere.

    These comments seem to have veered off the path of design in the graphic sense (which I think was the original idea, based on the post itself) and into the realm of interface patterns :)

    • Love your thoughts – thanks for taking the time for such an in-depth comment.

      Yeah, the conversation has veered off in another direction that from the original post, but it’s striking a chord with many of us who are passionate about building products for WordPress and care deeply not just about shipping code, but shipping a product that’s thoughtfully considered end-to-end.

      I’m going to try to succinctly (with mild success, most likely :) respond to the points that hit home for me, but I do give a disclaimer – I’m a programmer by trade. I care about design and usability, but I’m not claiming to be an expert – it’s something that I’m trying to better about myself – so these observations are coming from that perspective:

      • Your thoughts on UIX are spot on. I’ll be honest, as a developer, I tend to rely on the Codex or existing core functionality to guide my opinion. Something like “ah, well [this type] of option or [these type of settings] are grouped like this in core, so I’ll follow suit.” Despite the fact that there may be better ways, I assume that if I deviate too far from how WordPress is currently setup, it introduces an entirely new level of complexity of users. At a bare minimum, I’m trying to keep a base level of expectations – maybe the current workflow needs improvement, but it’s what users are used to so I’d rather try to mimic what’s already there so there’s some semblance of a cohesive experience.
      • Identifying a core first step is key. In my team’s usability tests, we’ve had some people not even understand some of the terminology that WordPress uses in the dashboard let alone how elements or organized. “Index page” versus “homepage,” for example, provides a lot of clarity. It helps establish mental model because they know what home pages are on other sites; rarely do they know it doubles as the index page. As such, perhaps all aspects should be considered (or re-considered? :). We all know that the UX is the sum of the parts.
      • I view writing UI and UX guidelines less of writing a book (though there’s certainly enough material to do so) in much as the same fashion as (a) the Codex (or at least in a similar fashion) and as (b) treating UI design patterns exactly as we treat software architecture design patterns. We lay out what it looks like, the purposes it intends to serve, when it lends itself best, and when to avoid it. Granted, this is much easier said than done, but that’s how I’ve conceptualized doing something like this.
      • Finally, my personal opinion of Automattic being involved in driving UX is simply because the core development team are Automattic employees. This isn’t meant to imply passionate, capable, and experienced people from the community get a lesser “vote” or carry less significance. Definitely not. I just meant that they’re involved in Trac making sure that we’re not deviating from the vision for the core application – we’re clarifying it.

      FWIW, I’m digging this discussion – love bringing issues like this to light.

      • I think it’s really important not to mix Automattic into core development. Not all of the core team is employed by Automattic (Mark, Nacin, Jon Cave) and I believe at least one of the Automatticians is employed in a non-core capacity. Also, that makes me ask what you consider to be the core team :) Would I be considered a part of the core team, at least for this cycle? I tend toward being unwilling to self-promote, but I think some folks would say yes. What I do know is that I am currently involved in watching over everything in the UI world from discussion to patches to see how it aligns with the goals of the cycle, the general core vision/philosophy, and the possible future. I don’t even necessarily do this because I am mandated to (because I’m not, really), but because I care. Anybody can care and, therefore, anybody can participate. Open source, right?

        You can always bring up UX issues in #wordpress-ui if you want to have an active discussion – there are more folks around these days. We are also looking at what it would take manpower-wise to round up links to thoughts people have posted on Make UI every week or so. The idea is there, but the commitment isn’t just yet. We also have that styleguide I saw linked further up. It’s not open at the moment (I do not know why, I was not involved in its genesis) but I imagine we can do something to involve more people in getting it updated. Again, it’s an issue of manpower. I see lots of talk about what’s needed, but haven’t yet seen an active show of making it happen. I hope that isn’t taken as a slight – I understand how hard it is to move from talking to doing, but I still want to see more of it. So, for example, how about an outline of things that would be good to see in a UIX guideline for WordPress core, or “human interface guidelines”, as it were?

        There is a lot of confusion out there when it comes to WordPress the open source project, a.k.a. WordPress.org, and Automattic/WordPress.com. They are not the same thing, despite a very small number of personnel who are donated from Automattic back to the .org project. Let’s not make it worse.

        • Distinguishing between Automattic and the core development team is probably based more on an assumption on my part than anything else. As much as I follow news regarding WordPress and am plugged into the community, I think I let the lines blur.

          My team and I are partners with Automattic so seeing some of the same names in Trac that are in the Themer Lobby just enforce an assumption :).

          Anyway, my local developer group and I have been talking about coming up with a few ideas on how to contribute back to WordPress rather than just submitting patches to core. Perhaps this is is something I’ll bring up at our next meetup.

          I’m also interested in getting in on the conversation with this kind of stuff. Sure, talk is easier than action but I’d definitely love to help as time permits.

          Oh .. and nothing is taken as slight .. as far as I’m concerned, this is all good stuff (and yet another reason why I dig the WordPress community :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.