A few years ago we added the ability to embed a screenshot from a YouTube video through the CMS editor. This alleviated the need to take a screenshot, edit with software to add the play button, and then finally uploading it to the web server to embed it into a page or an email. With one click, pasting the url of the video a screenshot of the video can automatically be generated and embedded into a page.
But there was a problem
The default YouTube play button at the time was a red rectangle which does call a lot of attention and allows users to immediately identify what will happen when they click the image. It became a problem over time as more of our videos (especially now that we can upload a custom still photo as the default screenshot) became people with a YouTube play button head:
We are happy to announce the play button graphic has been swapped out with a more transparent version that equally emphasizes the screenshot and the fact that the image will link to a YouTube video.
Now at a glance you can see the details in screenshot while still still understanding the link will bring the you to a YouTube video.
How to use the YouTube screenshot button in the CMS:
With the upgrade, the old method of using the documents copy/paste method is now obsolete. Below is the new method to send an HTML email from Wayne Connect, using our CMS email manager:
Once you have finalized and reviewed your HTML Email inside the CMS email manager, click the “View Preview” button in the lower-right area in edit mode to bring up the “Preview Screen.”
Once in “Preview Mode” make sure all the users with access, including yourself, have approved the final HTML email in order to view it.
Once approved, right click and do a “Select All” in the area next to the content body, within the preview box. (If “Select All” is not available in your browser with “Right Click”, you can alternatively use the keyboard shortcut combination of “Control A” keys after clicking next to the content body.)
Once everything is selected, right click again and “Copy.”
Make sure under “Options” your preference is set to “Format to HTML.”
Right click in the body/text area and hit “Paste.”
You should now see your HTML Email in graphic format with the header and footer. Enter the email/Listerv address in the “To:” field and a Subject in the “Subject:” field. Always TEST Your Email Before sending the final!
We have had the best success with using the Firefox browser, when sending out HTML emails via Wayne Connect.
TEST, TEST, TEST! Always perform a quick test email to yourself and inspect it before sending the final.
The types of projects our department takes on seem to go in waves. A bit of a history lesson takes us back to an abundance of websites which pushed us to build the CMS. The many events that followed gave us the idea to write and centralize them all in to a university events calendar. Then came the RSVP’s for those events. We got fed up creating hundreds of forms so we wrote an RSVP system for the events calendar. After that the campus community could maintain their own websites, and create events and RSVP’s by themselves. They then asked us to create pretty HTML emails to announce all of these components and we did that for a while before crafting the self- serve HTML email creator.
Everything goes digital
Now we are on the age of transitioning traditional print newsletters to digital pieces. These are a little more complex than the standard email and sometimes connect to a broader website with more information. In the last four months we have literally transitioned more than ten complete print publications to online editions. I would love to say that in those four months we created a self-service system for the entire campus to create and maintain publications, but I can’t. They all seem to have some unique factor that required individual attention.
Requesting a new HTML newsletter can result in a 2 hour or up to a 40 hour project. It’s important to know what you need before starting the process. Let’s walk through the process of the newsletter request and I hope I’ll be able to shed some light on the reason for the complexity.
Simple single column email
The most basic email is just a single column with a single message and any action items go off to existing websites. The types of emails have a custom header that identifies your department or group and is reusable at your leisure.
Here are a few examples of single column emails we have done:
Multiple column email
Typically a multiple column email is required when there is a single message that needs to be communicated and the content warrants “action items” on the side. These can be: upcoming deadlines, buttons for next steps or just “for your information.” They’re a little more complex but offer some flexibility to highlight multiple items “above the fold”. (BTW, there is no fold on the Web.)
Here are a few examples of multiple column emails we have done:
Multiple column newsletter
Using the same format as the multiple column email the newsletter takes it one step further and keeps a consistent format but with categories and articles feeding in to compile a complete email. Typically the format is set up and each month/semester/year a new “publication” is created which consists of article titles, teaser descriptions and links off to more information.
If the links for each article go to existing stories already published on the Web it gets the user to interact with multiple areas of your website and possibly explore things they otherwise wouldn’t have without being prompted by the email.
Here are a few examples of multiple column newsletters we have done:
Newsletter Web page
Lastly the most complex and time consuming is the HTML newsletter that has a stand alone website which features the full text of each article and is organized like a newsletter with editions and archives. This approach is really driven by the print mentality of compiling an entire edition of articles and publishing the entire thing at once. It wraps up the email and website into a single package for the user to experience. One of the downsides, just like a printed newsletter/magazine is once the user receives it and browses through, they typically recycle it or close the window and never come back. Their only reason to come back in the future is when their next email comes in. It isn’t “sticky” and doesn’t build continuous engagement, but in the end it’s what most traditional writers are comfortable with.
Here are a few example of newsletter websites that we have done:
Thinking about requesting an HTML email?
Make sure you have thought through how you want it to work and be prepared to answer some tough questions by our team. Just because “email is free”, aka you don’t have to pay postage, it doesn’t mean that your audience will engage the same way they have in the past.
We are always looking for great stories and events happing around campus. We get alerted about a lot of them automatically but are always open to and encourage submissions. If you have something to submit please send us an email (firstname.lastname@example.org) with a title, description and a link where we can find more information. We will review each request to determine if and when it is appropriate to be included in the email.
Next phase of the roll out
Today@Wayne is always evolving. We get a lot of complaints about the quantity of emails that get sent out each day. We are working to solve that with the next phase of the Today@Wayne roll out. Instead of everyone on campus getting the same email each day we will be customizing the email to fit every individual. Based on campus role, faculty, staff, administration, etc, instead of getting ten emails a day, they will all be consolidated in to a new section in Today@Wayne. This will reduce the amount of email in your inbox and give control back to the user about which messages to read.
Something that has been on my mind for a while is the massive amount of internal email we get and send at Wayne State. There have been countless articleswrittenabout the death of email but from the user’s point of view it has appeared to pick up faster than normal. We do have a proposed solution coming, but is it going to be our saving grace? Or just another piece of noise?
I have a special “_email” folder in my inbox where I place ALL internal bulk mail. My hope is one day I would analyze it for who is sending out the most, create a wordle of the subjects or body of the messages but I just have not had time. But I wanted to do something useful with them.
The 10 second test
Just like a website, email has the same “10 second test” factor. I would argue it is shorter and a message may not even make it to the test if the subject (or sender) isn’t appealing enough. Since creation is decentralized on campus it is impossible to have a consistent message through every email. Additionally, every email has a specific audience who has different tolerances to the information they are use to (willing to) receive.
For those of you who don’t get as many emails as I do, I put together a representative sample of what is coming out of the university and going in to people’s inboxes. I am making no judgement about the content of the emails, purely looking at visuals in this case. Flip through the examples above as an end user. Some of which went out to lists with 50,000+ people on them, are they conveying the message you think they are trying to convey?
If you were trying to get your email read and have the recipient take action, how would you stand out? Which messages would you pay attention to? What catches your attention? Is it the images, colors, headings, links?
This last week we launched two newsletters. Over the last year or so schools and colleges across campus have been transitioning their traditional print publications to the web. Right now most are doing dual format but we expect them to go all digital over the next few years. This will not only allow them to save money (on postage and printing) but also get the word out to in a timely manor and start interacting with their audience.
College of Engineering – Exemplar
Traditionally a print magazine and will still be for some time but now they give their readers the option to read and subscribe online. The main audience is alumni and unfortunately they don’t have email addresses for them all. This is a slow transition by promoting the online version in print to get people to subscribe to the email and online version. It is still early so we don’t have statistics yet to show the conversion rate.
Also started out as a print newsletter but this one has gone all digital, no more print. Traditionally they would publish a PDF of the print version online but not many people were reading them. The new site also includes an HTML email formatted specifically to promote the primary articles and upcoming events. Below is the preview of the email.
Overall this trend doesn’t look like it’s going to stop. Almost all the school and college sites we do have brought up bringing their newsletter online. Initially these were all custom but as we do more of them we noticed tons of similarities. We are building the tools to bring this capability into the CMS for anyone who hosts a site through us to use. We will keep you updated on these features as they become available in the CMS.
Because we oversee 350+ Web sites and get a large number of new requests, questions and maintenance requests each day it’s important we have an efficient way to manage them all while still getting other work done. I cannot be at my computer all day so most of the requests have to be read and assigned by the team itself.
How we do it
We have a central email address. web [at] wayne [dot] edu. That email goes into a central inbox. Inside that inbox everyone has a folder and there is an archive folder where every project we work on has it’s own box.
This inbox is mapped to everyone’s computer. Throughout the day different people check the box and scan to determine who is the most appropriate to take each request. They put the email in the person’s folder and move on. The inbox then syncs across everyone’s computer.
We use a plugin called TruePreview for OS X Mail that keeps email’s unread until they are double clicked or force marked. This makes it possible for each of us is scanning the folders to see how many new emails are waiting.
This process allows everyone to have a list of items to read and respond to. If it was assigned by accident they can just move it into someone else’s folder and move on.
Once an email or task is done the whole conversation get moved into the z_Archive folder. Every project has their own folder to things are kept nice and neat. The beauty of it is the folders automatically update and everyone has the same content on their computers. No conversations or files are lost.
Why not use a ticket system?
Over the past 6 years we have played with the idea of a true ticket system, and have even tested a few. The problem is a separate system brings a level of unnecessary overhead. We don’t really need to pull stats from all the tickets and our staff really isn’t that large. Everyone already knows how to use email and having a central single interface makes processing hundreds of emails quite easy. There are downsides to our system though, like if someone deletes something it will probably be overlooked or if someone is sick and no one looks in their folder to pick up tasks. But this is a risk we are willing to take and is inherit to any task based system.
The solution to this tough problem doesn’t have to be a complex system. Our department strives to use existing tool and centralize and streamline as much as possible to get the most bang for the buck. We are use to working with limited resources and we apply this philosophy to everything we do. In this case a zero cost crowd sourced analyze and assign system was the best approach. I cannot be at my computer all day and I don’t want to be the one to have to look at all the requests and assigning them. Everyone knows their capabilities and has the authority and position to act on them as they see necessary. It’s a beautiful system that just works.
Added: I’m in no way saying this system is going to work for everyone but it works great for us.
Recently, I talked about the pros and cons of sending HTML vs Text emails to your clients in this article “Filling your inboxes with visual appealing HTML emails”. Since HTML Emails are becoming increasingly more popular to send here at Wayne State, we are trying to come up with a system that makes this painstakingly clumsy process as streamlined as possible.
Third party testing
If you have one main template and don’t have to create new ones often, a pay email testing service might be for you. For a small fee you can use one of these services to send your HTML code to and then it will produce screenshots of how the email looks in the most popular email clients. In addition, some of these services will also test how your email will react with spam filters.
If you don’t have the resources or funding to go with one of the automated services, you can go the “old fashioned way” and set up a series of test email accounts on all the popular email clients. To begin with, set up accounts on Hotmail, Yahoo, Google, AOL and of course, Outlook 2000, 2003, 2007 and Outlook Express. Don’t forget to test Apple Mail 2 and 3 and to test on the iPhone as well. This will get you tested in over 80% of all the popular email clients, according to Campaign Monitor as of June 2009, in their article Email client popularity.
Don’t forget to test email in popular mobile environments as well, iPhone for example is now more popular than gmail in viewing email. Once you establish some main HTML email templates the testing will get easier. When designing email templates, keep it simple. Trying too much, is one of the biggest mistakes designers do when creating HTML emails.
Here are some more good resources for getting a professional and cross-platform HTML email below. Remember to test, test, test!
Within the last year we have seen a dramatic increase for the demand of HTML emails. To keep up with the demand we have created some default templates for schools and colleges, as well as a very basic template to keep the Wayne State University brand uniform across campus.
There are two basic methods on sending email to your clients: HTML version and text only version. There are various advantages to each and it seems the HTML version is more popular based on demand.
Allows you to brand you emails, with the use of colors, logos and stucture
Visually appealing and you can get your point across with images
You can track your your email campaigns and see their effectiveness Better readability and people can skim over the content to get to the point fast
Each email client renders HTML coding differently, making it more challenging to design uniform looking campaigns, across all email software and applications
Can be more complicated to design and write for to avoid anti-spam filters
Increased chance someone won’t open the HTML email, because they are scared of getting a virus
Advantages: Concise and simple to produce
Looks more personal and will render correctly across all email clients increasing readability
Less problems with spam-filters and delivery
No Creativity present creating a flat “brandless” email
People more apt to delete or not read the whole message if in text format
Unable to track the campaign and analyze the open rates
There is alot of parameters to examine when choosing what format to create your email messages in. Wayne State University’s email client, Wayne Connect sends out an alternative text version of the HTML email as well, increasing the probability the client will get the message in their preferred format.
We intend on tracking some of these HTML email messages in the future to see how effective these campaigns have been. In the meantime, we will deliver what seems to be in high demand these days, which is creating the emails in HTML format to appease our visual nature.