Bandura, a TechGuard Company, Partners with UNICOM Engineering to Develop New Product for Overseas Market  

UNICOM Engineering’s Manufacturing, Regulatory Certification and Global Logistics Enable Security Company to Accelerate International Rollout of New Appliance

Canton, MA – October 29, 2013 — UNICOM Engineering (formerly NEI), a leading provider of application platforms, deployment solutions and lifecycle support services for software technology developers and OEMs worldwide, today announced that it is providing global expansion and manufacturing services to Bandura, a TechGuard company that provides technologies and services to protect critical networks from cyber attack. UNICOM Engineering is working with Bandura to manufacture and certify a new generation of the company’s award-winning PoliWall® appliance for the international market.

Bandura’s PoliWall is a network security device that sits between firewalls and edge routers to stop threats at the network perimeter by blocking malicious traffic. The PoliWall rapidly determines the country of origin and IP reputation for all incoming packets using HIPPIE® (High-speed Internet Protocol Packet Inspection Engine) and DCEL™ (Dynamically Compiled Exception Lists) technology. Packets are filtered according to customer-defined policies and unique exceptions that are bound to resource groups for specific network addresses and protocols.  

Having already achieved success in the U.S. market, Bandura decided to expand internationally with a next-generation version of the PoliWall product.  This required a faster appliance with higher throughput, greater availability, and a smaller footprint. Given their past connection with UNICOM Engineering, Bandura knew that the company’s proven experience with appliance manufacturing and expertise in international regulation certification could help them achieve their goal. UNICOM Engineering delivered with a pre-integrated solution with global certifications, further accelerating time to market for the product.

“UNICOM Engineering had the platforms we needed to be able to support our new high-throughput product up to 20G per second,” said David Maestas, chief technology officer at Bandura.“The fact that the platforms were already pre-certified for export and for sale in the U.S. was a huge bonus for us.”

UNICOM Engineering provides a broad range of products backed by value-add services to deliver solutions to companies like Bandura. With a comprehensive approach to solution design and application deployment, UNICOM Engineering uses standard technologies to build appliances that meet specific application requirements,accelerate time to market, and reduce total cost of ownership. Throughout the design process, the company considers all aspects of the solution lifecycle, including component life, energy efficiency, and regulatory requirements, among other factors.

“We have partnered with very small companies and very large companies in the past, and feel like UNICOM Engineering offers the best of both worlds,” said Bandura CEO Suzanne Magee. “They are big enough that we know we are getting the support we need in the U.S. and global markets, and yet they’re small enough that we get personal attention. It feels like we really matter to UNICOM Engineering.”

About Bandura, LLC

Bandura® is a wholly owned subsidiary of TechGuard Security, founded in February 2000 in direct response to Presidential Decision Directive 63, provides trusted and innovative Critical Infrastructure Protection to the Department of Defense, Homeland Security, Federal agencies, and the US Critical Infrastructure. The TechGuardians® research, develop, and rapidly prototype, cutting-edge security technologies, including the patent and patent-pending PoliWall® with HIPPIE® and PCELs® technologies; and provide expert consulting services.  PoliWall is marketed under Bandura, LLC.

About UNICOM Engineering, Inc.

UNICOM Engineering is a leading provider of server-based application platforms and lifecycle support services for software developers and OEMs worldwide. Through its expertise and comprehensive suite of solution design, system integration, application management, global logistics, support and maintenance services, UNICOM Engineering is redefining application deployment solutions to provide customers with a sustainable competitive advantage. More than a decade of appliance innovation with the ability to provide physical, virtual, and cloud-ready solutions makes UNICOM Engineering one of the most trusted software deployment partners in the industry. Founded in 1997, UNICOM Engineering has facilities in Canton, Massachusetts, Plano, Texas, and Galway, Ireland. For more information, visit www.unicomengineering.com.

For additional information, contact:

Jill Colna or Laura Nelson
SVM Public Relations
401-490-9700
jill.colna@svmpr.com
laura.nelson@svmpr.com

The online development tool Github has been around for a few years now. It provides online Git repository hosting for projects written in any common programming language. Over time their online API has gone through a few changes with the most current release at version 3. I have lots of fun toying around with different APIs, and Github is no exception.

In this tutorial I want to demonstrate how we can build a remote Github webapp using jQuery and Ajax. You enter a username and using the API we pull out some information about the user and their profile stats. Since this requires a remote connection through Ajax you’ll need to host this on some type of web server, or a local server environment if you have one. I’ve also hosted a live demo that you can check out below.

Live Demo – Download Source Code

Getting Started

So far I’ve downloaded a local copy of jQuery and created another css directory for my stylesheet. The page design itself isn’t super important, but it does help to understand my whole process when building the webapp.

  <div id="w">
        <h1>Simple Github API Webapp</h1>
        <p>Enter a single Github username below and click the button to display profile info via JSON.</p>
        
        <input type="text" name="ghusername" id="ghusername" placeholder="Github username...">
        
        <a href="#" id="ghsubmitbtn">Pull User Data</a>
        
        <div id="ghapidata" class="clearfix"></div>
      </div>
    

