Photo of Jared Sulzdorf

Jared is a maker of things at LexBlog. He likes pretty things, functional things, funny things, food, and WordPress. Not necessarily in that order.

WordCamp Seattle was this past weekend at the Washington State Convention Center, just a few short blocks away from LexBlog’s offices. This was my third WordCamp in four years and was a return to form (in my opinion) to the first WordCamp Seattle that I went to in 2014 (held at the University of Washington). 

Hot on everyone’s mind, and the subject of many talks, was Gutenberg, the new core editor coming to a WordPress install near you in just a few short weeks (recently, the timeline for the core update was pushed back to November 27th). In talking with various attendees, it was clear that sentiment was mixed on the introduction of Gutenberg and how it would impact their business, but there was also a palpable sense of excitement and interest around the project that I haven’t seen other major core updates garner (such as the Customizer or REST API). As I’ve said before, Gutenberg is a shot to the arm for the WordPress community, and that comes with pros and cons, but Thomas Jefferson was right:

I hold it that a little rebellion now and then is a good thing, and as necessary in the political world as storms in the physical.

By this I mean, shakeups in the status quo are a necessary part of any long-term project. If you’re not constantly evaluating and adapting, then you run the risk of stagnation. It’s more clear to me now that the benefits of Gutenberg extend beyond bringing a new technology stack to the table. It’s reengaged the community and brought content managers back into the fold as integral players in the conversation about what WordPress is and how it should move forward. At LexBlog, this is a conversation that’s near and dear to our hearts (as bloggers and managers of the largest legal blogging community in the world) and so it’s exciting to play our own little role as we map out an introduction to Gutenberg for our clients. 

As someone interested in what’s going on under the hood, I spent more time in technically-focused talks, but thoroughly enjoyed Andrea Zoellner’s talk on what Gutenberg could mean for the everyday writer. 

Like many pieces of technology, you have no idea what people will do with Gutenberg once it’s in their hands for an extended period of time. However, if her analogy holds and Snow Fall-esque (an interactive NY Times piece that set the standard for multimedia-driven articles) blog posts will eventually be achievable for the masses, then we’re about to enter a very interesting time for bloggers using WordPress. 

My other two favorite talks were from Alain Schlesser and Jon Peck.

Alain discussed how to change your way of thinking when interacting with Gutenberg, and honestly did a better job of it with his slides than with anything I could write here. The big takeaway for me was that as with all technology, there’s a path to sanity. It just might be a bit circuitous. If you’re looking for a less abstract breakdown, just go take a look at his slides! 

Meanwhile, Jon Peck (of Algorithmia) tackled a subject that is a big topic on my mind and was exciting to see someone in the WordPress sphere musing on it as well: Machine learning. For LexBlog, machine learning holds the keys to how we can effectively tag and organize content on LexBlog.com (which has over 400,000 posts and 150-200+ coming in every day). For WordPress, it could mean better ways to manage forums, create advanced applications, and continue to engage the broader engineering community. His talk was a shot in the arm and has me thinking about how to move forward on projects that include components of machine learning algorithms. His slides are also well worth the review, and there was also a fun WordPress plugin that he introduced that could be used as a scaffold for many different projects.  

In short, an incredibly fun and exciting WordCamp. Here’s to many more!

There is a long-running discussion at LexBlog about the benefits and perils of third-party solutions. This discussion has been going on for so long that if you look closely enough, you can find evidence of it in this A List Apart post from 2014 by our own Scott Fennell. This post, is also the subject of Scott’s WordCamp Portland Maine talk this year, so the battle clearly rages on (shameless plug for Scott/WordCamp Portland Maine here – he’s in some rarefied air with this speaker list!).

As with most things, I find my opinions on this subject to be complex. On the one hand, I’ve personally seen what happens when a site manager grows accustomed to a WordPress plugin only to see the support for it slowly fade as the developer (or company) behind it slows their involvement in supporting and managing the codebase. On the other hand, I’ve npm install‘d my way to freedom from more issues than I’d like to admit.

