Like many technical specifications on the web, RSS (which stands for Rich Site Summary or Really Simple Syndication depending on who you talk to) has a confusing history that seems to only get more confusing as time goes on. The format became popular in the late 1990’s as the need to standardize information held on websites became a pressing concern with the rise of blogging and dynamic websites. The influx of information and content, all organized in different ways, was exciting, but without a standard way to consume the content, you were left with just a few options:

  • Bookmarks, and lots of them
  • Memorize a handful of URLs and visit only those sites
  • Build a custom web scraper

The goal of RSS (as I see it) was to provide each site that created dynamic content a specification to follow to make that content available at some address so the rest of the internet community could easily monitor this address for updates. For example, this blog’s RSS feed is available at https://www.jsulz.com/feed/. You can take this URL and drop it in Feedly or your RSS reader of choice and every new post I publish will end up there alongside any other blogs you regularly read.

My introduction to RSS feeds was through Google Reader, a feed aggregator similar to Feedly that provided users with a way to compile compendiums of publications and read them all in one place. While aggregation and syndication are the most often cited reasons for using RSS, the use-cases extend much further beyond that. In my mind, RSS’s purpose runs parallel to one of the foundational reasons for the internet’s existence: Communication.

Even with WordPress dominating the online content management game there are still hundreds of systems, all with their own way of structuring webpages and publishing content. Without a standard way to consume this content, each post, page, update, or product stands to get lost in a sea of information. The RSS specification does away with all the page markup, styles, forms, etc and focuses on structuring the content so that it’s easily accessed. Without a standard for communication, there is no way to communicate.

As LexBlog opens its doors to legal blogs and digital publications around the web, my belief that RSS is a standard component of content management systems is being challenged. We’ve found blogs that don’t have RSS feeds, publications with RSS feeds that contain only the name of the site or a handful of posts, and just about everything in-between. I understand that technologies change and that a site built in 2004 may not have considered RSS a core part of blogging (although I may have some questions about why a site delivering dynamic content is being run on the same platform in 2018), and I get that making a piece of technology do something that it wasn’t designed to do is difficult. That said, people charged with managing content on the web are admitting to serious negligence if their publications don’t have an RSS feed and they aren’t doing something for their organizations (or clients) to change that.

It’s unfortunate that at a time when internet technologies have taken off and valuable content is around every corner, that technologists have eschewed standards designed to make that content available. As I wrote this, I was reminded of a recent post by Boone Gorges:

The more worrisome trend is content that’s not available through RSS simply because there’s no feed mechanism. A shamefully large number of my geekier aquantainces have moved their blogs to Jekyll and other static-site-generation tools, which don’t appear to have feed support out of the box; and – this is the “shameful” part – since these folks, geeky as they may be, think so little of RSS, they don’t bother setting up the secondary plugins or whatever necessary to serve feeds. I expect that kind of behavior from lock-up-my-content companies and technically-clueless organizations that rely heavily on proprietary and bespoke software, but not from people who ought to know better.

Could not have said it better myself.

Engineers make hardware and software for humans. It should go without saying, but remembering and staying true to that axiom is complicated depending on where you’re standing. With each passing year, it seems that things get more complicated, more random, more uncertain. This year was no different, especially in the realm of technology.

Facebook and Twitter are defending their platforms amidst allegations that they were used for interfering in America’s 2016 Presidential elections. Net neutrality seems to be going by the wayside with nary a peep from the so-called “Big N”, many of whom participated in protests in 2014 when the issue first came to the public’s attention. Uber dug itself into a hole as scandal after scandal rocked the company; the first of which was a female engineer lifting the veil and exposing a misogynistic and Darwinian culture, followed by revelations that the company had written software to avoid local law enforcement agents in areas where Uber was prohibited from operating. Meanwhile, the threat of automation and the looming specter of artificial intelligence have every working professional worried about the future of employment in this new economy.

The list could go on and on, and doesn’t end when last year began. As long as corporate greed and bad company culture are not only allowed, but praised, problems of this ilk will continue. The problem as I see it, is that it’s most troubling in the context of computers.

Continue Reading Make Technology for Humans

Over the past few days, the Product team at LexBlog has been busy launching a few bodies of work that have been a long time coming. While our Success team launches sites and solutions on a hourly basis, the product side of LexBlog has the luxury of spending weeks, sometimes months, working on new features (what luxury!). It’s a truly fortunate situation, and one that we don’t take for granted.

This week, our team had the pleasure of being in the same offices together with our Lead Developer, Scott Fennell – who blogs over at Code in the Cold – and Director of Design, Brian Biddle making their quarterly visit to the LexBlog Mothership (now at WeWork!), and we made sure to capitalize. This Thursday and Friday we celebrated our team’s geographical unity, short-lived though it may be, by launching a new admin color scheme, a redesigned LXBN – named The LexBlog Network from here on out – and LexBlog Network subscription options for each author on LexBlog’s publishing platform.

While our authors may not find the new admin color scheme groundbreaking, this update was the source of some headaches for yours truly, and served as a great technical opportunity for Mr. Biddle and Angelo Carosio, LexBlog’s in-house DJ and developer extraordinaire.

Continue Reading LXBN as the New LexBlog

In my time at LexBlog, I’ve seen three different office buildings and worked in two.

The first LexBlog offices where my first “real” desk job began was on 95 South Jackson Street in Pioneer Square. The building was near the waterfront, and a stone’s throw away from the Seattle Ferry Terminal. Our CEO, Kevin O’Keefe (he of Real Lawyers Have Blogs), lives on Bainbridge and so LexBlog has always stuck near the ferries. The offices were nice; brick walls, open layout, corner offices with good views, but toward the end of LexBlog’s lease we were neighbors with one of the largest construction projects in Seattle’s history.

Continue Reading LexBlog is Moving to WeWork

This post was written using Gutenberg, the code name for the WordPress core team’s effort to overhaul the WordPress post editor.

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.

Continue Reading Gutenberg – The Future of WordPress’s Post Editor

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.

Continue Reading Building a Visual Regression Testing Application Using React, Selenium, Node.js, and the WordPress REST API

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.

Continue Reading Getting To Know You, Getting to Know All About You

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.

Continue Reading Building a Legal Blogging Platform

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:

Screen Shot 2016-07-22 at 10.19.05 AM

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.

Continue Reading Game of Thrones Spoiler Blocker – an Exercise in Building Chrome Extensions

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.

Continue Reading The Beginnings of A Wallingford Sensor Garden