Photograph by Jeremy Keith (adactio)

The mobile revolution has completely changed how people access the web. It’s only natural then that the web should evolve to better suit the plethora of devices on which it’s now accessed.

When the web was first created 25 years ago, it was the child of the “workstation” computer. Over those 25 years, we’ve seen the web proliferate to desktop PCs, laptops, mobile phones, tablets, and now even fashion accessories like watches. There’s no questioning that the web is here to stay. But what will the future look like?

In this blog post, I want to take you on a journey through some of the JavaScript device APIs that are extending the functionality of the web to better match the capabilities of modern devices.

Note: Some of the technologies you’ll learn about in this post are already implemented in browsers, but others are not. I’ve included examples of how to use each of the APIs, and done my best to provide up-to-date browser support information.

Geolocation

The Geolocation API allows you to pinpoint the user’s location using the positioning capabilities of their device. Most of the time this will be done using GPS, but less accurate methods, such as WiFi-based positioning, may also be used.

// Get the location.
    navigator.geolocation.getCurrentPosition(function(position) {
        // Get the positioning coordinates.
        var lat = position.coords.latitude;
        var lon = position.coords.longitude;
    
        // Do something interesting...
    });

W3C Specification Learn about the Geolocation API

Specification Status: W3C Recommendation

Browser Support For The Geolocation API

The geolocation specification has been around for quite a while now. All modern web browsers include support for the API (including on mobile).

Source: http://caniuse.com/#feat=geolocation

Device Orientation

The DeviceOrientation and DeviceMotion events provide a way to create applications that are aware of the physical positioning of a device. This is especially useful when building HTML5 games.

// Check to make sure the browser supprots DeviceOrientationEvents
    if (window.DeviceOrientationEvent) {
      // Create an event listener
      window.addEventListener('deviceorientation', function(event) {
          // Get the left-to-right tilt (in degrees).
        var tiltLR = event.gamma;
    
        // Get the front-to-back tilt (in degrees).
        var titleFB = event.beta;
    
          // Get the direction of the device (in degrees).
        var direction = event.alpha;
      });
    }

W3C Specification Learn about the Device Orientation API

Specification Status: Working Draft

Browser Support For The DeviceOrientation API

Browser support for the DeviceOrientation and DeviceMotion events is pretty good. Safari is the only desktop browser that doesn’t currently include support.

IE is the only mobile browser without support for the DeviceOrientation and DeviceMotion events.

Source: http://caniuse.com/#feat=deviceorientation

Media Capture and Streams

Almost everything seems to have a camera on it these days: phones, tablets, glasses, and more. With the Media Capture and Streams API you can get access to the device camera using JavaScript.

Coupled with the power of WebRTC, this enables some pretty cool applications like real-time video conferencing without the need for third-party plugins.

// Request the camera.
    navigator.getUserMedia(
        // Constraints
        {
            video: true
        },
        // Success Callback
        function(localMediaStream) {
              // Get a reference to the video element on the page.
            var vid = document.getElementById('camera-stream');
    
            // Create an object URL for the video stream and use this 
            // to set the video source.
            vid.src = window.URL.createObjectURL(localMediaStream);
        },
        // Error Callback
        function(err) {
            // Log the error to the console.
            console.log('The following error occurred when trying to use getUserMedia: ' + err);
        }
    );

W3C Specification Learn about the Media Capture

Specification Status: Working Draft

Browser Support For Media Capture

Browser support for the Media Capture and Streams API is growing. Firefox, Chrome, and Opera currently include support in their desktop browsers.

On mobile, the Media Capture and Streams API is supported in the Blackberry browser, Chrome for Android, Firefox for Android, and Opera Mobile.

Source: http://caniuse.com/#feat=stream

Vibration

The Vibration API allows developers to provide non-audible feedback to the user by harnessing the devices vibration motor.

// Vibrate for 1 second (1000 milliseconds).
    navigator.vibrate(1000);
    
    // Vibrate in sequence.
    navigator.vibrate([500, 250, 500]);

This API is useful when building HTML5 games, or for making applications accessible to users with hearing impairments.

W3C Specification Learn about the Vibration API

Specification Status: Last Call Working Draft

Browser Support for The Vibration API

The Vibration API is supported in Firefox, Chrome, and Opera on the desktop. (Although the device will, of course, need to have a vibration motor for this to work.)

On mobile, the Vibration API is supported in the Android and Blackberry browsers, as well as in Chrome and Firefox for Android, and Opera Mobile.

Source: http://caniuse.com/#feat=vibration

Ambient Light

The Ambient Light API allows developers to access the light sensor on the device.

With the increasing popularity of bright, minimalist designs, many developers have added a “night mode” to their apps to make them easier to use in dark surroundings. You could use the data from the Ambient Light API to automatically switch between “day” and “night” modes.

window.addEventListener('devicelight', function(event) {
        // Get the ambient light level in lux.
        var lightLevel = event.value;
    });

W3C Specification Learn about the Ambient Light API

Specification Status: Candidate Recommendation

Browser Support for The Ambient Light API

The Ambient Light API is currently only supported in Firefox 22+ on the Mac.

Only Firefox for Android includes support on mobile.

Source: https://developer.mozilla.org/en-US/docs/Web/API/DeviceLightEvent

Proximity Events

