The Not So Subtle Shift From Email

I’ve been providing IT support for customers for two decades. In that time, I’ve realized that the method in which people prefer to obtain support has changed dramatically.

Unfortunately, some companies make it difficult to reach a support representative. The theory is that by being less approachable customers will try to resolve the issues themselves. Requiring customers to make a phone call to cancel their account is part of this scheme. I have always firmly rejected this notion and instead opted for being as easy to contact as possible. Doing so carries a bit more cost, but in the long run, its worth it. I have been lucky enough to meet some amazing people from all corners of the globe, and helping them with their issues has been a pleasure I wouldn’t have received if I hadn’t made sure our support staff was easy to contact.

In the late 90’s, customers wanted phone support. Amazingly, even some firms provided support by fax! Regardless, phone was the easiest and provided the most immediate and consistent response. During the first decade of the new millennium, customers warmed up to email and eventually preferred it because more technical information could be conveyed. Reliability and speed of email slowly increased to where it became the preferred method of contact. As email’s popularity grew, so did spam. Stronger anti-spam solutions were developed, and some were so effective that they rejected most legitimate mail as well. The frequency that people checked their email began to decline, and now, outside of business, email is often considered an afterthought – used primarily to register for services online.

Soon, more consistent and less noisy methods of communication were developed, including text messaging (SMS), social media messaging like Facebook’s Messenger, and Slack. Nearly everyone had access to text messaging, and many use Facebook Messenger every day to communicate with friends and family. Slack provides excellent communication for businesses. Along with phone and email support, we offer Slack-based support with our retainer customers, but something else was needed to help fill the gap between our corporate clients and our busy professionals on the go who weren’t usually in front of a computer screen.

That’s where text messaging came in. By offering a support text messaging system directly integrated into our help desk, any text message sent to our 256-973-9996 number is automatically converted into a support ticket. It shows as coming from a text message so that support technicians know to keep replies brief. Since we launched this service at the beginning of 2017 we’ve had many clients take advantage of it, and we’ve received tremendously positive feedback from it.  What’s more, in developing this system, we have the expertise to now add text messaging support (both incoming and outgoing) to your website or mobile application. We have clients using our text messaging integrations to deliver powerful marketing messages and reminders, and have highly reliable incoming text support code available to add superior interactivity to your business.

If trends continue, we expect alternative methods like text messaging support, Facebook messenger, and Slack to continue to overtake use of email in our support operations. Of course, the good old fashioned phone is always an option. Interestingly enough, I’ve had several great conversations with our clients on this exact subject via phone! Give me a call or text and we’ll talk about your project.

 

Advertisements

No Need to Hide Your Email

It’s very likely that spammers already have it!

This topic comes up from time to time while developing websites.  Oftentimes clients will ask to obfuscate their email address on their contact page.  While this was previously a very good piece of advise, it is no longer necessary for a multitude of reasons.

If you’re a business, you want people to contact you.  Of course you don’t want spammers but as I said they very likely have your e-mail address anyway.  While web scraping for email addresses is still done, the value of an email address to a spammer is a lot less than it used to be.

Comment and form spam is far more prevalent, so if you hide your email behind a form without taking a set of very specific precautions, you’re more likely to be spammed through the form than via a harvested email address.  Contact forms can break or be compromised, so unless you’re storing your comments in a database, you could lose important contacts.

Javascript obfuscation of an e-mail address might seem effective but a smart web bot can see right through it.  And even if it was completely effective, you run the risk of people who use ad and script blocking software visitors not able to retrieve your address. Additionally, some mobile browsers may have issues with this, especially if Adobe Flash is used in the process.

Of course you may want to omit your email address entirely if you are trying to stay anonymous on your site, but for business purposes this would be counter productive. You’re far more likely to be spammed via other means, so there is little reason to hide your email address on your website if you want people to contact you.

Setting Up a Site in Dreamweaver

In some circles Dreamweaver isn’t the “in” tool to use, but for general everyday HTML editing it’s hard to beat Adobe’s WYSIWIG tool.  Setting up a local site is very easy and straightforward, but connecting to a remote server can be a bit challenging for a newcomer, so I’ve decided to write a guide on how to do just that.

If You Already Have a Site Profile

If you haven’t created the site locally yet, please ignore this section and skip to step 1.