This is all you will find in the HTML body since most of the code is appended using jQuery. #ghusername is the input field to hold the username and #ghsubmitbtn is the element we use for triggering the API call. Once the user clicks on this link we can pull out all the info we need and create one long string variable holding all the HTML. This gets applied into #ghapidata using the jQuery .html() method.

Since the majority of the content here is written in jQuery I’d like to focus solely on the scripting. But if you want to learn about my CSS styles check out the styles.css file along with my source code. All of the classes we use in jQuery have already been styled beforehand. The easiest method is to construct your interface using HTML and CSS with dummy data, and then go back to replace it with jQuery.

Different Ajax Calls

I wrote two separate ways of pulling JSON data from the server, but I want to clarify that either one can work fine. A newer solution $.getJSON() is a shorthand Ajax function where you know the response will be in JSON format. I also put together a different function which allows for a callback method using $.ajax().

  function requestJSON(url, callback) {
        $.ajax({
          url: url,
          complete: function(xhr) {
            callback.call(null, xhr.responseJSON);
          }
        });
      }
    

This block is found at the very bottom of the script, defined as a reusable function. It helps if you want to call different Ajax requests based on which button is pressed – that way you can pass in different variables for the request URL and callback method. There are reasons to use both of these methods but for newcomers I’d recommend using getJSON() to make problem solving a bit quicker.

Handling User Input

I’ve setup a click event listener tied onto the button which calls a new function whenever it gets clicked. My first line uses event.preventDefault() so the HREF value doesn’t get loaded into the address bar. I also put together a small loading GIF which appears while we are waiting on the Ajax request.