Many devices have proximity sensors that can feed back data about objects that are close to the device. Proximity events gives developers access to this data for use in their web applications.

There are two different types of proximity events, DeviceProximityEvent and UserProximityEvent. DeviceProximityEvent is the more accurate of the two, providing data about the distance an object is from the device as well as the sensors field of view. The UserProximityEvent only provides a boolean attribute (near) to indicate if an object is close to the device or not.

// An event listener for a DeviceProximityEvent.
    window.addEventListener('deviceproximity', function(event) {
        // The maximum distance the sensor covers (in cm).
        var max = event.max;
    
        // The minimum distance the sensor covers (in cm).
        var min = event.min;
    
        // The device proximity (in cm).
        var proximity = event.value;
    });
    
    // An event listener for a UserProximityEvent.
    window.addEventListener('userproximity', function(event) {
        if (event.near) {
            // Do something.
        } else {
            // Do something else.
        }
    });

W3C Specification Learn about Proximity Events

Specification Status: Candidate Recommendation

Browser Support for Proximity Events

Proximity events are currently only supported in Firefox (desktop) and Firefox for Android.

Source: https://developer.mozilla.org/en-US/docs/WebAPI/Proximity

Battery Status

The Battery Status API gives developers information about the device’s current power status. The BatteryManager object offers information about the current charge level, whether the device is charging, and how much time is left until the device runs out of juice and powers down.

// Get the current power level.
    navigator.battery.level;
    
    // Get the charging status (boolean).
    navigator.battery.charging;
    
    // Find out how long until the battery is charged.
    navigator.battery.chargingTime;
    
    // Find out how long until the battery is empty.
    navigator.battery.dischargingTime;

W3C Specification Learn about the Battery API

Browser Support for The Battery Status API

Currently the Battery Status API is only supported in Firefox (desktop) and Firefox for Android. Work is being done to add this functionality to blink, but there’s no indication of exactly when this will make it into Chrome or Opera.

Source: https://developer.mozilla.org/en-US/docs/WebAPI/Battery_Status

Other Specifications in the Works

So far in this post we’ve looked at a number of different APIs that help to further the capabilities of web applications. In addition to the APIs I’ve already mentioned, there are also a number of specifications that are being worked on for other exciting technologies. I’ve listed some of these below.

• ContactsManager
• Messaging
• Telephony
• WebNFC

It’s worth noting that these specifications are all classed as working drafts and therefore are very early in development and likely to change. There’s no guarantee that these technologies will ever make it into browsers, or even through the spec development process. Nevertheless, I think they’re worth mentioning purely as a look into what the future may hold.

Final Thoughts

In this blog post you’ve explored some of the JavaScript device APIs that are helping to further the capabilities of web applications. I’m incredibly excited about the direction the web is going. Browsers are invading device hardware and offering up the loot through new APIs — data that web developers have been eager to get their hands on for years.

The capabilities gap that has existed between native and web applications is closing fast, and that shows no signs of slowing down. The future looks ever brighter for web developers.

Useful Links

• W3C JavaScript APIs

The post Exploring the JavaScript Device APIs appeared first on Treehouse Blog.

Welcome back! If you missed the first part of our journey so far, then you might want to go back and catch-up first.

So far, we've applied a Test-Driven Development process to building our application, alongside utilizing the popular RSpec testing framework. From here, we're going to investigate some other RSpec features as well as look into using the Pry gem to help you debug and write your code.

Other RSpec Features

Let's take a moment to review some other RSpec features that we've not needed in this simple example application, but you may find useful working on your own project.

Pending Statement

Imagine you write a test but you're interrupted, or you need to leave for a meeting and haven't yet completed the code required to get the test to pass.

You could delete the test and re-write it later when you're able to come back to your work. Or alternatively you could just comment the code out, but that's pretty ugly and definitely no good when using a version control system.

The best thing to do in this situation is to define our test as 'pending' so whenever the tests are run, the test framework will ignore the test. To do this you need to use the pending keyword:

describe "some method" do
      it "should do something"
        pending
      end
    end
    

Set-Up and Tear-Down

All good testing frameworks allow you to execute code before and after each test is run. RSpec is no different.