Today was a day where I was saved by a third-party solution. WP Crontrol, a plugin from John Blackbourn, is a handy tool that provides a user interface for CRUDing WP-cron events. Typically, the problems that plague the WP-cron elude us as WP Engine provides a true cron that we use on all of our environments to ensure that scheduled actions take place when our publishers (and us) expect them to. However, this isn’t a perfect solution as long-running crons can cause a bottleneck to appear at the top of the cron stack with those cron jobs stopping others from firing.  This is a pretty frustrating issue for someone that just wants their scheduled post to go live without worrying, and difficult to troubleshoot as cron events are held off in the database without a great way to manage them.

Enter WP Crontrol. After installing this plugin, I was able to easily see a list of cron events that clearly should have fired by now. After deleting the oldest cron, the rest cleared up in short order. 

Now, Mr. Blackbourn is a well-known quantity in the WordPress realm. We use his plugin Query Monitor regularly, he’s a core contributor, and works at Human Made, a highly-regarded WordPress agency. This is a far cry from the sorts of solutions that Scott or other members of the LexBlog product would typically have concerns about.

But where do you draw the line? As I eluded to above, npm is something I’ve grown accustomed to using, and many of those modules have dependency chains that stink to high heaven. LexBlog taps into a number of third-party plugins that are now a core part of our product offering. WordPress itself is a third-party solution that we have built our business upon. There is no escaping the power of these tools, and I wouldn’t want to even if I could. 

The trick, as Scott so eloquently puts it at the end of his post on A List Apart, is knowing when to leap into someone’s helping hands, and knowing when to take a stand:

It’s not that third parties are bad per se. It’s just that the modern web team strikes me as a strange place: not only do we stand on the shoulders of giants, we do so without getting to know them first—and we hoist our organizations and clients up there, too.

So look before you leap. It’s never as easy as just installing and forgetting. 

Unlike recent point releases, WordPress 5.0 represents a major shift both in the underlying technology and user experience. Some other releases stand out in my mind – 3.4 brought the theme customizer which is now the foundation for all the theme work done at LexBlog, 3.8 changed the look and feel of the WordPress administrative area, and 4.4 introduced a REST API into core – but this update dwarfs those and most others. 

For as long as I can remember, writing a post or updating a page in WordPress was done through the visual editor built on TinyMCE.  This experience has been a more consistent part of my life than anything else. I’ve changed jobs, left my home in Montana, made a new home in Seattle, and gotten married all while the WordPress editor remained unchanged. As of WordPress 5.0, that will change as the new Gutenberg editor replaces the traditional publishing interface. This means that we’ll go from the ubiquitous WYSIWYG editor:

The old TinyMCE as it appears on the LexBlog Platform currently

to one that looks like this:

And is based primarily on the notion of “blocks.” Every discrete piece of content (paragraphs, images, embeds, lists, blockquotes, etc) is considered to be a content block in Gutenberg.

As this is not a post that’s designed to be about the differences between Gutenberg and the current experience, I’ll skip over most of those details, but if you’re really interested, I’d advise visiting Testing Gutenberg where you can play around with a demo of the new editor.

The first inklings that the editor as we knew it was on its way out was January of 2017 when Matt Mullenweg (WordPress’s benevolent dictator/founder and Automattic’s CEO) posted on WordPress core’s development blog that the editor was a primary focus for that year. In the nearly two years since, the GitHub repository that hosts the current iteration of Gutenberg as a WordPress plugin has seen over 8,000 commits and 300 contributors. The team behind Gutenberg represents some of the most committed and talented WordPress developers, and more join the ranks of contributors every day.

Gutenberg has also been the subject of countless posts that vacillate between critique, praise, and everything in the middle. While the introduction of WordPress’s REST API was no stranger to controversy, the forward-facing nature of this change has opened the discussion to the entire community. The WordPress community has grown far beyond freelance developers and solo bloggers looking for an easy solution to setting up a site. It now includes small businesses, Fortune 500 companies, digital publications, e-commerce shops, newspapers, and countless agencies, plugin/theme developers, and entire marketplaces.

WordPress enjoys a marketshare unlike anything before it with 32% of the web and nearly 60% of all sites that use a known content management system relying on the open source project. If Facebook is the town square of the internet, WordPress is the roads and sidewalk, and like the roads and sidewalk of any city, if there are potholes or uneven edges, people will complain and complain loudly. Unfortunately, there is plenty to complain about with Gutenberg. Automattic’s accessibility lead just resigned amidst complaints that the project was leaving behind the central tenants web accessibility standards. The documentation of the APIs and ways to interact with the new editor are sorely lacking. The core team’s attempts to engage the community have been ham-handed at times.

