October 17, 2014 - Comments Off on A Brief Description of the SPF record

A Brief Description of the SPF record

A client recently came to us with problems receiving emailed form submissions from their website. We did a little testing and realized that indeed the emails were being sent by the server but something was stopping them during transit. In our research, we had to dig deeper into SPF records.

An SPF (Sender Policy Framework) record, validates an IP address as permitted to send emails from that Domain. Once propagated, the DNS record serves as a list of verified senders, which the recipient of an email can use to check against.

The SPF record was introduced because the ubiquitous SMTP (Simple Mail Transfer Protocol) allows a computer to send email claiming to be from any domain. Spam and phishing emailers use this to send email purporting to be from a trusted source.

With an SPF record, a receivers spam filter is more likely to accept the message as it is coming from a validated source. It also discourages potential spammers from using your domain as a sending address, knowing that domains with SPF records are more likely to be rejected by recipient spam filters, if the senders IP does not match one associated with the record.

Once an SPF record is created, it is important to ensure that all computers that will be sending emails are included, as the presence of the record indicates that any email not declared is dubious. This is the problem we ran into, where an SPF record was added to the DNS zone, but did not include the server hosting the website in it’s list of IP addresses.

Here is an example SPF TXT record:

example.com TXT “v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a ~all”

Published by: georgebrassey in The Programming Mechanism
Tags:

October 3, 2014 - Comments Off on Avoiding a Mobile House of Cards

Avoiding a Mobile House of Cards

netflix-kevin-spacey

"There’s no better way to overpower a trickle of doubt than with a flood of naked truth." -Francis Underwood

In 2010, Morgan Stanley Research extended their financial necks and predicted that the "mobile internet would overtake the desktop PC by 2014." I talked about the importance of that research the first time I spoke at the PRSA International conference about mobile in 2011. So, how accurate were they (and [arguably] even more importantly, how foolish might I look this year, if they were wrong)?

In January 2014, according to data from comScore, cited by research firm, Enders Analysis, mobile devices accounted for 55% of Internet usage in the United States. Traffic from PC's clocked in at 45%. A mobile strategy is no longer a "nice to have" luxury - it's the present and future of communications with regard to B2C and B2B communications. Companies and corporations that have yet to allocate resources for a mobile strategy, or have taken shortcuts with their mobile approach are building a house of cards – and it's about to take a tumble. Mobile has won.

The dictionary defines a "House of Cards" as a flimsy structure, arrangement, or situation that is in danger of collapsing or failing.

Your first consideration for expanding or enhancing any brand within the digital space begins with how the information will be received on a mobile device. While the near future will likely include universally acceptable, massive flatscreen entertainment portals with easy-to-use internet access, for the moment we’re talking about the now instead of the future now – while planning both responsively and reactively for the eventual.

Three Questions

There are three high-level questions to ask when building a strategy to avoid a house of cards. While these bullets may appear simple, the details are important. Building upon a structure of understanding carefully will elevate further insights and ultimately determine how well received your digital experience will be on all devices.

  • Who is the audience?
  • What do they want?
  • Where are they accessing content?

"After all, we are nothing more or less than what we choose to reveal." -Francis Underwood

Who is the audience?

Speak openly and honestly with your client about their audience. Conduct interviews with key stakeholders. Learn about your clients competitors and review the digital experiences they are likely to visit in tandem with your clients brand. Build exhaustive and clear user case studies to better understand gender, age and other criteria, to consider who will be accessing brand from a digital perspective. If the client has been online for some time, request access to a potentially vast treasure trove of information available from Google analytics to expose further details about the audience: specific times they are most likely accessing the site; what devices they are using. All of this information will allow you to prepare surmountable goals and clear the path for the measurable and appropriate design/UI decisions you will soon be making.

What do they want?

From a mile up, the client or a copywriting research team should be able to articulate what content best suits the audience. Aside from the standard questions that will help design a high-level content inventory plan, the importance of how vastly different mobile content is from the desktop is crucial and must be articulated to the client. To start with the obvious, the real estate you have to work with is different. Consider quantity and the breadth of content you should show to someone on a mobile device vs. a larger tablet or desktop device. Keep in mind, mobile users are on the go, and have a shortened attention span. Content should should always be readable, usable and most importantly – appropriate for the device.

