In order to do our part to stop the spread of COVID-19, our team will be working from home. Please via email.
Anyone sending bulk email can be flagged as a spammer. Bulk email is sending an email to a group of recipients. The more emails you send and the larger your recipient lists, the greater the risk of being flagged, but there is no such thing as a safe limit that you can stay under. Any bulk emails you send could potentially land you in trouble.
Everyone is coming down hard on email spam, from governments with anti-spam legislation like CASL, to Internet Service Providers (ISPs), who are doing more and more to detect and block bulk email.
ISPs, as well as companies that provide spam-filtering services, process a lot of email. This gives them the ability to collect large amounts of aggregate data with which to identify spam, and potentially blacklist the sender. Once you are blacklisted, it takes time and money to fix.
Services such as MailChimp, Constant Contact, and Campaign Monitor protect you from getting blacklisted. However, even when using these services, you must follow good email practices, because the industry looks at your "email reputation".
Your email reputation is how ISPs and anti-spam systems track and score the desirability of the bulk email your organization sends. If you have a good reputation, then there's a good chance your emails will end up in recipient inboxes. But if your reputation is low, then your emails are more likely to end up in spam folders or be blocked entirely.
Many factors can go into determining your email reputation, and every ISP does it differently. Common things they look at include:
If you have a bad email reputation, third party email services may drop you as well.
In summary, organizations used to get away with anything when sending out email blasts. However, the industry and government legislation has changed that, and it's probably only going to get tougher.
I read a great article on web content writing tips
The key tip was write for "scanners". The article points out that only 16% of people read web pages word-for-word. Most people just scan.
When people scan a page, the four things they notice most are:
These are things you should pay special attention to. In particular:
These methods can help get your ideas across quickly, and perhaps entice people to read a little more.
A writer's most important tool is the delete key, so shorten your text and make your copy easy to read:
In a nutshell, write in plain English and keep it simple – visitors don't want to have to work to understand what you're trying to say.
Many organizations want to track detailed statistics about how their users consume their content, such as:
Many web service organizations will provide engagement stats that attempt to satisfy this desire to look over users' shoulders and keep track of what they are doing. But you should treat these numbers with a bit of skepticism.
Generally speaking, you cannot look over your users' s shoulders to determine exactly what they are doing. If your users have decided that they don't want to be spied on, then it would be a privacy violation for you to do so, assuming you even had that capability. (And, realistically, you don't have that capability.)
Most engagement stats use simple tricks to guess what the user is doing. They are not actually monitoring the user. Instead they are looking at your web server's traffic stats to see what content is delivered to the user's computer. To track individual users, the URLs that are used to request that content might be tagged with personalized tracking codes.
So you can look at your web stats to see that a video was accessed, and if you are using tracking codes, you can even infer who it was accessed by (assuming that user did not share the link with someone else). Your web stats can report exactly how much data was sent back, and from that you can infer whether that adds up to the complete video or not. But none of that means the user actually watched the video. Video players will preload (buffer) their content, so the fact that your web server (or video service) delivered the full video doesn't mean the video was actually played, or that it wasn't paused or closed before it got to the end. Because things like pausing happen on the user's personal computer, and not on your web server, they are much harder to track, require more invasive spyware tricks to monitor on the user, and are unreliable even with all that extra effort. (There are many popular browser plugins that block tracking software.)
Monitoring who reads your emails is similarly problematic. As with videos, there is no way to tell that an email was actually read. Because email is not on your website, you cannot even say if it was delivered. But there is a trick you can do to determine if an email was opened. This is done by embedding an image with a tracking code into the email. When that image is downloaded from your web server, you can detect that tracking code, and guess that the email was displayed somewhere. But even in that ideal case, that doesn't tell you if the user actually looked at the email, or were just whipping through their inbox, deleting unwanted messages. Most email programs also provide easy ways to disable automatic image loading, since it can also result in slow performance and unwanted data charges on mobile devices. Without image loading, your tracker simply won't work, and your open stats are not going to be reliable. Either way, many emails that show as opened were not read, and many that show as unopened were read.
Many web analytics packages like to report how much time visitors spent at your website. Again, these are just wild guesses, based on tracking codes, cookies, or click patterns. Even if the user doesn't block cookies, it is very difficult to say how long someone is at your site. How long should an analytics package report that someone is on your site, if your site is left open in a background tab all day long? Who is more engaged with your website, someone who visits the same page three times in one hour, or someone who opens the same page in a tab once but leaves it there all week? There is no clear answer, and analytics tools can only make guesses based on their own assumptions.
Designing websites to work for visitors with disabilities is a complex subject, as there are many different disabilities that must be taken into consideration, each with its own requirements. There is no magic bullet that works for all disabilities.
Consider the seemingly simple task of embedding a video into your site, which you might not otherwise think twice about. Now ask yourself:
WCAG (Web Content Accessibility Guidelines) defines the various considerations you should take into account when building your website content. Exware's software is designed to make it easy for you to build accessible websites that adhere to WCAG and other industry standards. But as the video example above shows, you are ultimately in control of your own content. The software platform you use will not magically make your content accessible, and you can break compliance if you are not diligent.
WCAG compliance is not a simple yes/no thing. It is an extremely complicated standard, there are different levels of compliance, and at the highest level of compliance (AAA) it may not even be possible to satisfy all requirements for some types of content. There are many aspects (e.g. accessibility for the blind, for the deaf, for different types of visual impairment, for the motor impaired, for epileptics, etc.). Rather than asking "are we WCAG compliant?", one should start by asking "how accessible are we?" and "which types of disabilities could have trouble using our website?"
Designing a site to work for all types of disabilities is a hard thing to do as that means you must take many different design compromises into consideration. For example:
Designing for broad accessibility can put a lot of restrictions on how you design your site and deliver information to your visitors. Many graphic designers do not want to pay this price, because they are by nature visual designers, and broadly accessible designs can come across as comparatively plain (think about government websites, for instance). Many organizations concur, because they want to make an impact on site visitors—which usually means a visual impact. Because of this, you may have to accept some degree of accessibility imperfection if you are set on those visual effects. But with a small amount of care and attention, you can ensure that the imperfections do not break your website for disabled visitors, and that they are still able to access the critical content that they came to find.
Website SSL provides a more secure way to interact with a website. With an SSL site, the URL starts with https instead of http - the "s" stands for "secure". SSL improves security in two ways: authentication and encryption.
It's the need for encryption that has driven the adoption of SSL in recent years. Increasingly, browsers warn users whenever information is about to be entered on a website that is not using SSL. If you want users to trust your website and feel at ease, SSL has become a must-have.
Another huge motivator for encryption is the increased use of mobile computing. The ease and convenience of WIFI means it is also much easier for somebody nearby to listen in on your network traffic. The need for website SSL was made all the greater in October 2017 when it was discovered that WIFI's built-in security standard, WPA2, is highly vulnerable to attack, affording little protection against eavesdropping.
SSL certificates are traditionally issued by a commercial certificate issuer, with prices ranging from tens to hundreds of dollars per year. In 2016, a new system for issuing free automated certs was created by Let's Encrypt, using a protocol called ACME. Commercial SSL certs are typically good for one or two years. Free ACME certs are good for at most 90 days but are renewed automatically.
So if there are expensive SSL certs, and cheaper certs, and very cheap certs, and even free certs, what's the difference?
The good news is that when it comes to encryption, there is no difference. All SSL certificates regardless of cost., support the same enterprise-level 2048-bit data encryption. And as we've seen, encryption is the main issue.
One way SSL certificates can differ is the level of website authentication they provide. The most basic level is domain validation (DV). This means that the domain on the cert matches the domain of the website, so if the browser address bar says https://www.somesite.com then you really are at www.somesite.com. All SSL certs provide this. For the vast majority of websites, this is all you really need.
Commercial SSL certificates can, at additional cost, provide organization validation (OV), and there's an even fancier version of this called extended validation (EV). While DV authenticates the domain, OV and EV also authenticates the legal business name of the organization, providing assurance that the people running the website really are who they claim to be.
With an OV cert, users can inspect the certificate in their browser and see the name of the organization, although most people won't know how to do that. With the even more expensive EV cert, the organization name appears in the browser's address bar in green, making it completely obvious. EV certs are what you normally see with banks and other financial institutions where trust is most important. Twitter currently uses an EV cert, but Facebook and Google don't bother, and just have OV certs. If your domain is widely recognized, then an EV cert doesn't add much.
There are a several other distinguishing features of SSL certificates:
Commercial SSL certificates provide liability protection, covering losses due to a flaw in the certificate. It's like insurance for the cert. For a basic GoDaddy cert, losses up to $100,000 are covered. Free certs do not have this at all, while more expensive certs typically cover higher amounts. It's debatable how useful this is.
Another consideration is reliability. SSL works because each browser - Chrome, Firefox, IE/Edge, Safari, etc - is programmed to trust the various certificate issuers. However if an issuer fails to exercise acceptable levels of security and diligence, they can have this trust revoked at the discretion of the browser makers. This could render invalid some or all of the SSL certificates that they've issued. While such occurences are rare, major websites typically use the more established and reputable issuers, which also tend to be more expensive.
Prestige and reputation can be a factor. Users who are very discriminating and technical may look at the issuer and level of a certificate, and use that to judge the trustworthiness and credibility of a website. A free or bargain-basement cert might be looked down upon.
For organizations wanting SSL on more than one domain, then a multi-domain SAN cert is an option. These support up to five different domains. Prices fluctuate, but if you have three or more domains, then a SAN cert is usually cheaper than three individual basic certs from a commercial issuer.