The list of grievances against Gutenberg could go on and likely constitutes a post unto itself, but one thing is certain: Gutenberg is merging into core whether we like it or not. The only question left is when.

Practically, what does this all mean? Ultimately, that depends on your situation. Many site managers, agencies, and plugin/theme developers are scrambling to activate the Classic Editor plugin (which deactivates Gutenberg) to avoid the onslaught of hard conversations between them and clients as various pieces of functionality may break with the introduction of the new editor. Others are diving headfirst into creating new blocks and building entire themes around the experience. However, if you’re like the majority of website owners, the update will come as a surprise as one day (thanks to the curse and magic of automatic updates) the visual editor updates to Gutenberg. 

At LexBlog, this is clearly a huge deal. The vast majority of our clients interact with the post editor and only the post editor. We are, after all, a community of publishers. Fortunately, we’re also a company that’s built our platform on WordPress, and we take new technical developments quite seriously. Over the course of the past two years we’ve reduced the number of third-party integrations that touch the WordPress post editor, limiting the chances that a third-party solution that hasn’t updated to integrate with Gutenberg will cause an issue for our customers. We still have a few third-party plugins that interact with the post editor, but they’re among the most well-known plugins (such as Yoast) or developed by highly regarded individuals (Co-Authors Plus) and have already been updated to support Gutenberg.

For our own plugins and themes, we’ve gone through a multi-pronged approach of:

  • Front-end visual regression testing (just to be safe)
  • Extensive review of our codebase for integrations with the existing editor 
  • Functional testing to unearth issues

We’ve certainly found problems and are working to address them (or have resolved them already). Unlike many site owners, we’re fortunate to have a great team who are capable of finding problems, organizing them, and fixing them one by one. We’ve activated the Gutenberg plugin on our internal properties (including this one), allowing our entire company to get used to the new interface and find issues before our customers do.

We will also straddle the line that many are walking, only perhaps with slightly different motives. At LexBlog, we’ve long believed that our customers are not guinea pigs for new changes, but instead take a pragmatic approach where we allow the broader community of users and developers to find issues and solutions for such developments. This will be no different. While the proposed WordPress 5.0 schedule has targeted a November 19th launch date (with an alternate deadline where 5.0 is shipped January 22nd if some project slippage happens) LexBlog will delay the introduction of the Gutenberg interface beyond that, activating the Classic Editor plugin and working with our customers to slowly introduce the new interface. This should help eliminate confusion and give our authors a safety net for learning how to use Gutenberg. 

How exactly we go about this is still a work in progress. There are many of the pieces of the puzzle we’re still working on, and those pieces will shift and settle as the picture from the core WordPress team crystalizes. Until then, stay tuned!

The longer LexBlog has maintained a product discipline, the more disciplined I’ve tried to become in evaluating new ideas and business. This often puts me in the place of saying “No”, which, contrary to some popular beliefs, is not a word that I personally enjoy saying. I find it unlikely that anyone enjoys telling someone else that their idea is not worthy of working on immediately (or ever), but it’s a necessary part of running a product.

A product is (hopefully) not a compilation of random ideas. It is the final result of days, months, or years of hard work. It is rarely the thing you thought it would be when you first started building. While many beautiful products started as offshoots of a larger product and eventually became the product (think Instagram), even these are carefully defined as the team behind the product learns and responds to it’s users.

Products are unsuccessful for reasons that are often far outside of the control of the team engaged in building the product. I can not understate the value of marketing and sales. However, when the product team allows their systems to grow unruly in scope and size, it’s nearly impossible for the product to succeed. This process of maintaining focus and delivering the largest value to the widest group of people is just that, a process, and it requires intense focus.

It feels a bit trite, as a product manager, to quote Steve Jobs, but this quote from the co-founder of Apple rings especially true as I think about the process of working on a product:

You know, one of the things that really hurt Apple was after I left John Sculley got a very serious disease. It’s the disease of thinking that a really great idea is 90% of the work. And if you just tell all these other people “here’s this great idea,” then of course they can go off and make it happen.