To take a page from Apple’s iOS guidelines, "Text is legible, icons are precise and lucid, adornments are subtle and appropriate and a sharpened focus on functionality should motivate the design." For smartphones in particular, a single column layout is the easiest to absorb for mobile, and calls to action should should be represented by areas no smaller than 44px x 44px (here's a case where a "rule of thumb" is about your actual thumbs). Place important content above the "fold", or immediately viewable area on mobile – like contact info and important calls to action.

Where are they accessing content?

Business Intelligence gained through data collection is imperative. According to IBM, Five petabytes of data are generated every day by mobile phone subscribers. This is roughly the equivalent of 100 million four-drawer filing cabinets filled with paper. The means the data you need to best serve mobile content to your audience is out there.

Google Analytics (GA) data will help, as will statistical data, reports about your client's industry and the general mobile landscape, and interviews with key stakeholders and investors. Google Analytics reports will aid in understanding the devices and mobile operating systems currently accessing a digital experience, as well as the location that they are accessing the experience from. If your client is international, pay close attention to their specific carriers and regions. This is also important if your client is predominantly reaching a North America or United States-only market as well. There are still areas in this hyper-connected country where connectivity is spotty or slower than you might expect.

Your plan should be to create the fastest loading experience for your mobile audience as possible, regardless of the device. This can be accomplished in several ways, one of which is limiting or eliminating images that are unnecessary for the overall user experience. When using icons as calls to action, utilize a single image (usually referred to in the HTML development world as a "sprite") for multiple icons to create a single call to the server, cutting down on latency issues that slow down user experience. 60% of visitors on a mobile device wait 3 seconds or less for your page to load on mobile.

We no longer access the majority of our internet content from the desktop. According to a survey run by Google/Nielsen in Q4 of 2012, 77% of mobile searches were from a location (work or home) likely to have a desktop PC available. Stationary, plugged-in devices are not suitable for today's attention deficit disorder audience. We're easily distracted multi-taskers – always on the move – and as such – we want our content to join us on our journey. We desire access to data at our beck and call. Always consider how to deliver content to smartphones, phablets, tablets, wearables, and even ultra books - all devices that are in the mobile ecosystem and the inevitable future of the post desktop landscape.

"There are two kinds of pain. The sort of pain that makes you strong and useless pain, the sort of pain that’s only suffering. I have no patience for useless things." -Francis Underwood

Building a mobile strategy isn't easy. Mobile involves many moving parts, working with right digital partners, and the willingness to take risks based on the inevitable future. 40% of mobile users turn to a competitor’s site after a bad mobile experience, and this number is growing. It's especially difficult for large corporations to jump in full throttle – but they must. If not, they will likely perish under the waves of progress and watch helplessly as the mobile house of cards inevitably collapses around their valuable brand.

Published by: davefletcher in Entertainment, The Thinking Mechanism
Tags: ,

September 26, 2014 - Comments Off on Biz Dev Q&A 002 with Raynald Leconte

Biz Dev Q&A 002 with Raynald Leconte

raynald-leconte

Welcome back to The Mechanism's Business Development Q&A. This is the second post in this series, in which we will be presenting our Director of New Business Strategy, Raynald Leconte, with a unique question each month and picking his brain a bit to learn some of the secrets he's picked up through the years. Raynald comes with a wealth of expertise acquired through decades of experience in business development. We hope you find this series useful & engaging!

You can find our first question to Raynald here.

Let's continue with our second question.

Q: What do you think makes a great salesperson?

RL: "Easy - resilience, personality, good listening skills, killer instincts, and thick skin! A good judge of character also never hurts. Most importantly, though, good salespeople know how to properly close a deal."

Published by: antonioortiz in The Internal Mechanism
Tags: , , , ,

September 19, 2014 - Comments Off on The MechCast 306b: How has the Internet changed the way we listen to music? (Part 2)

The MechCast 306b: How has the Internet changed the way we listen to music? (Part 2)

blog_post

Welcome to The MechCast! This is the Part II of a 2 part series. In this episode, we'll be discussing how the onset of the Internet has changed the way we listen to music, and the impact it has had on the record industry itself. We welcome a special guest – NYU's own Professor of Punk – Vivien Goldman.

Music

  • Bob Marley - Natural Mystic
  • Sex Pistols - God Save The Queen

Related Links

Published by: antonioortiz in The Mechcast
Tags: , , , ,

September 12, 2014 - Comments Off on The MechCast 306a: How has the Internet changed the way we listen to music? (Part 1)

The MechCast 306a: How has the Internet changed the way we listen to music? (Part 1)

internet-music-industry

In this episode of The MechCast, we'll be discussing how the onset of the Internet has changed the way we listen to music, and the impact it has had on the record industry itself. We welcome a special guest – NYU's own Professor of Punk – Vivien Goldman.

Music

  • Bob Marley - Natural Mystic
  • Sex Pistols - God Save The Queen

Related Links

Published by: antonioortiz in The Mechcast
Tags: , ,

August 22, 2014 - Comments Off on Biz Dev Q&A 001 with Raynald Leconte

Biz Dev Q&A 001 with Raynald Leconte

raynald-leconte

We recently welcomed our newest member to Team Mechanism, Raynald Leconte. Raynald is our Director of New Business Strategy, and he comes with a wealth of expertise acquired through decades of experience in business development. We will be presenting him with a unique question each month and picking his brain a bit to learn some of the secrets he's picked up through the years.

Let's get started with our first question.

Q: What attracted you to this role?

RL: "Vision, vision, vision! Dave's vision in terms of connecting people back to people in this plethora of apps and mobile devices is right on for future and successful digital, design and development agencies. I believe that creativity is becoming even more important as we tackle problem solving in the digital space still finding itself."

Published by: antonioortiz in The Internal Mechanism
Tags: , ,

August 19, 2014 - Comments Off on Could the iWatch Revolutionize Medical Research?

Could the iWatch Revolutionize Medical Research?

“Talkback Tuesdays” is an original weekly installment where a team member of The Mechanism is asked one question pertaining to digital design, inspiration, and experience. The Q&A will be featured here on The Mechanism Blog as well as on The Mechanism’s Facebook, Twitter, and Instagram, every Tuesday. Feel free to offer up your 2¢ in the comments.

George Brassey, The Mechanism’s lead developer, discusses the great potential smart watches can have in revolutionizing medical research and healthcare management. It seems like only a matter of time!

What new piece of tech are you most excited about hitting shelves?

I'm excited to see what sensors Apple will introduce with the iWatch. I'm hoping they announce a watch with an array of sensors which might revolutionize health care research. Last year there was a huge amount of media buzz around the wearable space, with nothing appearing. This year the rumor mill is turning again and it sounds like Apple will finally announce an iWatch next month to be released later this year/early next year. Why am I interested? Last year I didn't like the idea of the wearable. The potential uses didn't interest me. I already have a phone, tablet and laptop. I don't need yet another screen. Especially considering how limited the functionality will be on such a small device. This year, however, I've been hearing about the sensors that will be included.

I'm a migraine sufferer. From time to time, without warning, I get massive blind spots in my field of vision, followed by debilitating headaches. Research on migraines has been inconclusive. The Mayo Clinic lists: hormones, foods, food additives, drinks, stress, sensory stimuli, changes in wake-sleep pattern, physical factors, changes in the environment, and medications; as potential causes. That's a long list with very little practical information as to how to prevent a migraine. I will be interested to see what could be learned by analyzing various health markers preceding migraines.

Depending on how Apple's new Healthkit SDK deals with privacy, the platform could standardize the sharing of medical records. Currently, there is very little access to medical data for researchers. Fears of records getting into the wrong hands means that acquiring data for research often requires a new study, even if a similar study has been done before. This involves, raising money, finding volunteers and conducting the study which may take months, even years. Most health information is under lock and key. The proliferation of devices to passively record a wealth of data could provide easy access for life saving research.

August 15, 2014 - Comments Off on How to Build an Easy Embedabble Widget

How to Build an Easy Embedabble Widget

Building with iframes is a fantastic way to create seamless, easy to implement, embeddable widgets. Once set up, creating multiple instances linking to your service is easy to do. Existing within a website, an iframe is like a window onto another website. Rather than forcing open another window, a user can interact with another service within the context of the website they have navigated to. The experience is smooth for the visitor, who will find the relevant service presented inline.

Over here at The Mechanism, we have been using iframes to integrate our custom bug tracking solution with client websites during user assisted testing. We needed an inconspicuous tool which would allow clients to seamlessly review work and submit bugs as they find them.

The requirements for this front end bug catcher:

  1. Simple to embed and easy to implement across many projects
  2. Sandboxed so that it doesn't cause any conflicts with the project DOM, JS or CSS
  3. Simple architecture which works on all browsers
  4. Responsive; it must work on all device sizes and form factors
  5. Context Aware; diagnostic information will require knowledge of the parent document (the website under bug tracking )

Our first iteration of the bug tracking widget violated the second requirement. For our first prototype, we loaded a script and pulled in our view and styling files through JSONP (a method for circumventing Same-Origin Policy, you can read about it here). This worked in our limited prototype but caused a few issues. First of all, we had to give our DOM elements verbose ID's and class names to ensure there would no conflict with the parent document. Secondly, we ran the risk of causing script conflicts with our dependencies. We used a script loader to minimize this risk, however we could never be sure. Finally, we were at the mercy of the stylesheets loaded by the parent which required us to write additional resets to ensure consistent appearance across projects. However, repairs like this are equivalent to bailing a sinking ship rather than repairing the leak.

So for our second iteration we converted the widget into an iframe. To do so we still had to find a way to get around the Same-Origin Policy. The Same-Origin Policy restricts communication between two documents; the parent window and the iframe. Cross Document Messaging is a new addition to the HTML5 specification, which allows for simple string communication between documents. This is supported by most modern browsers, however, there are many hacks necessary for older browsers.

easyXDM

easyXDM is a great library built to cross this great divide introduced by iframes. It uses the HTML5 postMessage() method when available and uses many fallbacks when necessary, ensuring the free flow of information between documents. For the developer, it exposes two protocols for data transfer. The first is a socket, which will send a string between the documents. This method requires us to parse and decipher the string before performing the relevant action on that information. The second option is an RPC (Remote Procedure Call), specifically JSON-RPC. JSON-RPC is a specification for calling functions from remote software, and for data to be returned. This allows for a much more dynamic interaction between our two documents where each process exists in their relative scope and can communicate as discreet functions would be expected. For our needs, the simpler option and the one we will be employing is the RPC protocol.

To implement easyXDM we must load our dependency and create an RPC instance, with the necessary proxy objects and method stubs. We will initiate this within a script loaded on the parent document. This script will embed our iframe and act as our gateway to the bug tracking widget.

On our parent document we will place an asynchronous script call to our remote script

 

// footer.html

 

In our script we will start by loading our easyXDM dependency

 

// main.js

var serverURL = 'http://www.example.com/our-remote-service/',

iframeFile = 'iframe.html',

depends = {

'easyXDM': serverURL + 'js/easyXDM.min.js'

};

Object.size = function(obj) {

var size = 0, key;

for (key in obj) {

if (obj.hasOwnProperty(key)) size++;

}

return size;

}

var scriptCount = Object.size(depends); // count of scripts required

var scriptLoads = 0; // count of script loaded

for (var key in depends) {

if (depends.hasOwnProperty(key)) {

loadScript(key, depends[key], function() {

scriptLoads++;

if (scriptLoads === scriptCount) {

main();

}

});

}

}

function loadScript (dependency, src, callback) {

// this function checks if the dependency is present.

// it waits for load before executing the callback.

if (window[dependency] === undefined) { // if dependency is not present

var scriptTag = document.createElement('script');

scriptTag.setAttribute('type', 'text/javascript');

scriptTag.setAttribute('src', src);

if (scriptTag.readyState) {

scriptTag.onreadystatechange = function () { // For old versions of IE

if (this.readyState == 'complete' || this.readyState == 'loaded') {

callback();

}

};

} else { // Other browsers

scriptTag.onload = callback;

}

(document.getElementsByTagName("head")[0] || document.documentElement).appendChild(scriptTag);

} else {

callback();

}

}

 

  1. Lines 1-5 we are declaring a some variables that will be used later.
  2. Lines 7-16 we extend the Object object with a method which will return the length of our depends array on line 15, along with a variable to hold an index value.
  3. Lines 18-27, we run a loop through the depends array and call a function loadScript(), which takes the name of our dependency, the url it can be found at and a callback which will be run once the dependency is loaded.
  4. Lines 29-49, our function which will test the presence of the dependency and load the script if it is not found. It uses various methods to ensure the script is loaded before running the callback function.

Next we will create our RPC instance which will load the iframe

 

// main.js

.

.

.

var iframeContainer = document.createElement('div');

iframeContainer.style.position = 'fixed';

iframeContainer.style.zIndex = 999;

iframeContainer.style.bottom = 0;

iframeContainer.style.left = 0;

iframeContainer.style.top = "auto";

iframeContainer.style.right = "auto";

iframeContainer.style['max-height'] = '100%';

iframeContainer.style['max-width'] = '100%';

document.getElementsByTagName('body')[0].appendChild(iframeContainer);

var rpc = new easyXDM.Rpc({

remote: serverURL + iframeFile,

container: iframeContainer,

props: {

id: 'bug-iframe',

frameborder: '0',

scrolling: 'no',

marginwidth: '0',

marginheight: '0',

allowTransparency: 'true',

style: {

height: '100%',

width: '100%',

display: 'block'

}

}

},

{

local: {

resizeiFrame: function (widthReq, heightReq, allowScroll) {

var windowWidth = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth,

windowHeight = window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight;

var width = (widthReq < windowWidth) ? widthReq : windowWidth;

var height = (heightReq < windowHeight) ? heightReq : windowHeight;

iframeContainer.style.width = width + 'px';

iframeContainer.style.height = height + 'px';

var sc = (allowScroll) ? 'yes' : 'no';

document.getElementById('mech-bug-iframe').scrolling = sc;

return {

x: width,

y: height

};

},

parentInfo: function () {

return {

width: window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth,

height: window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight,

url: window.location.href

};

}

}

});

 

  1. Lines 5-16; we are creating the iframes container with properties for it's layout within the parent documents DOM
  2. Lines 18-34; our RPC instance with the address to find the iframe contents, a container to place the div in, and some properties to control it's appearance
  3. Lines 34-64; is where we declare the methods we will be exposing to our iframe. resizeiFrame() and parentInfo() will allow us the adjust the size of the iframe and return diagnostic information respectively. They will be called from within our iframe

In our iframes markup we will load easyXDM and a shiv for older browsers without support for JSON, plus another .js file where we will instatiate our RPC connection.

 

 

In our iframe-main.js file, we will create another instance of easyXDM.Rpc and create stubs for our remote methods

 

// iframe-main.js

var rpc = new easyXDM.Rpc({},

{

remote: {

resizeiFrame: {},

parentInfo: {}

}

});

.

.

.

rpc.parentInfo(function(parentInfo) {

var diagObject = {

'width' = parentInfo.width,

'height' = parentInfo.height,

'url' = parentInfo.url

}

});

 

  1. Lines 2-8; we create our rpc object with the relevant stubs, referring to the remote methods
  2. Lines 14-20; an example of how we call our remote function. Notice the anonymous function we pass to the remote function to return our requested data. This is an asynchronous function

Stay tuned for more on the Venus project to find out where it goes next. Dhruv Mehrotra will be back in a few weeks with a blog post going over some of the steps taken to set up the Ruby on Rails server behind Venus. And we will have meetup at our offices the second week of September. Hope to see you there!

Published by: georgebrassey in The Programming Mechanism
Tags: , , , ,

August 12, 2014 - Comments Off on Finding Design Inspiration with The Mechanism Founder – Talkback Tuesday

Finding Design Inspiration with The Mechanism Founder – Talkback Tuesday

"Talkback Tuesdays" is an original weekly installment where a team member of The Mechanism is asked one question pertaining to digital design, inspiration, and experience. The Q&A will be featured here on The Mechanism Blog as well as on The Mechanism's Facebook, Twitter, and Instagram, every Tuesday. Feel free to offer up your 2¢ in the comments.

This week The Mechanism Founder, and all around design-guru, Dave Fletcher, discusses why his photography is one of the first places he turns for design inspiration.

dino-1

Where do you find design inspiration?

Since around 1996, I’ve been taking an abundance of digital photographs from my travels to conferences, events and holidays. Simply being able to look into my treasure trove of images has helped me out of an occasional creative jam. From a photo, I generally can find a color palette or typographic element that ignites something new, or a visual that sparks a memory and triggers another. Before you know it, I’m well on my way to a fusion of ideas without having to do too much thinking. It just flows. Everything we do is connected in a very cosmic (and occasionally “comic”) sense, so the invaluable inspiration gleaned from a photograph I took in New Orleans in 2003, could trigger ideas for a logo or visual metaphor completely unrelated to the original photographic resource.

I’ve read a great deal about sparking inspiration from simply changing your typical path. We are all creatures of habit, and once we lock into a routine, we are easily able to drown out everything around us. We shut down our minds and put our bodies on a kind of “auto-pilot” to get from the train to the office, or our house to the grocery store. However, if you consciously break a habit or routine and try a different route to your destination, you’ll be forced to experience new things and to pay closer attention to your surroundings.

dino-2

In 2005, I was keynoting an AIGA event in Jacksonville, Florida. Part of my daily ride to my destination involved passing an old, overrun Goony Golf mini-golf course. There was a spectacular and decrepit roadside dinosaur in front, clearly visible from the highway, that I simply had to photograph. During my keynote, I showed the audience the dinosaur in one of my slides, and only a few locals recognized it. After I mentioned that I took it not more than a mile away, they were a bit taken aback. This group of highly creative individuals had become so accustomed to passing the dinosaur in their daily routine that they no longer even saw this majestic beast deteriorating right in front of their eyes. Years later I learned that a few of the attendees had taken it upon themselves to save the roadside dinosaur from further deterioration by repairing him and moving him to a safer location.

They just needed to have their eyes opened to their own surroundings to be inspired. It was immensely gratifying to be part of this. It galvanized the lesson that inspiration can be found directly under our noses, and sometimes we just need to be nudged a little bit in one direction or another to actually see it.