DEV Community: Jamie Smith

For WordPress, Free isn't Freedom

Jamie Smith — Wed, 10 Mar 2021 16:37:42 +0000

WordPress is popular—people like popular because popular is comfortable and easy. Its popularity has driven the growth and adaptation of the behemoth CMS. With almost 40% of the active internet using WordPress, it's often the first option considered when building a website. It's the Kleenex of the CMS world. Some don't even know there are alternatives.

I've built or worked on dozens of marketing websites — hospitality, financial, industrial, communication. There is a commonality in any industry that WordPress is a mystical tool able to subvert one of nature’s universal constants.

There are some unbreakable and universal laws in nature:

A body in motion tends to remain in motion.
The speed of light in a vacuum is 299,792,458 meters per second.
A website can be built fast, cheap, or nice with only two of these qualities present.

The last one refers to the iron triangle. If you don’t want to click on the link, the iron triangle generally states that any project can only have two of the three: fast, cheap, or well-built. This principle applies to almost any endeavor, but here we apply it to website design and development. Specifically of the WordPress variety.

As a tool, it's not a magic bullet allowing you to circumvent this rule. WordPress is free, and many are under the impression this means a less expensive website. That WordPress is the panacea allowing a high-quality product a developer can create quickly for much less than any other alternatives.

WordPress does do a lot of heavy lifting when building a site, and I'm not targeting the platform’s capabilities. My focus is on the unexpected costs of building any website, and many organizations are surprised to find additional charges that countering their understanding that WordPress is cheap.

Below are frequent cost surprises to clients and solutions to help manage client expectations. Each solution has in common the importance of including these unexpected costs before signing a contract.

Hosting

Problem

It costs money to put the site somewhere. The data (pictures, text, functionality) has to live somewhere. Many clients don't know about hosting, and the developer or agency is explicit about that cost or risk an uncomfortable conversation asking the client for more money.

Solution

Have a hosting solution in mind. Find a hosting provider that you trust, providing excellent service, and familiar to you. A decently priced, managed WordPress solution is ideal. My favorite host for smaller sites/clients is Flywheel. They are a part of my favorite host for larger clients/sites, WP Engine.

With a host in mind, the client will see you as an expert consultant knowledgeable in delivering a website.

Domain:

Problem

Unless the company already has a domain name, they will be surprised that this costs money. Domains aren't expensive, but if your client has already laid out a budget without this additional cost, it will come as a surprise they'll have to pay an additional fee if they even know they need one in the first place.

Even if they already have a domain name, unexpected costs could arise from the need to transfer it to a new domain registrar.

Solution:

Just as with hosting, discuss this early on as well. Ask if they have a domain and if not, you have an opportunity to work with them on finding a domain.
If they already have a domain, it’s essential to be sure you have all of the details to point the DNS to the hosting provider you’ve already discussed. Do you have the login details for the registrar? Does the client want to handle the domain and DNS settings on their side?

Design:

Problem

Design is an entirely differnt article. Whether using a theme or a professional designer, the site's design will cost more money. Again, clients don't know this and are often under the assumption that "WordPress is free" means the design is as well.

Solution:

This is a non-negotiable topic to discuss with the client. More important than both the domain and the host, you need to understand how the site will look. Are you using a theme? Ok. That might cost money. Does the client expect you to make all of the design decisions? Are you even a designer?

If the client is providing a design, can it be duplicated with a theme? Or will it need to be developed as a custom theme? If it’s a custom theme, how are your coding chops? The answers to these questions all impact how long the site will take, how well built it is, and how much it’s going to cost.

It’s easy for either side to assume the other side has a plan for the site design. That is not the case.

Content & Copywriting:

Problem

I am frequently surprised to find clients not having a plan for the site's content. They often assume it's just part of the website; letting them know they need to provide the content comes as a total shock.

What usually ends up happening is that a site is near completion and the developer of the site is ready for content. But the client expects you to enter the content. But if you aren’t also a copywriter. You probably wouldn’t even know where to begin writing content about your client’s industry.

Solution:

Find out who will be providing the content, who will be entering the content, and who, if need be, will be updating the content? Where is the content coming from, where is it going, and what is its source will be the questions you need answering.
The almost-bullet-proof solution to this is to get the content before any detailed conversation about design is shared. The content is the foundation of the site. Not having the content before starting construction is like asking a contractor to build a house for your family without mentioning that your family has 25 people.