And the problem with that is that there’s just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows. It never comes out like it starts because you learn a lot more as you get into the subtleties of it. And you also find there are tremendous tradeoffs that you have to make. There are just certain things you can’t make electrons do. There are certain things you can’t make plastic do. Or glass do. Or factories do. Or robots do.

Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.

And it’s that process that is the magic.

We’ve relaunched LexBlog.com!

These are words that I’ve (and others) have said at LexBlog probably a hair over a half-dozen times in the past two years; a point that Conner alluded to when he took a look at the history of LexBlog’s many and various websites. This time, however, things feel very different. After an eight month battle with Co-Authors Plus, the WordPress REST API, caching, and a few handfuls of our own plugins the new LexBlog.com was soft-launched in August (just before my wedding!).

If you look back on some of my recent posts here (We’re Redoing LexBlog.com…… Again. and How We’re QA’ing The New Aggregation Engine of LexBlog.com) and some of Kevin and Bob’s older posts (What if LexBlog were a publication? and As We Open Our Network, Should We Reject Some Blogs?) you’ll see that this latest version was a long time in the works both technically and philosophically.

On the technical side, we had to battle (and continue to wrangle with) keeping posts and authors in synch on LexBlog.com with their original counterparts using the WordPress REST API to communicate between sites. When you’re talking about over 1000 sites, nearly 400,000 posts, and just under 20,000 authors/co-authors this is no easy task.

Philosophically, we’ve had to prepare for the shift in what LexBlog.com means to the company and the larger legal publishing community. For years, LexBlog has focused on publishing platform technology to help lawyers get online and engage in the larger discussion online. We believe, and continue to believe, that the fastest way to join this conversation is to listen, share, and add your two cents.

Blogs are our chosen vehicle for helping our clients do that. However, it’s not easy to start blogging when your digital network is one – just you. LexBlog.com is many things to many people inside and outside of LexBlog, but for me it’s a place to see the vibrant digital publishing community in the legal industry. Hopefully, it’s a spot for other authors and legal professionals to find that for themselves. Somewhere to maybe see a similar publication to the one you have, find an author that you enjoy, or follow along with an emerging topic in your industry.

There are hundreds of publications focusing on a plethora of topics, and as LexBlog grows, so will these topics and contributing publications and so will the site itself. What we currently have is a foundation to finally launch all of the things we’ve wanted for so long:

  • Enhanced search functionality
  • Better subscription options for email and RSS
  • Social integrations for sharing content and interacting with publishers
  • and the list goes on

I’ve worked full-time at LexBlog for nearly 6 years and watched as the digital hosting, development, and content production sphere have evolved and seen us adapt alongside these many changes. In that time, this version of LexBlog.com is the one that kept me moving forward toward a larger vision of how digital publishing fits into the legal industry of today and its future.

Here’s to that future 🙂

In another era, I would be an Excel jockey; instead, my true love is Google Sheets.

As Scott Fennell and I have continued to hammer away at working on the new LexBlog.com, my eyes have gone red staring at more spreadsheets in Google Sheets than I’d care to admit. I’m using these spreadsheets for two reasons:

  • Validate that the shape of the data on our test aggregation site (i.e., the future LexBlog.com) matches the shape of the data on each test source site (i.e., all of the client sites that we manage)
  • Derive some understanding of the organization of things on the current LexBlog.com

The reason I’m using Google Sheets for all this is simple: It’s fast, easy, and requires very little from me to maintain the approach.

Continue Reading How We’re QA’ing The New Aggregation Engine of LexBlog.com

A company’s website can be an amorphous thing. A place that tries to be something to everyone that visits.

Most product-based websites are attempting to sell you something. Whether that’s a dream, a physical object, a service, or a piece of software the goal is to take you from visitor to lead to customer. This process of conversion is well-studied and cottage industries have grown around helping businesses convert website visitors to leads.

For a time, LexBlog’s website tried to act as this funnel using relatively standard techniques. Early iterations had clear calls to action for purchasing something. Later, “more sophisticated”, approaches had landing pages for different personas and extensive product tables.

Today’s version is the closest version to what I’m comfortable with as a LexBlog employee. We’re no longer pushing LexBlog and our products through our website. Instead, we’re shining a light on our customers and the people that want to join us in our mission to broaden the discussion of the law online and make that discussion freely available to anyone that is interested.