It provides us before and after methods which allows us to set-up a specific state for our test to run, and to then clean up that state after the test has run (this is so the state doesn't leak and effect the outcome of subsequent tests).

describe "some method" do
      before(:each) do
        # some set-up code
      end
    
      after(:each) do
        # some tear-down code
      end
    
      it "should do something"
        pending
      end
    end
    

Context Blocks

We've already seen the describe block; but there is another block which is functionally equivalent called context. You can use it every where you would use describe.

The difference between them is subtle but important: context allows us to define a state for our test. Not explicitly though (we don't actually set the state by defining a context block - it instead is for readability purposes so the intent of the following code is clearer).

Here is an example:

describe "Some method" do
      context "block provided" do
        it "yields to block" do
          pending
        end
      end
    
      context "no block provided" do
        it "calls a fallback method" do
          pending
        end
      end
    end
    

Stubs

We can use the stub method to create a fake version of an existing object and to have it return a pre-determined value.

This is useful in preventing our tests from touching live service APIs, and guiding our tests by giving predictable results from certain calls.

Imagine we have a class called Person and that this class has a speak method. We want to test that method works how we expect it to. To do this we'll stub the speak method using the following code:

describe Person do
      it "speak()" do
        bob = stub()
        bob.stub(:speak).and_return('hello')
        Person.any_instance.stub(:initialize).and_return(bob)
        
        instance = Person.new
        expect(instance.speak).to eq('hello')
      end
    end
    

In this example, we say that 'any instance' of the Person class should have its initialize method stubbed so it returns the object bob.

You'll notice that bob is itself a stub which is set-up so that any time code tries to execute the speak method it will return "hello".

We then proceed to create a new Person instance and pass the call of instance.speak into RSpec's expect syntax.

We tell RSpec that we're expecting that call to result in the String "hello".

Consecutive Return Values

In the previous examples we've use the RSpec feature and_return to indicate what our stub should return when it's called.

We can indicate a different return value each time the stub is called by specifying multiple arguments to the and_return method:

obj = stub()
    obj.stub(:foo).and_return(1, 2, 3)
    
    expect(obj.foo()).to eq(1)
    expect(obj.foo()).to eq(2)
    expect(obj.foo()).to eq(3)
    

Mocks

Mocks are similar to Stubs in that we are creating fake versions of our objects but instead of returning a pre-defined value we're more specifically guiding the routes our objects must take for the test to be valid.

To do that we use the mock method:

describe Obj do
      it "testing()" do
        bob = mock()
        bob.should_receive(:testing).with('content')
    
        Obj.any_instance.stub(:initialize).and_return(bob)
    
        instance = Obj.new
        instance.testing('some value')
      end
    end
    

In the above example we create a new Object instance and then call its testing method.

Behind the scenes of that code we expect the testing method to be called with the value 'content'. If it isn't called with that value (which in the above example it's not) then we know that some piece of our code hasn't functioned properly.

Subject Block

The subject keyword can be used in a couple of different ways. All of which are designed to reduce code duplication.

You can use it implicitly (notice our it block doesn't reference subject at all):

describe Array do
      describe "with 3 items" do
        subject { [1,2,3] }
        it { should_not be_empty }
      end
    end
    

You can use it explicitly (notice our it block refers to subject directly):

describe MyClass do
      describe "initialization" do
        subject { MyClass }
        it "creates a new instance" do
          instance = subject.new
          expect(instance).to be_a(MyClass)
        end
      end
    end
    

Rather than constantly referencing a subject within your code and passing in different values for instantiation, for example:

describe "Foo" do
      context "A" do
        it "Bar" do
          baz = Baz.new('a')
          expect(baz.type).to eq('a')
        end
      end
    
      context "B" do
        it "Bar" do
          baz = Baz.new('b')
          expect(baz.type).to eq('b')
        end
      end
    
      context "C" do
        it "Bar" do
          baz = Baz.new('c')
          expect(baz.type).to eq('c')
        end
      end
    end
    

You can instead use subject along with let to reduce the duplication:

describe "Person" do
      subject { Person.new(name) } # Person has a get_name method
    
      context "Bob" do
        let(:name) { 'Bob' }
        its(:get_name) { should == 'Bob' }
      end
    
      context "Joe" do
        let(:name) { 'Joe' }
        its(:get_name) { should == 'Joe' }
      end
    
      context "Smith" do
        let(:name) { 'Smith' }
        its(:get_name) { should == 'Smith' }
      end
    end
    

There are many more features available to RSpec but we've looked at the most important ones that you'll find yourself using a lot when writing tests using RSpec.

Randomized Tests

You can configure RSpec to run your tests in a random order. This allows you to ensure that none of your tests have any reliance or dependency on the other tests around it.

RSpec.configure do |config|
      config.order = 'random'
    end
    

You can set this via the command using the --order flag/option. For example: rspec --order random.

When you use the --order random option RSpec will display the random number it used to seed the algorithm. You can use this 'seed' value again when you think you've discovered a dependency issue within your tests. Once you've fixed what you think is the issue you can pass the seed value into RSpec (e.g. if the seed was 1234 then execute --order random:1234) and it will use that same randomized seed to see if it can replicate the original dependency bug.

Global Configuration

You've seen we've added a project specific set of configuration objects within our Rakefile. But you can set configuration options globally by added them to a .rspec file within your home directory.

For example, inside .rspec:

--color --format nested
    

Debugging With Pry

Now we're ready to start looking into how we can debug our application and our test code using the Pry gem.

It's important to understand that although Pry is really good for debugging your code, it is actually meant as an improved Ruby REPL tool (to replace irb) and not strictly debugging purposes; so for example there are no built-in functions such as: step into, step over or step out etc that you would typically find in a tool designed for debugging.

But as a debugging tool, Pry is very focused and lean.

We'll come back to debugging in a moment, but let's first review how we'll be using Pry initially.

Updated Code Example

For the purpose of demonstrating Pry I'm going to add more code to my example application (this extra code doesn't effect our test in any way)

class RSpecGreeter
      attr_accessor :test
    
      @@class_property = "I'm a class property"
    
      def greet
        binding.pry
        @instance_property = "I'm an instance property"
        pubs
        privs
        "Hello RSpec!"
      end
    
      def pubs
        test_var = "I'm a test variable"
        test_var
      end
    
      private
    
      def privs
        puts "I'm private"
      end
    end
    

You'll notice we've added some extra methods, instance and class properties. We also make calls to two of the new methods we've added from within our greet method.

Lastly, you'll notice the use of binding.pry.

Setting Break-Points With binding.pry

A break-point is a place within your code where execution will stop.

You can have multiple break-points set within your code and you create them using binding.pry.

When you run your code you'll notice that the terminal will stop and place you inside your application's code at the exact spot your binding.pry was placed.

Below is an example of how it might look...

    8: def greet
    =>  9:   binding.pry
       10:   pubs
       11:   privs
       12:   "Hello RSpec!"
       13: end
    

From this point Pry has access to the local scope so you can use Pry much like you would in irb and start typing in for example variables to see what values they hold.

You can run the exit command to exit Pry and for your code to continue executing.

Finding Where You Are: whereami

When using lots of binding.pry break points it can be difficult to understand where in the application you are.

To get a better context of where you are at any point, you can use the whereami command.

When run on its own you'll see something similar to when you used binding.pry (you'll see the line on which the break-point was set and a couple of lines above and below that). The difference being is if you pass an extra numerical argument like whereami 5 you'll see five additional lines above where the binding.pry was placed. You could request to see 100 lines around the current break-point for example.