Maintenance:

Problem

OK. WordPress as a platform IS free. It is open source, and anybody can go to WordPress.org and download it. A tradeoff requires someone to ensure the site, theme, and plugins are up to date. Just recently, WordPress made an extremely rare, breaking change. Overnight, hundreds of thousands of WordPress sites were rendered useless. That means hundreds of thousands of organizations needed to find someone to repair their site. I know from firsthand experience this issue cost companies money for repairs and will cost money for long-term fixes.

Solution

You must make clear the client understands the importance of keeping the site up to date. Not to do so is irresponsible. Set it and forget it WordPress development is far too common, and many clients suffer in the long term. You don’t necessarily need to be responsible for the maintenance, but you are responsible for informing your client that it will be required moving forward. If the client wants to handle the site’s maintenance themselves, be sure to give them the information and resources on how to do so.

This IS a great opportunity for recurring income, which is a beautiful segue into the next point.

Ongoing Costs:

Problem

The client should be accounting for ongoing costs in their budget, but many small companies do not even think about them when seeking a developer to build their site. Small companies or during rush-jobs can easily forget to create a budget for the short term. Maybe the client expects a web-site to be a one-time expense. It’s not at all uncommon. Hosting & domains always have an ongoing cost. Items like maintenance, content creation, or even content management will all likely add to the client’s long-term budget.

Solution

In the early conversations, you need to be sure you know what it is the client wants and their expectations. This one is all about communication and, if you’ve covered the points before this one, you’ve hopefully addressed all of the elements that will continue to cost money.

What often happens is that the topics we’ve already covered get discussed, but as developers, we forget that clients don’t know that a .com domain costs $12 a year. They don’t know that they are paying for a hosting service, that it’s not a one-off.

Wrapping up, it's important to remember thet when building a WordPress website, you are still building a website. It’s easy to lose sight of the end-user of the product you deliver. That user is not your client. It’s their clients or customers, and they only care that there is a website at all. Approach the project like you are building a website first and WordPress is the tool you are using to acheive the goal.

WordPress isn’t a manifestation of the whole project management Trinity. But by understanding the project’s full scope, managing the client’s expectations, and delivering a project that meets (or exceeds) those expectations, the client will walk away having had a great experience in a field notorious for anything but.

If the client is happy with their product, the limitations set by the iron triangle are moot. Nothing beats excellent customer service. It wins every single time.

Must Web Accessibility Be So ... Inaccessible?

Jamie Smith — Wed, 03 Mar 2021 13:32:07 +0000

I was recently disciplined for bringing up accessibility (a11y) issues on a project at the agency where I was a dev. Even more troublingly, I had already developed a ready-to-push accessible feature for a client. It was nixed at the client’s request, stamped by a higher-up’s approval.

I pushed back, a little. The resulting squabble descended into a minor panic within our agency. Might the client face an ADA lawsuit? Or, would they become upset that we did not implement their request against better accessibility practices? It resulted in my first official discipline as a developer over the two years I’ve committed to this agency. It hurt a little.

Basically, I had suggested that making a digital product — already developed — less accessible was a bad idea. Then, suddenly, everything became dramatic. The client was a small business, so ADA litigation wasn’t likely. I suppose the intended lesson in my discipline was: “keep your mouth shut about accessibility.” I consider that a lesson not learned.

Web dev shops have an existing set of accessibility tools already represented within the HTML code-chest! To me, it’s a real no-brainer to utilize them. It requires no advanced knowledge. Let’s be honest with ourselves as software makers. If we can Google Flexbox every other week but can't be bothered to look up ARIA and Fieldset, the blame falls on us.

A general apathy against implementing accessibility is disturbingly common, rearing its head on even most-critical civic websites. It’s a trend making national news, as many COVID vaccination appointment scheduling sites are inaccessible to blind web users. These sites’ forms and fields were not designed well, with broad accessibility in mind. Many are functionally broken.

I understand that there must have been a rush to get these info sites and web forms up as soon as possible. And, I don't know the tech stacks the developers used. In fact, I do not think it’s fair to assume that actual coders held much decision-making power in how the sites were built. It is, in my experience, often not the case.

I realize that this topic isn't new. My take isn’t novel, but it’s a topic that never seems to find a resolution. We should keep talking about web a11y right now, and as the technology evolves. Maybe coding with accessibility in mind can become second-nature and expected, as opposed to the other way around?