This shift has not been without it’s struggles. To get to where we are today, we had to first take the website formerly known as LXBN and put a better dress on it. This included not just updating the design of the site, but bringing it into out platform in a more formal fashion by opening up subscription options to publishers on our platform. We then had to move LXBN to become the new LexBlog.com. We did this almost under the cover of night last winter with our CTO, Joshua Lynch, working his domain magic to get the hardest parts done.

While we’ve come a long way, the version of LexBlog.com that you see today is full of warts and issues. These are things that perhaps only I can see, but that if we’re serious about our mission, everyone will see sooner or later. The tools we use to aggregate our customer’s content are the same ones that we used in 2011 when LXBN.com was launched and I can only describe them as lossy. We can and should do better, which is why the product team at LexBlog has, over the course of the past several months, been working on more advanced and faithful ways to pull content into LexBlog.com and treat it in a way that respects our publisher’s actions on the platform, and provides greater context to readers that come to the site.

In layman’s terms this means better post attribution, better organization by source (i.e., by blog) and by membership (i.e., the organization – be it a law firm or legal company – responsible for publishing), and a foundation for future iterations around search and subscriptions.

In technical terms, this has meant a deep dive into the WordPress REST API by Scott Fennell and Angelo Carosio – LexBlog’s dynamic developer duo – so that we can keep our network of 1000 blogs, 15,000 publishers, and nearly 400,000 posts in synch with LexBlog.com. This has been no easy task, and in many ways, the core WordPress work of building out custom REST endpoints has been the easiest. The real trick has been looking at the tools we’ve layered in (additional profile meta, content reassignment tools, etc) that our publishers have access to, and making sure that when they take an action, it’s reflected over on LexBlog.com.

Practically, this means when a post is updated on Kevin, our CEO’s, blog, a request is sent to LexBlog.com to update the corresponding post there. Or if Bob Ambrogi, LexBlog’s editor-in-chief, posts a new article on a piece of technology he’s interested in on his LawSites blog, that post goes right over to LexBlog.com – in full – and is properly attributed for the audience there to read.

This is all still a work in progress. We’ve only just come to a point in the project where I feel comfortable talking about it out loud instead of in a company Slack channel after getting through some of the more complex bits of debugging that we’ve had to endure at LexBlog. To take this from a project in the LexBlog lab and move it into the light is going to take some serious elbow grease. While we don’t have a set launch date for this project quite yet, I’m continuing to be optimistic that we’ll make significant progress before we’re too deep into the Seattle summer.

But what will the finished product look like? Ultimately, it will be similar to what you see today. A place where we continue to highlight the best legal content on the web and bring together opinions from all over the globe on the shifting landscape of the law. A point of pride for me as a LexBlog employee has always been the level of care we have for our client’s work. The company that we are today is because of them. It feels good to build LexBlog.com as a vehicle for their work, not ours, all in an effort to bring the law online.

A long time ago in a galaxy far far away, LexBlog used Get Satisfaction to manage our knowledge base and community portal (then named “Reach”). The implementation was clunky, requiring users to create dual user profiles on their sites and inside this other application. Moreover, there were no ties between the content in the knowledge base and the people that were helping clients find answers to questions, so there was little incentive as an employee to know or contribute to the content.

As I’ve mentioned in my past few posts, a huge reason LexBlog moved to using Zendesk’s suite of products was the consolidation of systems and processes. Instead of having three products from different companies that don’t talk to each other to manage one thing (support and project management) we now have a variety of integrated tools. A benefit to being in the Zendesk ecosystem is that these tools are fairly technically advanced, allowing us to tie a WordPress user to a Zendesk profile and supporting single sign-on into LexBlog’s support center where you can see all of your submitted tickets and interactions with our team since we’ve been using Zendesk’s ticketing system. For our support team this also means that all of the content from support center is at their fingertips each time they answer a question from a customer, and a new question can easily turn into a support center article.

While this has significantly streamlined our support processes from the Get Satisfaction days to today, we took things a step further when redesigning the support center. While the content has been available to anyone with a link to the support center for several years now, we had not allowed search engines to index anything. As a part of continuing to open LexBlog’s doors to all legal bloggers, we thought it was about time to take that step so that now anyone can search for the content on the web and find their way to the LexBlog support center. Community posts, profiles, and other private information will remain that way, but all articles written by LexBlog will be indexed by search engines from here on out.

