    
|
|
|
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.
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
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:
assets FolderThe 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.
public FolderContains the files that are publicly available, such as pictures your site uses, the favicon, etc.
config FolderThis 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 adaptersapplication.js – general settings for the applicationassets.js – asset settings for CSS and JSbootstrap.js – code that will be ran before the app launcheslocales – folder containing translationspolicies.js – user rights management configurationroutes.js – the routes for the systemviews.js – view related settingsThe sails.js documentation contains detailed information on each of these folders.
views FolderThe 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.
api FolderThis folder is composed from a buch of sub-folders:
adapters folder contains the adapters used by the application tocontrollers folder contains the application controllersmodels folderpolicies folder are stored rules for application user accessservicesSo 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 are stored in the config/application.js file. The configurable options for the application are:
appName)port)environment)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.
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
}
}
Regarding views, the configurable options are the template engine to be used and if a layout should or not be used, for views.
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 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 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:
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 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="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<!-- 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.
These are defined in the /assets/templates and are loaded as we saw above.
We discussed how to configure routes in the Configuration chapter.
There are several conventions that Sails follows when routes are handled:
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.: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.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.
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.
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.
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).
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)
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.
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.
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:
(al, il)
© Jeremy Girard for Smashing Magazine, 2013.
]]>|
|
In our latest Treehouse Project, expert teacher Ben Jakuben takes the Ribbit app from Build a Self-Destructing iPhone App and implements a fresh new design that he worked on with a designer. In the project you’ll implement custom login and signup screens, customize a table view controller and the table cells, and implement pull to refresh.
By the end you’ll be ready to work with a design team (or your own concepts) to customize your own iPhone apps!
Implementing Designs for iPhone
The post Announcing Implementing Designs for iPhone appeared first on Treehouse Blog.
]]>|
|
|
|
Published: Tuesday, October 29, 2013
Updated: Wednesday, October 30, 2013 01:10
What started out as a class project for three UMBC students has become a real world business venture that has recently been purchased by Tecore Networks. Tecore Networks is a company that specializes in wireless technology, based in Hanover, Md. Check out the full Retriever Weekly article here.