Visual design and UI mock-ups are effective way for communicating various aspects of the application to end users. However, it falls short when it comes to capturing details of interactions and behaviors of the application. Often, our workflow transitions from visual design to final implementation, with a short phase of semi-clickable mock-ups. So, real interaction design does not start until the backend development is done and wired up to the front-end. In one of the recent project with fairly complex backend integrated with external system, we started getting good end-user feedback not until they stated seeing and experiencing the data flowing through the application. It was somewhat late in the game, it would have been greatly helpful for UX designers and developers if this feedback came at earlier stage.
Functional prototype could help bridge this gap and start the feedback loop earlier in the development cycle. In this post, I am exploring the techniques for creating a functional prototype using the AngularJS without real backend. I selected fitness activity tracking as an application to be prototyped. Sign-up, sign-in, log activity, view dashboard are the features selected for prototyping. You can see the final outcome in the screenshot below, you could play with the live version here. All the data is held in the page memory, so feel free to sign-up, log activity and switch between the users. You could also log in using the demo user with ‘x’ as email and password.
This prototype leverages Angular’s $httpBackend for mocking the HTTP calls, while allowing rest of the application to user the $resource as if the real backend is available. Not this approach only helps to hash out lots of details of the front-end implementation, but large part of the code would be reusable when the real backend becomes available. As your RESTful endpoints becomes available, you could simply remove the code which mocks those HTTP calls. Now, lets dive in to the implementation details.
Enter the $httpBackend and $http
These are the two of the many building blocks of the AngularJS framework. $httpBackend, as the name indicates, provides low-level backend/ service for interacting with the XMLHttpRequest. $httpBackend deals with the browser incompatibilities and nuances for enabling cross-origin requests using JSONP. $http is a layer on top of $httpBackend, providing easy to use API to interect with, so you almost never require to interact directly with the $httpBackend.
ngMock module includes service with the same name –
$httpBackend which has ability to mock the HTTP calls. In situations where you would like to mock the back-end behavior for backend-less development or testing, you need to use $httpBakend from
ngMock module. So, make sure to include the
angular-mocks.js on the page. This nice layered abstraction over the browser infrastructure for communicating with the backend opens up lots of possibilities.
Lets Mock the Backend
AngularJS provides a nice service –
$resource for easily interacting with the RESTful endpoints.
$resource provides higher level of abstraction over the
$http, so you don’t have to write the boiler plate code for performing standard CRUD operations. Under the hood,
$http uses the
$httpBackend which could be configured to respond to certain URL requests instead of making the actual HTTP call. Ability to intercept the calls to specific URLs and responding to it is the core concept of prototyping technique discussed here. Following code snippet shows a way to intercept GET calls to the URL ‘/api/101/activity’ and responding with an array containing one activity.
1 2 3
run block – when your application is bootstrapping, is the best place to configure all the necessary HTTP call mocking. You could either use hooks defined for specific HTTP methods(i.e.
whenPUT, etc.) or use a generic method
when(method, url, data, headers) for defining your backend. URLs could be defined as regular expressions, which could be really handy. Following code shows how the RegExp URL pattern is defined for intercepting the Activity creation calls. The user id part of the URL is extracted simply by doing the RegEx matching.
1 2 3 4 5 6 7 8
For some of the URLs, you might like to make a real HTTP call instead of mocking them. Such URLs needs to be explicitly flagged as
passThrough. If your application makes a request to the URL which is not mocked nor included for the
passThrough would result in to error. Following
passThrough rule allows to make real HTTP calls for all the view under
Repository for your data
Once you start intercepting the HTTP calls, next question would be – where to put the data.
Repository is such generic repository which provides methods like
find and so on. It maintains array for storing the objects, it automatically assigns the id for the new object being added. In this sample we need repository to store the registered users and activities for each user, the repositories are defined as shown below. After intercepting the call, appropriate method is called on the repository. Repository uses
Lo-Dash to work with the collections.
1 2 3 4 5