WP Remote is a tool we built to help manage our growing list of WordPress websites internally. Over the years, we opened it up to the public, accumulated over 50,000 WordPress websites and kept building on top of it when we found time. In the process of sporadic iterations and never quite finding development flow, it’s grown big.
At its core, WP Remote is an application to manage multiple instances of another application (WordPress) that in turn helps you manage your websites, pretty meta. Abstractions like that are something I’m typically not fond of, especially when it’s just doing one thing; Tweet scheduling, Instagram cropping, there’s a graveyard full of third party applications which end up being core features six months later.
Since I started becoming more active on WP Remote, this is something that has continuously worried me. WP Remote’s greatest strength has always been in consolidation, the ability to monitor a large number of WordPress sites simultaneously regardless of version, setup or hosting service. This unique advantage is something that for a variety of reasons will likely never ship with WordPress itself.
That said, a number of other features we provide through WP Remote (backups, audit logs) are vulnerable in one way or another. Those additional features do not need to sit outside of WordPress (in a tool such as WP Remote). From a technical perspective, nothing is stopping backups or audit logging from being a part of WordPress core, being packaged in a plugin or alternatively being managed through a third party service. We crossed the line by replicating features which were already floating around the ecosystem in different forms.
From our users perspective, these features led to duplication and potential overlap with their existing tools.
How do we go about finding our mojo again? In the simplest of ways, we unwind the few deep features we have and instead focus on many light integrations that respect existing user setups and choices.
In practice, where we previously performed backups, we will now scan for plugins or other integrations on each site individually and let that information (and related actions) bubble up. I love this construct as it carries incredible power by being solution agnostic. No one freelancer or agency manage all their WordPress websites with the same load-out, so why should we force them (or alternatively ship a product with 80% unused features)? Backup information exposed in WP Remote could thus be sourced from a plugin (i.e. BackupWordPress), a hosted solution (i.e. VaultPress) or a hosting company’s own tool. There is so much variety not only with what tools people work with, but even in how they use them. This can’t be ignored or solved through brute force.
Consolidation by itself is pretty (think Geckoboard or Panicboard for your WordPress sites), but not indispensable. It’s not useful enough to be one of your top ten bookmarks, let alone on your browser homepage. The consolidation of actions however carries immense value and is also what initially made WP Remote so successful, the ability to one click update all your WordPress plugins across multiple sites. The new version of WP Remote builds on this, having actions feed into WP Remote as opposed to in-house features sprawl out.
In a perfect world, we’d perform continuous and small iterations which are then tested. We do not have the resources to work in this manner without sacrificing our desire to experiment. Instead, we’re more sporadic, working in sprints that pursue larger assumptions through more dramatic changes. This is how Happytables 2.0 came about, a one week sprint off the back of an idea that we could stop relying on WP-Admin and provide our own interface instead.
The high level design assumptions I’m making with WP Remote 2.0, is that to focus on consolidation, we need to put the site list construct we have front and centre, whilst enhancing it with functions that enable users to work with larger blocks of sites (and ultimately all sites at once). Below are some of the larger themes of this redesign.
The most logical shift off the bat is to focus on the site list and make that the centre of the application (as opposed to the first screenshot of the article, where the list module functions more as a navigation). Enhancements and extensions would work within this list construct as opposed to spinning off into their own UI modules elsewhere.
My initial design concept goes in that direction, giving all real estate away to the site list:
The top row has some app-level settings, whilst the second row brings in a number of tools to filter and dissect views. The next two sections discussed (widgets & smart bulk actions) are at the core of this new design.
People have different roles, which in turn means they digest information differently. Being inspired by Geckoboard and the likes, we want to provide a configurable dashboard that allows you to choose a widget load-out which best represents your role or needs.
This UI would provide two benefits. The first and obvious one is a visual overview of integrations or open actions that are relevant to how you work on WordPress. The second is filtered views; the headers are clickable, exposing only the open items related to that integration. For example, clicking on the comments button (the speech bubble icon) would show you all open comments across all sites (hiding updates and other integrations in the process).
Given how we’re building this on the backend, we can easily venture beyond updates and comments, and into WordPress plugins (WooCommerce, EDD, etc.), third party monitoring services (PageSpeed Insights, Errorception, etc.) and beyond. I think we have a great opportunity to create some very role-specific views for users. The challenge will come in maintaining consistency across UI, so that the information is still useful.
Smart Bulk Actions
I remember clearly when I used to work in banking and I’d go on vacation only to come back to 500+ e-mails in my inbox. I’d first delete all e-mails that weren’t addressed to me (cc or group-wide communications), then sort by subject (usually deleting multiple threads at the same time if they contained a common keyword, i.e. “Project XYZ”) and then slowly get to working on the few individual e-mails remaining.
The idea there and with WP Remote now, is to replicate the largest wins (in the form of bulk actions) as frequently as possible. These bulk actions would be determined by two factors; 1) They are high in volume, 2) They are easy enough to be understood immediately and thereby also acted upon right there and then (without requiring the user to review individual sites).
Using my Outlook example as an analogy, deleting all e-mails just like updating every single core, plugin and theme item in one swift WP Remote action carries risk that you may be overreaching and doing things you don’t want to in the process. At the same time, processing all emails or performing every update individually is far too time consuming (albeit very accurate). There is however that attractive middle ground.
Say you click on the Updates filter and are then provided with a few additional buttons for your largest possible wins (as in the screenshot above), you’ll probably knock out a major chunk of updates comfortably before moving onto more niche items.
These smart bulk actions is something we’ll certainly try to push as far as we can. The talented @tcrsavage will be leading up development there (and does so on WP Remote as a whole).
The new design is in-browser and has some functionality hooked up to it, but there’ll still be a significant amount of iteration between now and then (both on the front- and backend).
We’ll have a first version running soon, but if you want to have beta access, please subscribe to be notified here. If you have any ideas or want to share your opinion, please feel free to do so using the inline comments or pinging me @noeltock.
Lastly, if you enjoyed the article, click recommend below, thank you!