Adopting that expectation may be a challenge, but it is an arena where the browsers can wield influence. They have wholesale blocked sites with insecure content before, over a range of issues. Other times, they’ve placed cautionary labels in toolbars. Google search results already favor sites with a11y implemented. It wouldn’t be a stretch for Chrome(ium), Firefox, Safari, or Edge to display a label notifying users and development stakeholders that a site isn’t accessible.

This ongoing (and seemingly never-ending) web accessibility crisis pushed me to write this: my very first dev-related article. I hope that it helps to further the conversation! Understanding the impact, importance, and relative ease of implementation is how web accessibility will become more accessible.

Note: I won't pretend to be blameless in implementing accessibility in my work. Moving forward, however, I'll be implementing it into my workflow. Including it in my work estimates.

a11y Resources:

Copy editor: Brint Davy

Is Slack Snooping Illegal?

Jamie Smith — Sat, 27 Feb 2021 19:38:07 +0000

Is Slack Snooping Illegal?

Update at bottom

I read a tweet the other which pointed out that Slack administrators can read your private and group messages.
// Detect dark theme var iframe = document.getElementById('tweet-1365423658601222146-36'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1365423658601222146&theme=dark" }

The responses to the tweet start a conversation that this isn't as easy for an organization to do this as the statement makes it sound.

I know people who've been disciplined for speaking honestly/airing their grievances in private channels. The management claimed to have read the messages and gave the group a warning specific to the chat messages. It seemed that they had indeed read the messages.

For those unfamiliar, many companies use Slack as an internal communication platform. It's so widespread that the word has more-or-less experienced trademark erosion, with many using it as a verb for any type of organizational messaging.

Anyway, after reading this thread, I decided to look into the situation more. I'm not a lawyer, and I'm not terribly well versed in data privacy laws. So, please don't take this to HR after you've been busted for calling your boss an L 7 weenie in your "Front-End Team Members ONLY!!!" support group.

According to Slack, the only way to export and read messages are through legal means. Even then, organization Slack administrations can only do so with Plus or Enterprise plans. Neither Free nor Standard Slack plans allow for the organization to access this information on their own.

If an organization on a Plus or Enterprise level plan wants to access message content, they need to send an application to Slack stating why access to this content is required.

Slack gives the following examples of when they might permit an organization to access the message content.

A company receives a report of harassment or theft of trade secrets and needs to conduct a workplace investigation.
A financial services company is required by a regulation to archive certain communications for a set period of time.
A court order mandates information from Slack must be disclosed due to a lawsuit or investigation.
A former employee requests to be provided with a copy of the information their former employer retained about them, as required by the EU’s General Data Protection Regulation

There is a lot of information on exporting data, including message content, but there isn't much on "monitoring" message content on private channels. I can only assume that the export rules extend to the monitoring of messages. If I can only have permission to export message data & content under specific circumstances, it would only make sense that I'd need similar permissions to monitor the message content at all.

The closest I came to any language regarding active monitoring of message content was in the Slack API documentation.

Let's summarize what seems to be Slack's policies regarding access to private message content:

In most cases, nobody can read message content in private channels other than the participants of that messaging.
If a Slack admin wants to gain access to private message content, they need to apply for permission to do so. This only applies to Slack Plus and Slack Enterprise plans. The Free and Standard tiers can only get this information directly from Slack.
If an organization obtains permission to monitor private message content, they need to make it clear to their employees and those using the company's Slack that this data is being collected and monitored.
Private message content can not be actively monitored. Only private message data.

Maybe someone has more insight on this? It's certainly worth talking about and potentially getting more information on.

I want to close out with two final thoughts:

It's probably smart to not engage in non-professional conversation in Slack. There are so many reasons why this is a bad idea and certainly not in the scope of this article.
This response in the conversation on the tweet: // Detect dark theme var iframe = document.getElementById('tweet-1365660239605956610-335'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1365660239605956610&theme=dark" }

If you don't trust your employer it means that your employer doesn't trust its employees and that is a sure sign of a toxic workplace. Start looking for a new job.

Thoughts? Additions?

Update: I'm in the US and you should never assume your conversations are "private" on a corporate/company account. There are a lot of ways to get around this in the United States and elsewhere. If, for example, the company has consent by it's employees to freely read this data, they probably can. Also, I found this AFTER I finished this article.