Red Button Marketing
Red Button Marketing (RBM) is a PR agency that has specialized in helping companies and persons to promote themselves in social media.
RBM helps the company/person to identify what the hottest topics within their profession are.
RBM’s solution scans new blogs, tweets and hash tags posted by high profiled persons (lead stars) within the industry. This is how the company knows what the latest and greatest is and what they should blog about next. The solution also lets other people within the company come with suggestions for new company blog posts. Case officers write the blog post.
When a blog post is approved and published the red button starts blinking and the button is “armed”.
A Sith lord or commander pushes “The red button” (a physical red button). This trigger an event that at first blogs the spams social media such as Twitter, Facebook and LinkedIn with a link to the blog post.
In this way, the company or person shows the world that they too are experts within their field of profession.
Logging into SharePoint
When users log on to SharePoint they are routed to their correct role-based dashboard.
Flow chart explained
New suggestions are either added by users or by a search service. The search service is a configured Google Custom Search, but can be hooked up to any open search proivder. The search is configured to be scoped on several sites like TechNet, Social, yammer, facebook, twitter, etc. The search is done with a set of “buzzwords” distributed through a SharePoint list. The list of buzzords can be filled by registering leaders in the community and their hashtags or buzzwords.
The articles found with the keywords as searchterms will be grabbed and title and url to blog post is added to a SharePoint list. Users add new suggestions from the user dashboard.
The search service
To meet the need of our customers, we need to be able to find new and relevant articles on the internet. The search is done with a set of “buzzwords” distributed through a SharePoint list. The articles found will be grabbed and handed over to SharePoint Online and included in our internal workflow/production.
The solution consists of three parts.
We have configured a Google Custom Search. The search is configured to be scoped on several sites like TechNet, Social, etc, but – important: we’re NOT searching the whole internet.
Unfortunately the Google Custom Search only offers 100 free searches before we will have to pay. As a company, we would off course have paid the price – right here on ASPC2015 we don’t do that. Because of that, we’ve been forced to keep manual control over the Google search (else we would’ve ran out of fun within 5 minutes ….)
We have a server “out there” – from now on referred to as “The Bergen server” – on which our search app, resultstorer and services runs.
The first application is the controller. This app is executed manually to avoid running out of free search queries. When executed, this app takes the first buzzword and kicks off the second application. This application implements a call to the google custom search and receives the results before it calls our third application. This application stores the results in a database on the Bergen Server.
The forth app on the Bergen Server, is the app that hands over the search results to SharePoint Online when called. This app may be configured to only send results registered since day x, week y or – for that sake – all findings stored.
We have created a provider hosted app in Azure. This app looks pretty simple with one single button – but it has a very important job.
When the button is clicked, the app makes a call to our Bergen Server and gets all the latest search results found. When received, the app begins to iterate them. Every new item will be stored in the SharePoint list “Suggestions” – but NOT before we’ve checked if it already may exist in the list. The check is done by looking at the incoming items Google Cache Id and if there are items already stored with the same id (Google Cache –yes, that “dies” after a while – but in production, our scope is never longer than 1 to max 2 weeks. Checks shows that the Google cache lives longer for items that are created within the last or two weeks.
The user dashboard contains a add-new-suggestion button, a Visio web part which is connected to the suggestion list, and a web part showing filtered suggestions. The Visio web part is clickable and filters the suggestion list web part based on status (new, blogs in progress and blogs published). The picture shows the user dashboard with filter on published blogs.
The dashboards is made entirely on the client side and all the files are stored in Site Assets. By leveraging User Custom Actions we have deployed two js-files via the scriptlink. The files are jquery (always nice to have ready for action, and a small file called appLoader.js. The appLoader.js helps our development environment (hello SublimeText!) and extremely small-footprint clientside development.
The whole appLoader is the following code:
This means that are apps can be developed side by side and without the .tmp-issues that tend to follow mapping the O365-folders to your own machine.
The editor assigns a new suggestion to a case officer which writes a blog post. When the blog post is written the editor decides if it’s ok or not. If it’s not ok, it gets sent back to the case officer for more editing. When a blog post is ok, the editor changes status field in blog post by clicking on a button. This updates the suggestion list item and posts the blog post on WordPress. Then the the physical red button gets armed.
When the red button is pressed a blog post is created on wordpress (or your flavour of the month blogging-tool)
This is the WordPress-blog that starts everything.
with the use of ifttt.com it then publishes a post on facebook, twitter, and yammer with a link to the newly posted blog. This can of course be added on to more social media accounts.