A lot of the content now is there to aid in making our customers successful in using our software, but as we expand that content to include more information on blogging and social media, others that are starting up a legal blog may find it a useful resource. A key challenge for LexBlog (one among many!) is helping to raise the level of discourse on the web for lawyers and law firms – regardless of whether or not you publish with LexBlog – and this is one small step of many in doing just that.

Maintaining a network of over 1,000 blogs can sometimes feel a bit like digital farming. Much of my time is spent identifying bugs to squash in various repositories, managing projects along to completion, and reviewing platform statistics in preparation for the next round of customer interviews (the “weeding”, “shepherding”, and “flock tending” of product management). Every so often, however, harvest comes and there is some revelry in the launch of a major update.

Yesterday was one such day as the new design of LexBlog’s support center was launched early in the morning; the culmination of several weeks of work between Ted Cox, Brian Biddle, and myself. The old design (pictured below) was a fast bit of work, with the primary focus on moving a rather large body of content from Get Satisfaction to Zendesk’s Guide product without losing anything in that migration.

 

 

 

While the move was a positive one, and the updated design better than the one implemented in Get Satisfaction’s ecosystem, there was still a lot of room for improvement. As with any design, the longer it was up, the more obvious it became that something was off. The three “call to action” boxes seen in the image above, seemed arbitrarily placed, the search form’s placement moved around depending on what page template you were on, if you scrolled lower you saw a list of categories without any explanation of what the contents of those categories were; the list of UX and UI flaws goes on and on.

With Ted moving from his role as a Technical Support Specialist to LexBlog’s full time Technical Writer, the time seemed ripe for a major overhaul of not just the design, but the organization and focus of the support center. Ted spent days reorganizing content, and more time reviewing everything to make sure that things were as up to date as could be expected, all while adding a series of documents on new (and old) LexBlog platform features. While that happened, Brian worked on building out a design that was both more in line with LexBlog’s design standards, and focused on the paths that a customer may take as they looked for content.

The result was a fully responsive (the last version had a mobile version) work of art that everyone at the company is (more) proud to stand behind.

 

 

There’s greater consistency throughout the design, and the list of popular articles at the top of the homepage is managed by Ted and reflects the most viewed pieces of documentation within the support center. The interior pages are where I think the design really shines, with each article containing clear navigation to other articles in the same section of documentation, making it easy to follow from article to article and find what you need:

 

 

Overall a pretty fun project to work on, and a good crop to harvest.

I’ve been a big proponent of Zendesk after using their product(s) for several years at LexBlog. Like all businesses, LexBlog has gone through a variety of systems and processes cycles, and how we manage inbound requests is no exception. As I mentioned in my last post, a huge push over the last several years has been the shift from the cycle of inbox to development/design requests back to inbox to a more distributed approach through the use of Zendesk’s ticketing system. Not only was the old approach to communication causing headaches for all project members (have you ever played the telephone game?), it created silos where only a single account/project manager could manage the projects they were responsible for. If for some reason, that person was sick for a week, their projects may go untended or be utterly confusing for someone to step in and address.

Something that we’ve worked hard to do in recent years is choose software that we can easily work with outside of the box. It’s rare that we find something that fits what we need without customization, and having the ability to extend the core product is vital.

In that regard, I can’t say enough good things about working with Zendesk. The content in our contextual support bubble is dynamically populated if opened on a page where there is support documentation that may be helpful – this is powered by the Web Widget API. The support center in each site’s administrative area is powered by the Core API. And much of my work over the last several weeks has been with Zendesk’s Help Center templates, which are a mixture of HTML, CSS, JS, and Handlebars.

I also had the chance to extend LexBlog’s visual regression testing application to be more of a dashboard application for managing all things related to LexBlog’s systems by working with the Help Center API to provide Ted Cox, our technical writer, with the tools needed to better manage the content inside our support center through a variety of API calls and new React components (as a brief aside, if you have a React application and ever need to take the results of an API call and jam them into a CSV, I love this package).

Overall, a lot of good things to say about Zendesk, and probably even more as we’re starting to wrap up our work on redesigning LexBlog’s support center!