$(function(){
      $('#ghsubmitbtn').on('click', function(e){
        e.preventDefault();
        $('#ghapidata').html('<div id="loader"><img src="css/loader.gif" alt="loading..."></div>');
        
        var username = $('#ghusername').val();
        var requri   = 'https://api.github.com/users/'+username;
        var repouri  = 'https://api.github.com/users/'+username+'/repos';
        
        requestJSON(requri, function(json) {
    

Each variable is used to obtain information about the API request. Each URI is based on the username provided in the text field. It’s important that you recognize we are calling the function I wrote earlier requestJSON() and using the sample user URI to get profile info from Github.

Notice the second parameter writes in a callback function. We aren’t defining this callback elsewhere in the document, it gets initialized right away. So inside this new function we have access to the JSON data so that we can start organizing a return value. Keep this in mind as we go over the rest of the code.

Organizing API Data

Our simple JSON object is returned to a variable with the name json. First we need to check out the response and see how we are configuring the page output.

      if(json.message == "Not Found" || username == '') {
            $('#ghapidata').html("<h2>No User Info Found</h2>");
          }
          
          else {
            // else we have a user and we display their info
            var fullname   = json.name;
            var username   = json.login;
            var aviurl     = json.avatar_url;
            var profileurl = json.html_url;
            var location   = json.location;
            var followersnum = json.followers;
            var followingnum = json.following;
            var reposnum     = json.public_repos;
            
            if(fullname == undefined) { fullname = username; }
    

If the user does not exist we don’t get any JSON response, just a string “Not Found”. If that’s the case we end the script immediately by appending some basic HTML onto the page. Otherwise we do have a real user and we can start creating variables to hold their profile information. At the end I put together an if{} statement checking if the user has no set Full Name, then we just replace it with their account username instead.

        var outhtml = '<h2>'+fullname+' <span class="smallname">(@<a href="'+profileurl+'" target="_blank">'+username+'</a>)</span></h2>';
            outhtml = outhtml + '<div class="ghcontent"><div class="avi"><a href="'+profileurl+'" target="_blank"><img src="'+aviurl+'" width="80" height="80" alt="'+username+'"></a></div>';
            outhtml = outhtml + '<p>Followers: '+followersnum+' - Following: '+followingnum+'<br>Repos: '+reposnum+'</p></div>';
            outhtml = outhtml + '<div class="repolist clearfix">';
    

Now we follow-up by creating a single variable outhtml to hold all the HTML output. This is why you may find it easier to have already written the HTML so you know what will look good on the page. Once all the static information is written into HTML my last feature is to pull out a list of the user’s Github repos(including forks).

To do this we need another Ajax request. I’m going to use $.getJSON() and write another function to handle the HTML output onto the page.

        var repositories;
            $.getJSON(repouri, function(json){
              repositories = json;   
              outputPageContent();                
            });          
            
            function outputPageContent() {
              if(repositories.length == 0) { outhtml = outhtml + '<p>No repos!</p></div>'; }
              else {
                outhtml = outhtml + '<p><strong>Repos List:</strong></p> <ul>';
                $.each(repositories, function(index) {
                  outhtml = outhtml + '<li><a href="'+repositories[index].html_url+'" target="_blank">'+repositories[index].name + '</a></li>';
                });
                outhtml = outhtml + '</ul></div>'; 
              }
              $('#ghapidata').html(outhtml);
            } // end outputPageContent()
          } // end else statement
        }); // end requestJSON Ajax call
      }); // end click event handler
    

The repositories variable now contains a full JSON response of the user’s entire repo collection. The new function I wrote outputPageContent() will have access to this variable because it is defined at the same scope. First I check if the JSON response is empty because the user has no repositories, otherwise we output some HTML using a jQuery loop.

The simplest way is using .each() on the repositories JSON object. The callback function allows 2 parameters but we only need the index value. In basic English, this loop will append one more <li> element into the output HTML for each repo in the JSON object. I can open+close the unordered list by writing this code outside of the loop.

Finally the output function ends with $(‘#ghapidata’).html(outhtml) to render this whole HTML string right into the empty div element. This will automatically replace the small GIF loader I added before, and it’ll do the same thing if you enter a different username into the text field.

Live Demo – Download Source Code

Closing

Once you start learning the basics of API development the whole process becomes very educational. Pulling data from 3rd party services can offer many new ideas for widgets or content areas in your layout. I do hope that my example can provide a way for developers to understand the process of using an online API. Also feel free to download a sample copy of my source codes and see what else you can learn.

The post Code a Simple Github API Webapp using jQuery & Ajax appeared first on Treehouse Blog.

The online development tool Github has been around for a few years now. It provides online Git repository hosting for projects written in any common programming language. Over time their online API has gone through a few changes with the most current release at version 3. I have lots of fun toying around with different APIs, and Github is no exception.

In this tutorial I want to demonstrate how we can build a remote Github webapp using jQuery and Ajax. You enter a username and using the API we pull out some information about the user and their profile stats. Since this requires a remote connection through Ajax you’ll need to host this on some type of web server, or a local server environment if you have one. I’ve also hosted a live demo that you can check out below.

Live Demo – Download Source Code

Getting Started

So far I’ve downloaded a local copy of jQuery and created another css directory for my stylesheet. The page design itself isn’t super important, but it does help to understand my whole process when building the webapp.

  <div id="w">
        <h1>Simple Github API Webapp</h1>
        <p>Enter a single Github username below and click the button to display profile info via JSON.</p>
        
        <input type="text" name="ghusername" id="ghusername" placeholder="Github username...">
        
        <a href="#" id="ghsubmitbtn">Pull User Data</a>
        
        <div id="ghapidata" class="clearfix"></div>
      </div>
    

This is all you will find in the HTML body since most of the code is appended using jQuery. #ghusername is the input field to hold the username and #ghsubmitbtn is the element we use for triggering the API call. Once the user clicks on this link we can pull out all the info we need and create one long string variable holding all the HTML. This gets applied into #ghapidata using the jQuery .html() method.

Since the majority of the content here is written in jQuery I’d like to focus solely on the scripting. But if you want to learn about my CSS styles check out the styles.css file along with my source code. All of the classes we use in jQuery have already been styled beforehand. The easiest method is to construct your interface using HTML and CSS with dummy data, and then go back to replace it with jQuery.

Different Ajax Calls

I wrote two separate ways of pulling JSON data from the server, but I want to clarify that either one can work fine. A newer solution $.getJSON() is a shorthand Ajax function where you know the response will be in JSON format. I also put together a different function which allows for a callback method using $.ajax().

  function requestJSON(url, callback) {
        $.ajax({
          url: url,
          complete: function(xhr) {
            callback.call(null, xhr.responseJSON);
          }
        });
      }
    

This block is found at the very bottom of the script, defined as a reusable function. It helps if you want to call different Ajax requests based on which button is pressed – that way you can pass in different variables for the request URL and callback method. There are reasons to use both of these methods but for newcomers I’d recommend using getJSON() to make problem solving a bit quicker.

Handling User Input

I’ve setup a click event listener tied onto the button which calls a new function whenever it gets clicked. My first line uses event.preventDefault() so the HREF value doesn’t get loaded into the address bar. I also put together a small loading GIF which appears while we are waiting on the Ajax request.

$(function(){
      $('#ghsubmitbtn').on('click', function(e){
        e.preventDefault();
        $('#ghapidata').html('<div id="loader"><img src="css/loader.gif" alt="loading..."></div>');
        
        var username = $('#ghusername').val();
        var requri   = 'https://api.github.com/users/'+username;
        var repouri  = 'https://api.github.com/users/'+username+'/repos';
        
        requestJSON(requri, function(json) {
    

Each variable is used to obtain information about the API request. Each URI is based on the username provided in the text field. It’s important that you recognize we are calling the function I wrote earlier requestJSON() and using the sample user URI to get profile info from Github.

Notice the second parameter writes in a callback function. We aren’t defining this callback elsewhere in the document, it gets initialized right away. So inside this new function we have access to the JSON data so that we can start organizing a return value. Keep this in mind as we go over the rest of the code.

Organizing API Data

Our simple JSON object is returned to a variable with the name json. First we need to check out the response and see how we are configuring the page output.

      if(json.message == "Not Found" || username == '') {
            $('#ghapidata').html("<h2>No User Info Found</h2>");
          }
          
          else {
            // else we have a user and we display their info
            var fullname   = json.name;
            var username   = json.login;
            var aviurl     = json.avatar_url;
            var profileurl = json.html_url;
            var location   = json.location;
            var followersnum = json.followers;
            var followingnum = json.following;
            var reposnum     = json.public_repos;
            
            if(fullname == undefined) { fullname = username; }
    

If the user does not exist we don’t get any JSON response, just a string “Not Found”. If that’s the case we end the script immediately by appending some basic HTML onto the page. Otherwise we do have a real user and we can start creating variables to hold their profile information. At the end I put together an if{} statement checking if the user has no set Full Name, then we just replace it with their account username instead.

        var outhtml = '<h2>'+fullname+' <span class="smallname">(@<a href="'+profileurl+'" target="_blank">'+username+'</a>)</span></h2>';
            outhtml = outhtml + '<div class="ghcontent"><div class="avi"><a href="'+profileurl+'" target="_blank"><img src="'+aviurl+'" width="80" height="80" alt="'+username+'"></a></div>';
            outhtml = outhtml + '<p>Followers: '+followersnum+' - Following: '+followingnum+'<br>Repos: '+reposnum+'</p></div>';
            outhtml = outhtml + '<div class="repolist clearfix">';
    

Now we follow-up by creating a single variable outhtml to hold all the HTML output. This is why you may find it easier to have already written the HTML so you know what will look good on the page. Once all the static information is written into HTML my last feature is to pull out a list of the user’s Github repos(including forks).

To do this we need another Ajax request. I’m going to use $.getJSON() and write another function to handle the HTML output onto the page.

        var repositories;
            $.getJSON(repouri, function(json){
              repositories = json;   
              outputPageContent();                
            });          
            
            function outputPageContent() {
              if(repositories.length == 0) { outhtml = outhtml + '<p>No repos!</p></div>'; }
              else {
                outhtml = outhtml + '<p><strong>Repos List:</strong></p> <ul>';
                $.each(repositories, function(index) {
                  outhtml = outhtml + '<li><a href="'+repositories[index].html_url+'" target="_blank">'+repositories[index].name + '</a></li>';
                });
                outhtml = outhtml + '</ul></div>'; 
              }
              $('#ghapidata').html(outhtml);
            } // end outputPageContent()
          } // end else statement
        }); // end requestJSON Ajax call
      }); // end click event handler
    

The repositories variable now contains a full JSON response of the user’s entire repo collection. The new function I wrote outputPageContent() will have access to this variable because it is defined at the same scope. First I check if the JSON response is empty because the user has no repositories, otherwise we output some HTML using a jQuery loop.

The simplest way is using .each() on the repositories JSON object. The callback function allows 2 parameters but we only need the index value. In basic English, this loop will append one more <li> element into the output HTML for each repo in the JSON object. I can open+close the unordered list by writing this code outside of the loop.

Finally the output function ends with $(‘#ghapidata’).html(outhtml) to render this whole HTML string right into the empty div element. This will automatically replace the small GIF loader I added before, and it’ll do the same thing if you enter a different username into the text field.

Live Demo – Download Source Code

Closing

Once you start learning the basics of API development the whole process becomes very educational. Pulling data from 3rd party services can offer many new ideas for widgets or content areas in your layout. I do hope that my example can provide a way for developers to understand the process of using an online API. Also feel free to download a sample copy of my source codes and see what else you can learn.

The post Code a Simple Github API Webapp using jQuery & Ajax appeared first on Treehouse Blog.

Computer Science and Electrical Engineering
University of Maryland, Baltimore County

Acoustic-Tactile Rendering of Visual
Information for the Visually Impaired

Thrasyvoulos N. Pappas

Electrical Engineering and Computer Science
Northwestern University

2:30pm Monday, 11 November 2013, ITE 325B, UMBC

After a brief overview of research in the Department of Electrical Engineering and Computer Science at Northwestern University, we will focus on one particular research problem, the use of hearing and touch for conveying graphical and pictorial information to visually impaired (VI) people. This problem combines visual, acoustic, and tactile signal analysis with and understanding of human perception and interface design. The main idea is that the user actively explores a two-dimensional layout consisting of one or more objects with the finger on a touch screen. The objects are displayed via sounds and raised-dot tactile patterns. The finger acts as a pointing device and provides kinesthetic feedback. The touch screen is partitioned into regions, each representing an element of a visual scene or graphical display. A key element of our research is the use of spatial sound to facilitate active exploration of the layout. We use the head-related transfer function (HRTF) for rendering sound directionality and variations of sound intensity and tempo for rendering proximity. Our research has addressed object shape and size perception, as well as the of a 2-D layout of simple objects with identical size and shape. We have also considered the rendering of a simple scene layout consisting of objects in a linear arrangement, each with a distinct tapping sound, which we compare to a “virtual cane.” Subjective experiments with visually-blocked subjects demonstrate the effectiveness of the proposed approaches. Our research findings are also expected to have an impact in other applications where vision cannot be used, e.g., for GPS navigation while driving, fire-fighter operations in thick smoke, and military missions conducted under the cover of darkness.

Thrasos Pappas received the Ph.D. degree in electrical engineering and computer science from MIT in 1987. From 1987 until 1999, he was a Member of the Technical Staff at Bell Laboratories, Murray Hill, NJ. He joined the EECS Department at Northwestern in 1999. His research interests are in human perception and electronic media, and in particular, image and video quality and compression, image and video analysis, content-based retrieval, model-based halftoning, and tactile and multimodal interfaces. Prof. Pappas is a Fellow of the IEEE and SPIE. He has served as editor-in-chief of the IEEE Transactions on Image Processing (2010-12), elected member of the Board of Governors of the Signal Processing Society of IEEE (2004-07), chair of the IEEE Image and Multidimensional Signal Processing Technical Committee (2002-03), and technical program co-chair of ICIP-01 and ICIP-09. Since 1997 he has been co-chair of the SPIE/IS&T Conference on Human Vision and Electronic Imaging.

Host: Janet C. Rutledge, Ph.D.

PhD Defense

Visualizing Sequential Patterns in Large

Datasets Using Levels of Abstraction

Dana Wortman

11am – 2pm, Friday, 1 November 2013, ITE 325b

Student retention and success are important topics in all academic fields and institutions. Faculty seek to understand which topics, theories, or skills defeat students or require strengthening to promote success. Programs seek to understand how to better sequence courses to ensure students are prepared for requisite future courses. Institutions seek to understand how to intervene to promote retention and improve graduation rates. Unfortunately, most statistics gathered by Institutional Research efforts are limited to failure rates, enrollment rates, and graduation rates and do not often explore individual student performance. While these are often further analyzed by various student demographic attributes such as race and gender, these statistical methods alone are insufficient to understand student performance over time and sequential patterns of enrollment or success and failure. This research presents a method using multiple levels of abstraction to visualize performance patterns over time.

To visualize student enrollment and performance patterns, several issues must be addressed including sequential versus concurrent enrollment, spatial layout of course events, and performance over time. Another challenge addressed by this work is that of presenting sequences within the context of the entire program. To address these issues, multiple abstractions are combined in a multi-layered visualization that presents a high-level overview of students enrollment and performance patterns while retaining detailed information regarding individual student progress and performance as they advance through their courses.

The aggregated view represents the lowest level of abstraction, student enrollment and performance are aggregated into a graph structure, presenting patterns of movement throughout the program at the individual course level. The clustered view represents mined sequential patterns of enrollment and performance, illustrating common sequences. The directed view represents the highest level of abstraction and uses two visual elements, heat maps and a vector field, to illustrate overall performance in individual events and movement through the program. Results from multiple cohorts can then be superimposed on the same visualization to enable easy comparisons between patterns. Together, these abstractions provide a focus+context view of student performance, retaining outliers and emphasizing common patterns to illuminate dominant and unique patterns between cohorts of students.

This approach can help educators better understand student progress through the program, performance in individual courses, or student-selected course sequencing and this information can be used to address deficiencies in preparation, skills, or prerequisites. To demonstrate the appropriateness of this approach, performance and enrollment patterns are explored in the Computer Science program at the University of Maryland, Baltimore County. Specifically, this work examines the Gateway policy that requires students to earn a B or higher in the first two required programming courses before progressing with the hopes of validating the existing Gateway but also exploring other possible Gateway courses. Other issues explored within the Computer Science program include race, gender, math placement, and high school scores with the goal of attracting and retaining a more diverse group of students.

Committee: Penny Rheingans (chair), Marie desJardins, Marc Olano, Tim Finin and Diane Lee

Sails is a Javascript framework designed to resemble the MVC architecture from frameworks like Ruby on Rails. It makes the process of building Node.js apps easier, especially APIs, single page apps and realtime features, like chat.

Installation

To install Sails, it is quite simple. The prerequisites are to have Node.js installed and also npm, which comes with Node. Then one must issue the following command in the terminal:

sudo npm install sails -g

Create a New Project

In order to create a new Sails project, the following command is used:

sails new myNewProject

Sails will generate a new folder named myNewProject and add all the necessary files to have a basic application built. To see what was generated, just get into the myNewProject folder and run the Sails server by issuing the following command in the terminal:

sails lift

Sails’s default port is 1337, so if you visit http://localhost:1337 you should get the Sails default index.html page.

Now, let's have a look at what Sails generated for us. In our myNewProject folder the following files and sub-folders were created:

The assets Folder

The assets folder contains subdirectories for the Javascript and CSS files that should be loaded during runtime. This is the best place to store auxiliary libraries used by your application.

The public Folder

Contains the files that are publicly available, such as pictures your site uses, the favicon, etc.

The config Folder

This is one of the important folders. Sails is designed to be flexible. It assumes some standard conventions, but it also allows the developer to change the way Sails configures the created app to fit the project’s needs. The following is a list of configuration files present in the config folder:

• adapters.js – used to configure the database adapters
• application.js – general settings for the application
• assets.js – asset settings for CSS and JS
• bootstrap.js – code that will be ran before the app launches
• locales – folder containing translations
• policies.js – user rights management configuration
• routes.js – the routes for the system
• views.js – view related settings

The sails.js documentation contains detailed information on each of these folders.

The views Folder

The application's views are stored in this folder. Looking at its contents, we notice that the views are generated by default as EJS (embedded JavaScript). Also, the views folder contains views for error handling (404 and 500) and also the layout file (layout.ejs) and the views for the home controller, which were generated by Sails.

The api Folder

This folder is composed from a buch of sub-folders:

• the adapters folder contains the adapters used by the application to
  handle database connections
• the controllers folder contains the application controllers
• the application's models are stored in the models folder
• in the policies folder are stored rules for application user access
• the api services implemented by the app are stored in the services
  folder

Configure the Application

So far we have created our application and took a look at what was generated by default, now it's time to configure the application to make it fit our needs.

General Settings

General settings are stored in the config/application.js file. The configurable options for the application are:

• application name (appName)
• the port on which the app will listen (port)
• the application environment; can be either development or production (environment)
• the level for the logger, usable to control the size of the log file (log)

Note that by setting the app environment to production, makes Sails bundle and minify the CSS and JS, which can make it harder to debug.

Routes

Application routes are defined in the config/routes.js file. As you’d expect, this file will be the one that you will most often work with as you add new controllers to the application.

The routes are exported as follows, in the configuration file:

module.exports.routes = {
      // route to index page of the home controller
      '/': {
        controller: 'home'
      },
    
      // route to the auth controller, login action
      '/login': {
        controller: 'auth',
        action: 'login'
      },
    
      // route to blog controller, add action to add a post to a blog
      // note that we use also the HTTP method/verb before the path
      'post /blog/add': {
        controller: 'blog',
        action: 'add_post'
      },
    
      // route to get the first blog post. The find action will return
      // the database row containing the desired information
      '/blog/:item': {
        controller: blog,
        action: find
      }
    }

Views

Regarding views, the configurable options are the template engine to be used and if a layout should or not be used, for views.

Models

Models are a representation of the application data stored in a database. Models are defined by using attributes and associations. For instance, the definition of a Person model might look like this:

// Person.js
    var Person = {
      name: 'STRING',
      age: 'INTEGER',
      birthDate: 'DATE',
      phoneNumber: 'STRING',
      emailAddress: 'STRING'
    };
    exports = Person;

The communication with the underlying database is done through adapters. Adapters are defined in api/adapters and are configured in the adapters.js file. At the moment of writing this article, Sails comes with three adapters: memory, disk and mysql but you can write your own adapter (see the documentation for details).

Once you have a model defined you can operate on it by creating records, finding records, updating and destroying records.

Controllers

Controllers are placed in api/controllers. A controller is created using the following command:

sails generate controller comment

This command will generate a CommentController object. Actions are defined inside this object. Actions can also be generated when you issue the generate controller command:

sails generate controller comment create destroy tag like

This will create a Comment controller with actions for create, destroy, tag and like.

Actions receive as parameters the request and the response objects, which can be used for getting parameters of the URI (the request object) or output in the view (using the response object).

To communicate with the model, the callback of the appopriate action is used. For instance, in the case of querying a database with find, the following pattern is used to manipulate the model:

Blog.find(id).done(err, blog) {
      // blog is the database record with the specified id
      console.log(blog.content);
    }

Views

Views are used to handle the UI of the application. By default, views are handled using EJS, but any other templating library can be used. How to configure views was discussed previously in the Configuration chapter.

Views are defined in the /views directory and the templates are defined in the /assests/templates folder.

There are mainly four types of views:

• server-side views
• view partials
• layout views
• client-side views

Server-Side Views

Their job is to display data when a view is requested by the client. Usually the method res.view corresponds to a client with the appropriate view. But if no controller or action exists for a request, Sails will serve the view in the following fashion: /views/:controller/:action.ejs.

The Layout View

The Layout can be found in /views/layout.ejs. It is used to load the application assets such as stylesheets or JavaScript libraries.

Have a look at the specified file:

<!DOCTYPE html>
    <html>
      <head>
        <title><%- title %></title>
    
        <!-- Viewport mobile tag for sensible mobile support -->
        <meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1, maximum-scale=1&quot;>
    
        <!-- JavaScript and stylesheets from your public folder are included here -->
        <%- assets.css() %>
        <%- assets.js() %>
      </head>
    
      <body>
        <%- body %>
    
        <!-- Templates from your view path are included here -->
        <%- assets.templateLibrary() %>
      </body>
    </html>

The lines assets.css() and assets.js() load the CSS and JS assets of our application and the assets.templateLibrary loads the client templates.

Client-Side Templates

These are defined in the /assets/templates and are loaded as we saw above.

Routes

We discussed how to configure routes in the Configuration chapter.

There are several conventions that Sails follows when routes are handled:

• if the URL is not specified in the config/routes.js the default route for a URL is /:controller/:action/:id with the obvious meanings for controller and action and id being the request parameter derived from the URL.
• if :action is not specified, Sails will redirect to the appropriate action. Out of the box, the same RESTful route conventions are used as in Backbone.
• if the requested controller/action do not exist, Sails will behave as so:
• if a view exists, Sails will render that view
• if a view does not exist, but a model exists, Sails will return the JSON form of that model
• if none of the above exist, Sails will respond with a 404

Conclusion

Now I’ve barely scratched the surface with what Sails can do, but stay tuned, as I will follow this up with an in-depth presentation showing you how to build an application, using Sails.

Also keep in mind that Sails is currently under development and constantly changing. So make sure to check out the documentation to see what's new.

Designing and developing websites that work well on mobile devices is an important aspect of the work we do on today’s Web. This importance is reflected in the conversations I have with clients, almost all of whom list “support for mobile devices” as one of their top goals for a redesign — all except one, that is.

Late last year, I began a redesign project for a company that sells pressure-treated lumber products. Early on in our conversation, I turned to the topic of support for mobile devices and responsive Web design. Normally, this topic is met with enthusiasm, but not this time, as the client explained:

Our customers don’t use mobile phones to come to our website.

This isn’t the first time I’ve heard this comment from a potential client. I’ve had many conversations in which the company severely underestimates the number of people who access their website on a phone or other mobile device. Typically, a look at the analytics will open their eyes to the true impact that mobile is having on their website’s traffic. But when I looked at the analytics for this particular client, I was the one left in shock.

Two percent. That was how much of its traffic was coming from mobile devices at the time. That’s it!

Jumping ahead to the end of this story, I did end up working with this client to redesign their website, and that website is now fully responsive. The path we took to that point, however, provides an interesting glimpse into how we as designers can go about selling responsive websites, and when we should push for a solution that we know to be an important best practice and yet whose need is not immediately obvious.

Determine Whether They Actually Need A Mobile Web Experience

The title of this article, “Selling Responsive Web Design To Clients,” might sound like a shady salesperson attempting to convince a customer to purchase something they don’t need. That is not what I am advocating for at all. So, let me start by stating that the first step in this process should be to determine whether the client actually needs a given solution at all.

Make sure that the solution you are selling fits the client you are pitching it to. (Image: echerries)

When considering a responsive design for a website that doesn’t currently support mobile devices, begin by looking at the big picture. Do the traffic figures show that the client is attracting mobile users? If the mobile traffic figures are similar to those of this client of mine, then maybe they don’t actually need a mobile Web experience at this time — especially if the website has no other issues.

If a website is currently working well for the organization — meaning that it is converting visitors, features an attractive design, and has a high-quality user experience (for desktop visitors at least), while drawing an incredibly low percentage of mobile users — then redesigning or rebuilding that website only to make it responsive wouldn’t make financial sense.

You could argue that even a small percentage of visitors getting a poor experience is unacceptable and could be resolved by developing a responsive design. The designer in me can appreciate that argument, but I also understand the business side of the situation. Undertaking a responsive redesign to accommodate just 2% of the audience will be a very tough sell, no matter what company you are speaking with. This is why you need to look beyond just the traffic figures and think about more than just the design-related benefits of responsiveness.

Try To Solve Other Problems They Are Having

While support for mobile devices was not a compelling enough reason for our client to redesign their website, other concerns brought them to us in the first place. Two of these concerns were the visual design of their website, which was outdated and did not reflect their current marketing, and the lack of a content management system (CMS) or any tools to enable them to update the website on their own. So, I focused my proposal on solving these problems.

A redesign would bring the look and feel of the website in line with the rest of the client’s marketing, while also improving the overall aesthetics and usability of the website itself. We would bring the website up to current standards and integrate it into a CMS (in this case, ExpressionEngine) — which would solve the second problem of being able to update the website.

As I discussed with the client this proposal and the process we would follow, I mentioned that we would make the website responsive as we rebuilt it. As expected, the client questioned whether this was necessary or added cost to the project — which, of course, it would have. The key here is that I was now able to steer the conversation towards the benefits of responsive design above and beyond the support for mobile devices.

Focus On More Than Just Phones

When we talk about responsive design, we often focus on phones. This makes sense because smartphones are most unlike the type of devices that we’ve designed for in the past — that is, desktop screens. Creating one website to be marketed and managed and to deliver a high-quality experience to all devices, from desktops to smartphones, is an excellent way to demonstrate the flexibility and power of responsive design. But for this client, phone users were seemingly not a factor. Luckily, responsive design is about so much more than phones.

The devices and screens we design for today are a variety of sizes. (Image: Edwin Torres)

In speaking with the client, I discovered that a complaint they often receive from customers is that the website appears “small.” The reason is that it had been designed to a fixed width many years ago — so long ago, in fact, that it was built for an 800 × 600-pixel resolution. When a user on what is now a typically large desktop screen visited the website, they saw a very narrow column, with a lot of unused space on either side. Yet, the company still had a number of other visitors on old desktops and laptops with low resolutions. So, merely making the website bigger wasn’t the right solution. The company needed a website that would work well both on large screens and on old small screens. This was a problem that could absolutely be solved by a responsive design.

Instead of focusing on phones and small screens, I explained to the client that a responsive design would enable us to effectively present a layout for today’s large desktop screens and also reflow to accommodate laptops and old desktop monitors that don’t have a high resolution.

As we demonstrated a responsive website for the client using a large desktop screen and a much smaller laptop, they got excited and told us that they had hated the “smallness” of the website for years, but their previous designer explained to them that, to support visitors with old computers, they had no choice but to design for this “lowest common denominator.”

Responsive design would solve this problem, and by this point our client was pretty much on board because they saw that it solved a problem they had (the “smallness” of the website), without addressing a problem that they didn’t think needed to be solved (support for mobile devices).

Build For The Future, Not Only The Present

When I discuss responsive Web design with my clients, I rarely use the term “mobile support” because it makes those clients think only of phones or, perhaps, tablets. I instead prefer the phrase “multi-device support,” which better encompasses the wide range of devices and screen sizes we are really designing and developing for these days.

One of the advantages of responsive design is that it doesn’t focus merely on the devices and screen sizes out there today. Because a responsive website reflows to fit a screen of any size, with an experience and a layout suited to each, the approach is very future-friendly. The prospect of having a website that continues to work well into the future, even as new devices and screen sizes come to market, appealed to our client. We further explained that, even if the website didn’t draw a lot of mobile visitors today, it might in the future. A responsive approach would ensure that those mobile visitors get an experience optimized for them.

The client remained skeptical that they would ever attract mobile visitors, but they were sold on responsive design because of the other problems it would solve. Additionally, because we were rebuilding the website anyway, making it responsive at the same time made financial sense. Trying to strap responsiveness onto an existing non-responsive website can be daunting and expensive, whereas incorporating responsiveness early on in the design process is much easier, especially if it is a core part of your process and you’ve developed a workflow for it, which we have. That workflow helped us to make this approach both technically and financially viable for our client.

Moving forward with the project, we knew that we would have to keep an eye on traffic once the website went live to prove our theory about the lack of mobile traffic.

Looking to the future will help us to build websites that work well even as new devices and screen sizes come to market. (Image: Joe Penniston)

Break The Cycle

Two percent of traffic from mobile devices is so low a figure that, when I first saw it, I questioned its accuracy.

This particular company does not market or sell to the general public. It is a B2B company that works with a relatively small group of distributors and contractors from a defined geographic area. The client attributed the low mobile traffic to this demographic, which would access the website from an office desk, not on the road with a phone.

I agreed that mobile figures would likely be lower for this demographic than for a typical audience (for the websites we manage, 30% of traffic comes from mobile visitors, although some websites get over 50%) — but not this low. I felt that something else was happening here, and my gut told me that part of the reason was that the website worked so poorly on mobile devices. I suspected that the lack of a mobile experience kept mobile visitors away.

I did not share this theory with the client at the time, but in the year since the new design went live, the mobile traffic figures have climbed, from 2 to 17%. Granted, that is still lower than what many other websites get these days, but it is a sizeable jump and cannot be ignored.

The only reason we can point to for this jump is the website’s responsiveness. Neither the demographic nor the market has changed. The only difference is in how the website works on mobile devices. The improved experience has increased traffic. This was one of the reasons why I pushed for responsiveness, even when the traffic figures suggested otherwise.

Solving Problems

Part of our job as Web professionals is to solve problems for our clients. But we have to solve not only the problems that the client tells us about, but the ones that they do not even know they have.

Our clients’ problems are opportunities for us to provide high-quality solutions based on our experience and expertise. (Image: Donna Grayson)

With the redesign of the website, our team was able to solve a number of problems that the client brought to our attention, including the outdated design and the absence of a CMS. And our solution to the problem that they weren’t aware of — a lack of mobile visitors due to a lack of support — validated our responsive approach, even when the traffic figures did not show the need for it. We knew that a responsive design would fix the layout on large desktop screens as well as on small old monitors, but would also help turn around the website’s unusually low traffic from mobile visitors, and we were proven correct.

We knew that part of the rise from 2 to 17% could be attributed to existing customers who had been sticking to a desktop computer out of obligation but were now switching to a mobile device. Those users are now able to access the website’s content on their preferred device, confident that they will get an experience suited to the device.

Another reason for the increased mobile traffic is undoubtedly new business. The movie Field of Dreams is instructive here: “If you build it, they will come.” If a website does not support mobile devices, then a mobile visitor will likely leave immediately upon noticing it, never to return. This was part of the reason for the low numbers. But the website no longer turns mobile users away, and the users in turn will not leave as soon as they arrive. Rather, they will find the information they are looking for and might visit again or point other people in their organization to the content. Mobile support encourages mobile use.

By addressing the customers’ problems, including ones that the client was not aware of, we were able to sell a responsive approach. The improved experience has boosted the mobile audience, as well as boosted the leads that the company is getting from the website.

In Summary

Selling a responsive design is no different than selling anything else. It all starts with solving problems.

For this project, we highlighted the benefits of a responsive approach beyond the familiar benefit of support for mobile devices that we normally mention to prospective clients. Here are some of the key points we made in discussing the value of a responsive approach for a website without an obvious need for mobile support:

• We would be supporting a variety of screen sizes that aren’t typically considered when discussing responsive design, including large new desktop monitors with very high resolutions and old small screens with correspondingly low resolutions.
• The website would scale into the future as new devices and screen sizes come to market and as mobile users begin to visit.
• We would save time, money and technical complexity by doing this work now, as part of the redesign process, rather than trying to cram it in later when the website is set.

(al, il)

© Jeremy Girard for Smashing Magazine, 2013.