This command can help orientate you within the current file.

Stack Trace: wtf

The wtf command stands for "what the f***" and it provides a full stack trace for the most recent exception that has been thrown. It can help you understand the steps leading up to the error that occurred.

Inspecting: ls

The ls command displays what methods and properties are available to Pry.

When run it will show you something like...

RSpecGreeter#methods: greet  pubs  test  test=
    class variables: @@class_property
    locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_
    

In the above example we can see that we have four public methods (remember we updated our code to include some additional methods and then test and test= were created when using Ruby's attr_accessor short hand).

It also displays other class and local variables Pry can access.

Another useful thing you can do is to grep (search) the results for only what you're interested in. You'll need to have an understanding of Regular Expressions but it can be a handy technique. Here is an example...

ls -p -G ^p
    => RSpecGreeter#methods: privs
    

In the above example we're using the -p and -G options/flags which tell Pry we only want to see public and private methods and we use the regex ^p (which means match anything starting with p) as our search pattern to filter the results.

Running ls --help will also show you all available options.

Changing Scope: cd

You can change the current scope by using the cd command.

In our example if we run cd ../pubs it'll take us to the result of that method call.

If we now run whereami you'll see it will display Inside "I'm a test variable".

If we run self then you'll see we get "I'm a test variable" returned.

If we run self.class we'll see String returned.

You can move up the scope chain using cd .. or you can go back to the top level of the scope using cd /.

Note: we could add another binding.pry inside the pubs method and then our scope would be inside that method rather than the result of the method.

Seeing How Deep You Are: nesting

Consider the previous example of running cd pubs. If we run the nesting command we'll get a top level look on the number of contexts/levels Pry currently has:

Nesting status:
    --
    0. # (Pry top level)
    1. "I'm a test variable"
    

From there we can run exit to move back to the earlier context (for example, inside the greet method)

Running exit again will mean we're closing the last context Pry has and so Pry finishes and our code continues to run.

Locate Any Method: find-method

If you're not sure where to find a particular method then you can use the find-method command to show you all files within your code base that has a method that matches what you're searching for:

find-method priv
    => Kernel
       Kernel#private_methods
       Module
       Module#private_instance_methods
       Module#private_constant
       Module#private_method_defined?
       Module#private_class_method
       Module#private
       RSpecGreeter
       RSpecGreeter#privs
    

You can also use the -c option/flag to search the content of files instead:

find-method -c greet
    => RSpecGreeter
       RSpecGreeter: def greet
       RSpecGreeter#privs:   greet
    

Classic Debugging: next, step, continue

Although the above techniques are useful, it's not really 'debugging' in the same sense as what you're probably used to.

For most developers their editor or browser will provide them with a built-in debugging tool that lets them actually step through their code line by line and follow the route the code takes until completion.

As Pry is developed to be used as a REPL that's not to say it's not useful for debugging.

A naive solution would be to set multiple binding.pry statements through out a method and use ctrl-d to move through each break-point set. But that' still not quite good enough.

For step by step debugging you can load the gem pry-nav...

source "https://rubygems.org"
    
    gem 'rspec'
    
    group :development do
      gem 'guard'
      gem 'guard-rspec'
      gem 'pry'
    
      # Adds debugging steps to Pry
      # continue, step, next
      gem 'pry-remote'
      gem 'pry-nav'
    end
    

This gem extends Pry so it understands the following commands:

• Next (move to the next line)
• Step (move to the next line and if it's a method, then move into that method)
• Continue (Ignore any further break-points in this file)

Continuous Integration With Travis-CI

As an added bonus let's integrate our tests with the online CI (continuous integration) service Travis-CI.

The principle of CI is to commit/push early and often to avoid conflicts between your code and the master branch. When you do (in this case we're committing to GitHub) then that should kick off a 'build' on your CI server which runs the relevant tests to ensure all is working as it should be.

Now with TDD as your primary development methodology you're less likely to incur bugs every time you push because your tests are an integral part of your development workflow and so before you push you'll already be aware of bugs or regressions. But this doesn't necessarily protect you from bugs that occur from integration tests (where all code across multiple systems are run together to ensure the system 'as a whole' is functioning correctly).

Regardless, code should never be pushed directly to your live production server any way; it should always be pushed first to a CI server to help catch any potential bugs that arise from differences between your development environment and the production environment.

A lot of companies have more environments still for their code to pass through before it reaches the live production server.

For example, at BBC News we have:

• CI
• Test
• Stage
• Live

Although each environment should be identical in set-up, the purpose is to implement different types of testing to ensure as many bugs are caught and resolved before the code reaches 'live'.

Travis-CI

Travis CI is a hosted continuous integration service for the open source community. It is integrated with GitHub and offers first class support for multiple languages

What this means is that Travis-CI offers free CI services for open-source projects and also has a paid model for businesses and organizations who want to keep their CI integration private.

We'll be using the free open-source model on our example GitHub repository.

The process is this:

• Register an account with GitHub
• Sign into Travis-CI using your GitHub account
• Go to your "Accounts" page
• Turn "on" any repositories you want to run CI on
• Create a .travis.yml file within the root directory of your project and commit it to your GitHub repository

The final step is the most important (creating a .travis.yml file) as this determines the configuration settings for Travis-CI so it knows how to handle running the tests for your project.

Let's take a look at the .travis.yml file we're using for our example GitHub repository:

language: ruby
    cache: bundler
    
    rvm:
      - 2.0.0
      - 1.9.3
    
    script: 'bundle exec rake spec'
    
    bundler_args: --without development
    
    branches:
      only:
        - master
    
    notifications:
      email:
        - you@example.com
    

Let's break this down piece by piece...

First we specify what language we're using in our project. In this case we're using Ruby: language: ruby.

Because running Bundler can be a bit slow and we know that our dependencies aren't going to change that often we can choose to cache the dependencies, so we set cache: bundler.

Travis-CI uses RVM (Ruby Version Manager) for installing Rubies on their servers. So we need to specify what Ruby versions we want to run our tests against. In this instance we've chosen 2.0 and 1.9.3 which are two popular Ruby versions (technically our application uses Ruby 2 but it's good to know our code passes in other versions of Ruby as well):

rvm:
      - 2.0.0
      - 1.9.3
    

To run our tests we know that we can use the command rake or rake spec. Travis-CI by default runs the command rake but because of how Gems are installed on Travis-CI using Bundler we need to change the default command: script: 'bundle exec rake spec'. If we didn't do this then Travis-CI would have an issue locating the rspec/core/rake_task file which is specified within our Rakefile.

Note: if you have any issues regarding Travis-CI then you can join the #travis channel on IRC freenode to get help answering any questions you may have. That's where I discovered the solution to my issue with Travis-CI not being able to run my tests using its default rake command and the suggestion of overwriting the default with bundle exec rake resolved that issue.

Next, because we're only interested in running our tests we can pass additional arguments to Travis-CI to filter gems we don't want to bother installing. So for us we want to exclude installing the gems grouped as development: bundler_args: --without development (this means we are excluding gems that are only really used for development and debugging such as Pry and Guard).

It's important to note that originally I was loading Pry within our spec_helper.rb file. This caused a problem when running the code on Travis-CI, now that I was excluding 'development' gems. So I had to tweak the code like so:

require 'pry' if ENV['APP_ENV'] == 'debug'
    

You can see that now the Pry gem is only require'ed if an environment variable of APP_ENV is set to debug. This way we can avoid Travis-CI from throwing any errors. This does mean that when running your code locally you'd need to set the environment variable if you wanted to debug your code using Pry. The following shows how this could be done in one line:

APP_ENV=debug && ruby lib/example.rb

There were two other changes I made and that was to our Gemfile. One was to make it clearer what gems were required for testing and which were required for development, and the other was explicitly required by Travis-CI:

source "https://rubygems.org"
    
    group :test do
      gem 'rake'
      gem 'rspec'
    end
    
    group :development do
      gem 'guard'
      gem 'guard-rspec'
      gem 'pry'
    
      # Adds debugging steps to Pry
      # continue, step, next
      gem 'pry-remote'
      gem 'pry-nav'
    end
    

Looking at the above updated Gemfile we can see we've moved the RSpec gem into a new test group, so now it should be clearer what purpose each gem has. We've also added a new gem 'rake'. The Travis-CI documentation states this needed to be specified explicitly.

The next section is optional and it allows you to white list (or black list) certain branches on your repository. So by default Travis-CI will run tests against all your branches unless you tell it otherwise. In this example we're telling it we only want it to run against our master branch:

branches:
      only:
        - master
    

We could tell it to run every branch 'except' a particular branch, like so:

branches:
      except:
        - some_branch_I_dont_want_run
    

The final section tells Travis-CI where to send notifications to when a build fails or succeeds:

notifications:
      email:
        - you@example.com
    

You can specify multiple email addresses if you wish:

notifications:
      email:
        - you@example.com
        - them@example.com
        - others@example.com
    

You can be more specific and specify what you want to happen on either a failure or a success (for example, more people will only be interested if the tests fail rather than getting an email every time they pass):

notifications:
      email:
        recipients:
          - you@example.com
        on_failure: change
        on_success: never
    

The above example shows that the recipient will never receive an email if the tests pass but will get notified if the failure status changes (the default value for both is always which means you'll always be notified regardless of what the status result).

Note: when you explicitly specify a on_failure or on_success you need to move the email address(es) inside of recipients key.

Conclusion

This is the end of our two part look into RSpec, TDD and Pry.

In part one we managed to write our application using the TDD process and the RSpec testing framework. In this second half we've also utilized Pry to show how we can more easily debug a running Ruby application. Finally we were able to get our tests set-up to run as part of a continuous integration server using the popular Travis-CI service.

Hopefully this has given you enough of a taste so you are keen to investigate each of these techniques further.

Feature Engineering for Large Scale Predictive
Modeling with Electronic Health Records

Dr. Fei Wang
Healthcare Analytics Research group
IBM T. J. Watson Research Center

1:00pm Wednesday, 26 March 2014, ITE325b, UMBC

Predictive modeling lies in the heart of many medical informatics problems, such as early detection of some chronic diseases and patient hospitalization/readmission prediction. Typically those predictive models are built upon patient Electronic Health Records (EHR), which are systematic collection of patient information including demographics, diagnosis, medication, lab tests, etc. We refer those information as patient features. High quality features are of vital importance to building successful predictive models. In this talk, I will present two feature engineering technologies to improve the quality of the raw features extracted from original patient EHRs: (1) feature augmentation, which constructs more effective derived features from existing raw features by exploring the event sequentiality; (2) feature densification, which imputes the missing feature values via knowledge transfer across similar patients. Along with each technique we also developed a visual interface to facilitate the user exploring the derived features. Finally I will conclude the whole talk with some future research directions.

Dr. Fei Wang is currently a research staff member in Healthcare Analytics Research group, IBM T. J. Watson Research Center. Before his current position he was a postdoc in Department of Statistical Science, Cornell University. He received his Ph.D. from Department of Automation, Tsinghua University in 2008. Dr. Wang’s major research interests include data mining, machine learning as well as their applications in social and health informatics. He actively publishes papers on the top venues of the relevant fields including AMIA, KDD, ICML and InfoVis, and he has filed over 20 patents (four issued). Dr. Wang has given seven tutorials on different topics at ICDM/SDM/ICDM, organized seven workshops on KDD/ICDM/SDM/WSDM, and edited three special issues on Journal of Data Mining and Knowledge Discovery. His Ph.D. thesis was awarded the National Excellent Doctoral Thesis in China. His research paper was selected as the recipient of the Honorable mention of the best research paper award in ICDM 2010, and best research paper finalist in SDM 2011. More information can be found on his homepage.

Host: Prof. Kostas Kalpakis, Sorry, you need javascript to view this email address.

Feature Engineering for Large Scale Predictive
Modeling with Electronic Health Records

Dr. Fei Wang
Healthcare Analytics Research group
IBM T. J. Watson Research Center

1:00pm Wednesday, 26 March 2014, ITE325b, UMBC

Predictive modeling lies in the heart of many medical informatics problems, such as early detection of some chronic diseases and patient hospitalization/readmission prediction. Typically those predictive models are built upon patient Electronic Health Records (EHR), which are systematic collection of patient information including demographics, diagnosis, medication, lab tests, etc. We refer those information as patient features. High quality features are of vital importance to building successful predictive models. In this talk, I will present two feature engineering technologies to improve the quality of the raw features extracted from original patient EHRs: (1) feature augmentation, which constructs more effective derived features from existing raw features by exploring the event sequentiality; (2) feature densification, which imputes the missing feature values via knowledge transfer across similar patients. Along with each technique we also developed a visual interface to facilitate the user exploring the derived features. Finally I will conclude the whole talk with some future research directions.

Dr. Fei Wang is currently a research staff member in Healthcare Analytics Research group, IBM T. J. Watson Research Center. Before his current position he was a postdoc in Department of Statistical Science, Cornell University. He received his Ph.D. from Department of Automation, Tsinghua University in 2008. Dr. Wang’s major research interests include data mining, machine learning as well as their applications in social and health informatics. He actively publishes papers on the top venues of the relevant fields including AMIA, KDD, ICML and InfoVis, and he has filed over 20 patents (four issued). Dr. Wang has given seven tutorials on different topics at ICDM/SDM/ICDM, organized seven workshops on KDD/ICDM/SDM/WSDM, and edited three special issues on Journal of Data Mining and Knowledge Discovery. His Ph.D. thesis was awarded the National Excellent Doctoral Thesis in China. His research paper was selected as the recipient of the Honorable mention of the best research paper award in ICDM 2010, and best research paper finalist in SDM 2011. More information can be found on his homepage.

Host: Prof. Kostas Kalpakis, Sorry, you need javascript to view this email address.

Incorporating web forms into your website isn’t always the easiest thing to do; they often look very sales-driven, and don’t always flow well with your designs.

But we need forms because they are the ultimate way to capture important user-contributed data.

At Formstack (a web app that allows you to create online forms) it’s no surprise we love talking about web form optimization and best practices. Users are more likely to see and complete your forms if they are easy to use and displayed strategically in your designs.

Let’s explore a few strategic form-presentation techniques along with some examples.

Form Page

The most fundamental technique for displaying a web form is to have a dedicated web page for it. Examples of form pages are contact forms and sign-up forms.

People who come to form pages are generally ready to act, or are more likely to do so. For instance, when a user clicks on a sign-up button, they already have the intent to use the form they will encounter because they have a task they wish to complete (i.e., sign up for an account).

For long web forms (like online surveys or e-commerce checkout processes) it would be better to use a form page because they need more screen space. In addition, having a dedicated page will allow the user to focus at the task at hand without distraction.

To be user-friendly and more successful at capturing information, form pages should be as short as possible. When we encounter unnecessarily long forms, there’s a higher likelihood we’ll choose to abandon it because there’s too much time and effort required from us.

Form Page Example

An example of a form page is HealthTab’s sign-up page.

We can see in this example:

• The form is the most prominent component on the page.
• There are no distracting, non-essential elements in close proximity of the web form (e.g. photos, links, other calls-to-action, social media buttons, etc.).
• Text content is limited only to useful information that might help or encourage the user to complete the form. In this case, a promise of a reward: If you complete the form, you will be able to track your blood pressure and BMI.

On-Page Forms

This technique of displaying web forms is good for forms that need to be usable and available on multiple or all pages of a site. Examples of these forms are email newsletter sign-up forms and site search forms.

Unlike form pages where the user has explicitly decided to see the form, on-page forms are presented without the user’s permission. So we must make sure our on-page forms don’t drastically interrupt their experience.

Since we know our users will see on-page forms without prior knowledge about them, we should be extremely transparent when describing the form. Being transparent will help build trust and encourage people to use the form.

On-Page Form Example

We can see an on-page form example by looking at the bottom of Sacha Greif’s blog posts where he has an email newsletter sign-up form strategically placed on the right-hand sidebar.

As we can see from this example:

• It respects the user’s reading experience by being located off to the right and at the bottom of each blog post, away from the content — at this point of the page, the user has already gotten value from the site (reading a blog post for free) and thus more likely to be motivated to sign up.
• The form is very short, it only has one input field. We often see email sign-ups asking for our first name, last name and other information, but this form only asks for one thing: A person’s email address.
• The form explicitly tells users what to expect: A newsletter every Sunday, and we won’t get spammed by providing our email address.

Modal Window Forms

Modal windows are a way to display content on demand without requiring the user to leave the current page.

Modal windows walk a fine line between being useful and being annoying (like popup windows), so using this technique should be used with utmost care.

You can see many sites today automatically showing modal windows as soon as the page loads. While this method might guarantee that you get your message in the face of your visitor, it’s frustratingly invasive.

Allow your users to naturally find what they need through good, honest and thoughtful design.

Bad Modal Window Form

Under Armour, for example, immediately prompts new site visitors with a modal window that contains an email sign-up form.

But is this effective?

As a newcomer to the site, how willing are you to give away your email address to this sign-up form?

While this strategy might gain some traction for your email list, you need to prioritize UX.

Good Modal Window Form

Using modal window forms is a good technique if doing so can provide UX improvements.

For example, Spotify uses a modal window form to speed up their sign-up process.

Instead of the user clicking on their sign-up button and then being directed to a form page, a modal window pops up near-instantly, saving her a few seconds and making the transition to the sign-up web form much smoother.

In the Spotify example, we can see a good rule to follow when displaying modal window forms: Let the user request for the form, don’t force it onto them. This concept is called progressive disclosure.

Off-Canvas Forms

Off-canvas layouts have become increasingly popular in mobile UI design. And for good reason: When a designer is only working with about 2-3 inches of screen space, she doesn’t want to cram the screen with too much stuff.

By placing elements such as navigation menus, auxiliary text and web forms off the screen until the user needs them, we can enhance UX and take advantage of progressive disclosure.

In concept, it’s similar to modal window forms. Where they differ is in execution.

When to Use Off-Canvas Forms

Forms that are suitable for off-canvas placement are those that aren’t regularly used, but are nonetheless essential and critical when a situation calls for them.

One type of form that is well-served by off-canvas placement are search forms.

The common design pattern for search forms is to place them at the top of the layout.

In other words, people expect search forms at the top-right or top-left of the screen when they need to search the site. But these locations are prime real estate that can be used more optimally for more critical elements. Not everyone that visits a web page needs to perform a search, so placing a big search form wastes valuable space in a vast majority of situations.

A good solution that allows the designer to shrink the space a search form takes up is to put it off-canvas until the user asks to see it.

We can see this in Bellroy’s off-canvas navigation menu.

Placing not-always-crucial forms off-canvas allows us to free up screen real estate for more important elements.

When they become crucial — such as in the case when a user is having a hard time finding something specific on a site — that’s when we can show it to them.

Optimize Web Forms for People

Regardless of what design strategies you use to collect user information, make decisions based on your users’ needs.

In business, it’s important to maximize leads or signups. But it’s even more important to keep your users happy.

Where have you found success with form placement in your designs? What’s one of your biggest pet peeves when it comes to lead generation techniques in UX/UI design?

Related Content

• 10 Tips for Optimizing Web Form Submission Usability
• A Guide to the New HTML5 Form Input Types
• Lessons We Learned from Our Biggest UX and Design Mistakes
• Related categories: UI and Usability

About the Authors

Eva McKnight is the PR Specialist at Formstack. When Eva’s not bragging about the awesome ways to use Formstack, you can find her taking too many pictures of her cat or trying to avoid cooking. She loves connecting with other PR professionals and digital marketers. Connect with Eva on Twitter.

Lance Padgett is the SEO Specialist at Formstack where he manages search strategy and strategic outreach campaigns. He also does design and development work too. He loves building things, makes a mean loaf of bread and can talk sports with you all day. Connect with Lance on Twitter.

The post Optimal Techniques for Strategically Displaying Web Forms appeared first on Six Revisions.

With growing numbers of businesses taking their products and services to the web, offering greater reach and accessibility of their wares to their existing and potential clients, we as web designers need to be ready to deliver on their e-commerce web wants and needs. Across the Web we see numerous examples of both ends of this spectrum, e-commerce websites done extremely well and, unfortunately, some extremely poorly.

Here we’ll shine a light on what makes an e-commerce website really work. We discuss the basics that are required for success and highlight them with some sites that exemplify the points in focus. Overall, much of the weight of a successful e-commerce site falls under the UX umbrella, with functionality being key.

And while it is true that could be argued for every site on the Web, given the very nature of them, e-commerce sites’ success rely so heavily on usability and function, that any choice which would strain either of these aspects of the site should not ever be considered.

Searchability

Not only do you need at least one very prominant search box on the site, it also needs to work impecibly. Visitors are going to be searching for the items they wish to purchase from the site and if the search function is below par, and they have any kinds of issues whatsoever finding exactly what they’re looking for, it could cost users and potential buyers. In fact, chances are, with the high number of both local and national chains operating in the same markets the users will end up going to a competitor where they don’t have as many issues.

So be clear not only with how they can search the products and services on offer, but also be sure that you give them a trail of breadcrumbs that highlight where in the shop the item they were searching for hides. This way they can easily browse related items in the same category. It is all about giving them as much flexibility to access the store items as possible, while doing it subtly enough as to not overwhelm them. It is a fine balance to strike indeed.

Shopping cart

Like the search box, visitors not only need an easy and apparent way to get to their shopping cart from any page on the site, the cart itself needs to be highly user friendly and functional. Users have expectations that need to be looked after if they are expected to stick around and spend their money at any particular site, and the shopping cart is one area where dropping the ball on meeting those expectations can be unneccessarily costly.

Customers need to be able to easily delete items from their cart as well as change the quantities of items in there. Meeting these expectations is good, but exceeding them where you can is even better. Go above and beyond by offering an estimate on shipping based on the customer’s zip code and offering multiple shipping options when available. Make the entire check-out process completely intuitive, an absolute no-brainer, so as to remove any chance of customer confusion.

Product showcase

Naturally you want to showcase the product line in the most effective and attractive way possible. The photographs of the products is the last place any client needs to try and save some money, so you may need to convince them to hire the best photographer they can afford. Make sure the product images show them in their best light possible, and to do so, there needs to be a professional on the other end of the lens.

A gorgeous image with just the right light and composition versus a dark fuzzy photo will make the difference between a sale and a customer lost to a lack of professionalism on display. Almost as important as the way the products look is the way they are described on the site. Give as detailed a description as possible, covering everything the customers could possibly have a question about. Color choices, exact dimensions, weight, and so on.

Calls to action

Though they are often vital to the mission at hand, the prettiest pictures and best descriptions in the world won’t make a bit of difference if the customer can’t find the button to actually purchase the item. The various calls to action throughout will be the proverbial bread and butter of any ecommerce site. Make sure you highlight them effectively enough to find the users’ eye as they’re lead through the design and visually commands them to click.

Which also leads to the next point, be sure they all work properly. Again this is an area where lack of functionality can spell disaster for the site’s effectiveness and overall popularity. If the site is known to have issues with any of CTA’s, then what is the enticement for users to return in search of goods they possibly cannot access or procure. And it is always frustrating for a user when the design visually calls to them saying “Click Here”, and when they do, absolutely nothing occurs.

Security

If the potential customers are going to be giving their payment details through the site you want to make sure they feel as secure as possible in doing so. If there is anything on the site that gives them a less than comforting feeling, with regards to the security of the information required to complete their transactions, good luck getting this to be a successful ecommerce site. So site security has to be priority. Visably so.

Make sure the site have an up-to-date SSL certificate to start with. Also be sure that the site uses an approved and reputable payment gateway to offer users a sense of comfort when they begin handing over their payment information. And speaking of said info, it is good practice to never save credit card information being transmitted via the site. Not only that, but be sure to encrypt all communications with the credit card processor.

Contact information

Hopefully, if all the other advice is followed, the customers coming to the site will be able to easily find what they are looking for and make their purchase without impedence, but with so many factors influencing all user interactions with the site this is not always a guarantee. Should the users end up with a question they need an answer to, before they buy from the site, giving them a simple way to contact someone who can help is a must.

If someone cannot be on hand immediately to address the customer’s concerns, it becomes imperative to make sure and get back to them in as timely a manner as possible. Keeping them waiting around, is never any kind of solid plan. It can often backfire and cause them to seek out alternatives to your shop.

Create Typographic Images with Typo-Painter – only $5!

If you have good software skills and are still looking for a summer internship, check out the 2014 Google Summer of Code program. You can earn $5500 by coding for an open source software project this summer. You will probably work remotely, but in close collaboration with a mentor at one of over 100 participating organizations. To maximize your chances, explore the organizations and find one that needs your skills. Details here; apply by Friday, March 21.