Imagine this: an editor has a team of reporters in the field who don’t have time to log into a CMS to file articles. Problem is, these reporters are covering an ongoing situation, and their organization needs a constant stream of updates to stand out against competition and, more importantly, inform and engage readers.
In this situation, the need for a mobile CMS is obvious. Giving reporters, photographers and other employees quick and streamlined access to your CMS—especially when they can’t formally log in via browser—is crucial to meeting your content needs.
The Brightspot CMS was built with publishers in mind, allowing them to publish engaging content seamlessly on desktop, tablet and mobile interfaces. Brightspot goes even further, though, enabling the employees mentioned above with its "Email to CMS" feature, available out-of-the-box for clients whose teams need workflow flexibility in situations when opening a laptop isn't possible.
How Brightspot's Email to CMS works
Right away, Brightspot’s "Email to CMS" feature is designed to handle two content types: Article and Image. A reporter can simply draft a new email using an email client (Gmail, Outlook, Hotmail, etc.) and begin drafting the story, which may already be the process to which they are accustomed.
When finished, the reporter can add hashtags (i.e. #headline, #body, etc.) to direct Brightspot to populate corresponding fields with the data the reporter has entered. In a typical "Email to CMS" implementation, if images are added as attachments, the first image will automatically be loaded into the Lead field and any other images will upload as Image assets. If the email author matches the email address Brightspot has on file for a CMS user, that user will automatically be credited as the Author of the Article once passed into the CMS.
Upon hitting “Send” on the email, the data that the reporter entered is pushed into the CMS as a draft, which the editor can then review, edit and publish—or whatever happens to be the next step of the custom workflow you have set up.
Inside "Email to CMS"
What’s going on behind the scenes? A lot of it is a very simple configuration process that begins in the Sites & Settings area in Brightspot. Here, the following items can be configured:
- Receiving Email Address (i.e. firstname.lastname@example.org)
- Parsing Method
- Field Delimiter
- Content Types (to be created in CMS)
- Various processors for fields (Headline, Body, Section, Tags)
- State of submitted asset (Draft or Published)
Once these configurations are in place and before any conversion happens, Brightspot moves onto the retrieval process, leveraging simple yet robust offerings from cloud providers, like Amazon Web Services or Azure, for example.
When an email is sent to the email inbox that has been configured to receive soon-to-be Articles, it enters a queuing bucket, where it remains until it is added to a queue that is hooked up to a notification service.
It’s this notification service that talks to Brightspot; Brightspot, therefore, makes periodic calls to check the notification service to see if there are emails in the queue. If there are, Brightspot pulls them out of the queue.
Brightspot then takes the Java object of the email that is sent, and through the internal logic configured in the CMS (shown in the image above), Brightspot checks for the configured processors. The snippet below illustrates the code at work during this process.
Advice to developers configuring Email to CMS
Thinking of setting up "Email to CMS" in your Brightspot project? We recommend leveraging similar cloud infrastructures. Additionally, it is important to remember that not all email services are uniform—an integration like this that may deliver content seamlessly into Brightspot when sent with Gmail, but may not work quite as perfectly with mail sent from Outlook. That said, remember to account for differences and test across email clients. If accounting for Gmail, Outlook and Hotmail, chances are the bases will be covered, but it's worth understanding the most commonly used email platforms in your organization and prioritizing tests against those.