If you already have a site created in Dreamweaver and just need to add a remote server, click on the Site menu, then Manage Sites, and then double-click the site profile you have already created.  After you’ve completed this, skip over step one and proceed to step 2.

Step 1 – Creating the Site & Local Settings

Launch Dreamweaver then click on the Site menu then click New Site and you’ll be presented with the new site dialog.  For the site name, enter the name of your site.  I generally go by the friendly name (for example, OCS Solutions instead of http://www.ocssolutions.com, but it really doesn’t matter).  For the local site folder pick a folder on your hard drive that you want to use to store a local copy of the site.  I like to put it in the Websites folder that I have in Dropbox for instant backup and quick-and-dirty version control (I use Git for version control but Dropbox works well here for a simple HTML site).

Step 2 – Setting Server Settings

Click on the Servers tab on the side of the Site Setup dialog and click the plus sign.  It’s in a strange, out of the way location so I’ve highlighted it with my mouse in this screenshot.

2016-01-21 23_46_31-Site Setup for OCS Linux.png

When you click the plus sign you’ll see the FTP settings.  If you host with OCS Solutions, you’ll use SFTP so make sure you change the Connect Using dropdown to SFTP.  You may have to ask your host for the server name (though you can usually find this in your control panel), but the username and password you’ll likely already know.  With OCS they are the same as your cPanel username and password.  The root directory will usually be:

/home/username/public_html

Where username is your username.  Once you’re done click Test and if it passes you can click Save to save the settings.

That’s it – you’re finished setting up a Dreamweaver site with a remote server.  Now you can click the Local View drop down box to switch between the file view of local and the remote server.

2016-01-21 23_56_41-Adobe Dreamweaver CC 2015.png

To upload a file, use the up and down arrows while highlighting a file.  To edit a remote file, double click the file on the remote server view.

I hope this quick guide helps you with starting a simple site with Dreamweaver.

Do You Need a Responsive Website?

Happy New Year!

I’m asked about responsive websites quite a bit so I decided to answer for everyone in a blog post.  Before I answer, I should define the term responsive website.  A responsive website is simply a site design that adjusts automatically to any kind of device, including phones, tablets, laptops, and even larger desktop screens.

To answer the question – yes, in most cases, your website needs to be responsive.  While I know some people may question my recommendation and suggest that your site should always be responsive, I believe that it strongly depends on your target audience.

For most websites, more than half of your visitors will be accessing it via a phone or tablet. Laptop and desktop viewers are now a minority.  However, this does not hold true for absolutely every demographic of visitor or niche.

If your website targets markets that are less likely to surf on their phone then it may not be necessary to move to a responsive design at this point. A simpler or legacy format might be essential for some embedded markets that cannot take advantage of modern browsers.  Also, genres of websites like video gaming, for example, may be accessed more on desktops than on phones.

Having said that, everyone should be considering moving to a responsive website at some point in the future.  If you don’t have a very specific niche as mentioned above, then you already need to be responsive.  If you aren’t, you will suffer a penalty in search results with Google and mobile visitors will have a harder time using your site.

At OCS we use Twitter Bootstrap for our responsive web design.  We’ve found it to be the easiest, most compatible responsive framework to use.  If you choose to use WordPress instead of a pure-HTML or PHP/ASP.NET based design, we recommend ensuring that the theme uses Bootstrap for maximum compatibility.

Linux for Web Developers

If you are a web developer, you’ll no doubt need access to the myriad of command line tools that now power modern web design.  It seems that, for better or worse, the Node Package Manager (NPM) is standard equipment in a web developer’s tool chest. If you’re not a native Linux user, this can present a challenge, both on Windows and Mac.

This article will focus on providing a high-level overview of setting up a Linux development environment for Windows users.  It’s a bit easier to get a command line web development tool set going on Mac but I’ve always preferred to pick my own hardware and not pay a fortune for it.  I also can’t stand the Mac file system layout, UI navigation, and proprietary smugness of the operating system.  That will be the end of my Mac bashing for the remainder of this article.

I’m currently using Windows 10 on both my desktop and laptop, and while its far from perfect (you should turn off as much of the privacy-violating stuff as you can), it does a great job of providing the underpinning to my setup.  I would  use Linux full time if I could, but my gaming and Adobe addictions make that a difficult challenge.  Instead, I use Windows and run Linux in a virtual machine.

I’ve always been a fan of VirtualBox.  It’s open-source, free, and runs very well.  Out of the many Linux distributions I’ve tried in a virtualized environment I’ve found Linux Mint or Ubuntu to run the best.  I’d prefer Debian or Arch, but I’ve found that both Mint and Ubuntu have the best long term support (as long as you pick the LTS releases) and virtualization support right out of the box.  CentOS makes a great choice on the server but with little out of the box support for many of the web development tools you’ll need it just doesn’t make sense on a workstation.

Installing the various web development command line tools in Linux is extremely straightforward and requires little instruction.  If you go to each of the respective web pages for each software package you’ll find easy instructions tailored for your distribution.  Within just a few minutes after install you’ll be ready to go.  Since I do most of my work in Vim I skip fancy IDEs, but if they are your preference its easy to install Eclipse and others via the software package manager in Mint or Ubuntu.

The tricky part comes with sharing data with your host machine. VirtualBox includes shared folder support – allowing you to mount a Windows folder in Linux.  While that does work, I prefer simply sharing the folder natively in Windows then mounting it in Linux.  This avoids using custom kernel plugins that can change over time and allows you to access these folders on other machines as well.

You can also keep all of your work in Dropbox and install the Dropbox client inside your virtualized Linux environment.  This solution works well enough and provides an extra layer of backup for your work, but if you have a lot of data in your Dropbox account its strongly advisable to select only your work folders to be accessible inside your Linux system else you’ll end up duplicating your entire Dropbox folder structure which could be a problem if you’re on a smaller solid-state drive.

If you use Windows Backup or Acronis to do a bare-metal back up your Windows installation, you’ll also be backing up your Linux work environment as well – something that will greatly simply your backup strategy.  If you choose to throw Dropbox in the mix then you dramatically increase your protection against data loss and hardware failure.

I hope this post has given you a good overview of web development with Linux on Windows.  For now I wanted to share my overall thoughts and methodologies, but in future articles I’ll be digging into the specifics of installing a virtualized Linux environment, setting up specific tools, and optimizing the web development workflow.

This may be my last post before Christmas so best wishes for you and your family.  I hope you have a wonderful holiday!

 

The www Saga – Should Your Domain Be Naked?

Long ago, near the dawn of the UNIX epoch, servers were generally single-task in nature.  To have one server machine fill multiple roles was unusual.  This was because CPU cycles, RAM, and disk space were hard to find and what resources a machine did have needed to be available for the task at hand.

This situation gave rise to the Internet-naming scheme of putting www before a website address.  The reason for this was that there was literally a machine named www that served the website for that domain.  In today’s era of virtualization, this is no longer the case.  A single server can host thousands of websites and the www prefix is slowly falling out of favor.

There is a debate among webmasters about using the www prefix before your domain name.  To not use it is referred to as a naked domain, that is, typing yourdomain.com into the browser to reach your site without the www before it.  In the past websites have generally accepted both but redirected to the www version.  Now it is increasingly common to see sites use the non-www variety and redirect to the reverse.

Google understands the difference and will not penalize you for duplicate content if you serve from both versions. It really doesn’t matter what you choose but whatever you do it is strongly advised to be consistent.  If you want to use www in front of your domain, then always use it.  If you don’t want to, don’t link to it with www in front of the domain.  Here are some ways to accomplish that:

WordPress

If you use WordPress, this is a fairly simple situation to solve.  In the General page under Settings, simply specify the version you’d like to use. In this case for our site we use the www version because our site has been around since 1997 and we have a lot of links to that variation.  Specifying this here will redirect non-www requests to the proper URL.

general-settings-www.png

Other Linux-based Sites (Static HTML, PHP, etc.)

If you’re not using WordPress, you can use an .htaccess rule to address this situation.  For example, this rule:

RewriteCond %{HTTP_HOST} ^[^.]+\.[^.]+$
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This will redirect all traffic to the www version of your site and respect the use of SSL.  You can remove the www. from the last line above to do the opposite.  Do not use this solution if you are using WordPress – the two rules can conflict or, at best, unnecessarily duplicate each other.

Microsoft IIS

For .NET websites, you can use the web.config solution here to handle www redirection.