One of the things that we strive to do at LexBlog is help data drive decision making processes. The fetishization of data in business is somewhat akin to the fetishization for new specs and frameworks in development, but data is still a helpful tool (just like arrow functions in ES6) and should not be ignored. And so we track actions in the admin – clicks, navigating to a certain page, performing an action – all the data that a product manager like myself craves. One thing I’ve noticed in watching how our customers use the LexBlog platform is that people post. A lot.
That simple fact shouldn’t be surprising. We run a network of digital legal publications. Lawyers are trained writers, so they write constantly. Basically, if you give a lawyer a blog, be prepared to see them log in, go to Posts -> Add New, and begin writing away. So when I heard that Matt Mullenweg included the editor in the list of primary focuses for the core team, my interest was piqued. When I saw Aaron Jorbin’s post on using Gutenberg last night, I had to try it out for myself.
At LexBlog, my team is responsible for keeping a lot of sites up and running. We help manage the reputation of lawyers and law firms, where each pixel matters. As a result, our product team performs a host of functional tests before launching updates, and we lean on test driven development practices to catch things that functional tests cannot.
An unfortunate blind spot is that humans aren’t machines. We’re prone to miss simple things, and after staring at a screen for hours on end, our brains and eyes get tired. To help catch things that we may gloss over, we use an internal application built using Node.js, React, and Selenium that integrates with the WordPress REST API and an external service, Applitools.
Every Product Manager that I’ve had the opportunity to speak with, listen to, or read about makes one thing abundantly clear: Knowing your users is your job. Unfortunately, that’s easier said than done. If you take a moment to peruse career pages or job boards with Product Management positions, you’ll notice that each listing notes an ability to simultaneously be an Excel/SQL/database master and product expert. The nature of product management requires you to live, breathe, and eat the customer’s experience while understanding why their experience is the way it is.
I’ve spent a lot of time over the past year wrapping my mind around what it means to build a content management platform for lawyers. For nearly a year and a half, LexBlog has completely turned our model of delivery on its head, and shifted our focus from a project-to-project business, to one that focuses on developing new products. As you may guess, the cost of this shift has not been small.
Recently, I got it into my head that learning how to build a Chrome extension was a good idea. My current list of extensions includes LastPass, Chrome UA Spoofer, Live HTTP Headers, React Developer Tools, JSON Viewer, and a few others that you can see in this dandy screenshot:
The last icon you see there, is from your truly! The function of this extension is straightforward – I love Game of Thrones, refuse to watch the television series because I’ve invested too much time in the books, and I hate spoilers. This intractability combined with a love of surfing the internet has lead to a dangerous cocktail that this tool endeavors to support by blocking all elements on a webpage that could contain spoilers.
As a denizen of Wallingford, Seattle much of my time is spent in wonder at the greenness of it all. My time as a child and young adult in Montana did not prepare me for the lushness of Seattle, and Wallingford is no exception. The spring, summer, fall, and winters here are green and if you look closely enough, you’ll see something blooming during all those seasons as well.
Ultimately, I had to admit that I didn’t know JS.
A few weeks ago, Matt Medeiros published a post on the Matt Report that is still making some waves in the comment section on his blog, as well as over on Hacker News. The tl;dr version of the post is that WordPress isn’t easy, in fact very little on the web is, but WordPress confuses the issue by seeming so easy.
On Hacker News, the argument, not surprisingly, is different. In front of a more technical audience, WordPress, and the professional services market that taps into the software, is quickly the source of derision for any number of reasons:
- Outdated technology stack
- Slow (see above)
- Prone to security issues
- Spaghetti code programmers
- Etc., etc., etc. (read the entire thread if you’re interested, but some of the comments are downright silly, so I’m not going to rehash them here)
Here at LexBlog, we build, launch, and support a lot of WordPress websites and blogs. In many ways, that’s almost all we do! There are certainly other day-to-day tasks that the technical team takes on, but without a doubt, our most pressing responsibility to our clients is ensuring the stability and availability of their digital properties. This is especially true given that our clients, with the unique position that they have, are often suited to write in-depth analyses faster and more proficiently than a journalist or general content producer, but all that is for naught if their blog is inaccessible.
This is why I take the maintenance of our many sites incredibly seriously. When we perform plugin updates, the update is reviewed by a member of our development team (often a product manager like myself or a developer), a fully replicated staging environment is utilized for smoke testing, and each site is backed up before the update takes place. Unfortunately, when you’re talking about hundreds of sites that make use of various (and endlessly shifting) plugin components and themes, that’s just not enough. Fortunately, we’ve developed a few tricks up our sleeves that greatly simplify matters.