Sunday, February 15, 2015

From the Notebook: An Ember Bootstrap Modal Dialog and How to Deal with state in Ember controllers

Bootstrap Modal Dialog for Ember

To create a Bootstrap styled modal dialog for an Ember app at work, I mostly followed the Ember cookbook entry on modal dialogs. One difference is using Bootstrap for the modal dialog, of course. Here are the steps I took.

  1. Added a modal outlet to the application template

    {{outlet modal}}
  2. On my ApplicationRoute.js I have the following:

    actions: {
        openModal: function(modalName, model) {
            return this.render(modalName, {
                into: 'application',
                outlet: 'modal',
                model: model
        closeModal: function() {
            return this.disconnectOutlet({
                outlet: 'modal',
                parentView: 'application'

    This allows me to pass a model to the modal. One implication of this is that the modal view needs to have a corresponding Controller so that Ember can set the model on that Controller. It appears that by default Ember Routes will supply an ArrayController or ObjectController for routes that don't have one defined, but the same doesn't hold for these non-route views.

  3. I then defined a modal-dialog component, but also split out modal-body and modal-footer components since those are the ones I'm expecting to customize from modal dialog to modal dialog.

    <script type="text/x-handlebars" data-template-name="components/modal-dialog">
        <div class="modal fade" tabindex="-1" role="dialog" aria-labelledby="dialogTitle" aria-hidden="true">
            <div class="modal-dialog">
            <div class="modal-content">
                <div class="modal-header">
                    <button type="button" class="close" data-dismiss="modal"
                        aria-label="Close"> <span
                    <h4 class="modal-title" id="dialogTitle">{{title}}</h4>
    <script type="text/x-handlebars" data-template-name="components/modal-body">
        <div class="modal-body">
    <script type="text/x-handlebars" data-template-name="components/modal-footer">
        <div class="modal-footer">
  4. For the component code I need to call .modal() on the modal dialog to pop it up. I also wanted to handle the Bootstrap modal closed event and then remove the modal from the DOM (i.e., disconnect the outlet). Removing the modal from the DOM is not strictly necessary I guess, but I think it is nice to remove it from the DOM when it is no longer needed. If it is rendering a model, there's no point for the hidden modal to re-render when that model changes.

    App.ModalDialogComponent = Ember.Component.extend({
        sendCloseAction: function(){
        didInsertElement: function() {
            this.$('.modal').on('', this.sendCloseAction.bind(this));
        willDestroyElement: function() {
  5. To use it, just need to create a view that uses the modal-dialog component.

    <script type="text/x-handlebars" data-template-name="myModal">
        {{#modal-dialog close="closeModal" title=title}}
                <button type="button" class="btn btn-default" {{action 'save'}}>Save</button>
                <button type="button" class="btn btn-primary" data-dismiss="modal">Close</button>

    One problem I ran into was that Components can only send actions based on names that they are given. My ModalDialogComponent can't call this.sendAction('closeModal') and have that be handled by the ApplicationRoute. Instead ModalDialogComponent calls this.sendAction('close') where the actual named action to send is specified in the view using the component. Here in the myModal template I'm specifying that for close the component should send the closeModal action. See Sending Actions from Components to Your Application for more details.

Ember Controllers Are Singletons

One surprising thing about Ember for me as I've been learning over the past couple months is that Controllers are (kind of, sort of) singletons. Ember instantiates a controller for a route once. So any state in a Controller is sticky. But often times you'll want to reset the state in your Controller when switching from one model to another. So what to do?

Found a couple of interesting blogs regarding this problem:

Both suggest resetting the controller in Route's setupController as one way to address this problem. (Note: Ember.Route also has a resetController hook; haven't used it but seems to cover exactly this need.) Balint Erdi's post has an interesting idea about having the reset logic in the Controller itself and having it observe some property that can be used to trigger a reset.

When thinking about Controller state and Routes, and where to put this state, it occurs to me that there are 3 kinds of view state. A view might want to take advantage of all 3 types of view state.

  1. Transient view state

    This is view state that you don't want to be sticky at all. Maybe expanding/collapsing an accordion type view, or form validation error display.

    Basically, if the model changes, you want to reset this the transient state. For this you can define a resetState function that is called whenever the model changes.

    resetState: function(){
        // reset transient stuff here
  2. Sticky state, but not serialized to the URL

    This would be view state that you want to be sticky so that when the user moves from view to view this state remains. However, for whatever reason, you don't want to serialize this state to a Route URL. This is the default way that Ember works.

    Can't actually think of a good example here. Maybe a sub-view that you expand or show and as you move through different models you want to keep showing that sub-view?

  3. Sticky state that should be serialized to the URL

    If you have some view state that you want to be persistent, then you should really think about moving that to the Route and serializing to the URL. If that works for your use case, then you can do that and move that view state out of the Controller entirely.

To me, #1 is a more common type of view state than #2, so it seems weird that the default for Ember Controllers is #2. However, the fact that Ember Controllers are singletons makes #2 possible and then one just needs to reset state to make #1 work. If Ember Controllers weren't singletons, its hard to see where #2 style view state would be stored.

Odds and Ends

  • Console2: a better Windows console. I played around with setting up Console2 to get a better console window than cmd.exe. The following were helpful resources

    Here's what I like about Console2:

    • You can configure it to copy on select and paste with a right click.
    • You can resize the window (but you have to configure it to have more columns first, which is kind of weird). I sometimes like to have the console take up a full screen.
    • It is tabbed.
    • You can configure it to start a cmd shell or Git bash. I have Git bash as a default and hitting Ctrl+Shift+T opens a new Git bash tab.
  • Ember dot notation. Learned that in Ember instead of doing


    You can do


    If bar is not defined, then the first one would fail but the second would return undefined.

  • Git: counting words in a specific revision of a file. I wanted to be able to count how many words are in a previous version of a blog post. There might be a better way to do this, but here's how I did it.

    1. Get the file's blob hash. You can do

      git log --raw -- path/to/file

      Seems the easiest way. This prints the before and after blob hash for each revision

      :100644 100644 c5d00fe... 2403611... M  path/to/file

      Where 2403611 is the blob hash for this revision and c5d00fe is the blob hash for the previous revision.

    2. cat the blob and count the words. Getting the blob hash was the hard part, now we can simply do

      git cat-file -p 2403611 | wc -w

Sunday, February 08, 2015

Responsive Webapp Conclusions

I've spent a few weeks now reading and thinking about whether it makes sense to use responsive web design techniques to build a single page web application (SPA) that works well on mobile and desktop computers. I started with my initial thoughts and reviewed arguments for responsive webapps and against responsive webapps. I haven't done as much reading as I would like and there is still a lot of good stuff out there to read and learn from. But I think I have learned enough to come to some conclusions.


The first step in deciding whether to go responsive or not with a single page web application is to first design the ideal mobile UI and the ideal desktop UI for your app. Obviously phones and desktop computers have different real estate to work with, but when you are designing an ideal UI for your app think also about the different use cases that users on mobile versus desktop computers will have. Don't just think "how do I make this work on small and large screens". For example, consider an email campaign management app. On desktop the UI would likely be optimized for creating new email messages or templates and bulk loading and editing of email lists. On a mobile device the UI would be more geared to checking the status of email campaigns: open rates, bounceback rates, unsubscribes. Design a UI that makes the most sense for your users on both platforms.

Now, if the UI is basically the same except for layout, then Responsive Web Design techniques could be a good fit. You can use media queries to adapt the layout of the app on different devices.

However, you might still not choose to go responsive. Why?

  1. You might want to optimize what is downloaded on mobile devices. Not only to achieve a smaller download size but also to exclude running JavaScript code that would be a performance burden on mobile devices.
  2. You want the flexibility to diverge the UIs in the future. Sure, today, maybe before you even have any users, you think that the ideal mobile and desktop UIs only differ in layout. But apps should evolve based on feedback from users and as they grow new capabilities. (This point might actually be the nail in the coffin for me regarding responsive SPAs. It seems far more pragmatic to start by having separate mobile and desktop UIs.)
Other recommendations
Only two device classes: phone and desktop (or small and large)

There used to be such a clear cut divide between phones and tablets, but any more I don't see much point in developing separate UIs for them. They share a lot of the same considerations:

  • modest computational resources
  • on mobile networks
  • access to sensors like GPS

I think it is sufficient to just have two device classes.

One thing that does seem reasonable is to use responsive web design techniques to have your mobile UI adapt to larger screen area. For example, you could implement the kind of UI like in the iPad Mail app where in portrait you see only the email message but in landscape you see a list of emails in that folder on the left and the email message on the right.

Also, allow the user to switch between the phone and desktop UIs if they desire. A theme running throughout these blog posts is to try to not make any hard assumptions and this is, to me, one of the big advantages of the device class approach. You might think that the user will best be served by the mobile UI but that user may want the desktop UI. (This also dovetails nicely with thinking about different use cases on mobile and desktop: the user may be on a desktop computer but want to use the mobile UI because it is optimized for the kind of task the user currently has in mind.)

Make everything optimized for touch

Whether you go responsive or take the device classes approach, make everything optimized for touch. Size controls so that they can be tapped on and respond to touch events.

An alternative to responsive webapps: Device Classes

This week I spent some time with Boris Smus' article, A non-responsive approach to building cross-device webapps. As the title suggests, Boris presents an alternative to using media queries and responsive design for building webapps that work on a range of devices. It's a good article and I recommend reading it. In this blog post I'll review his arguments and give my thoughts on the matter.

To start with, Boris sees a few problems with Media Queries (or at least, with using just media queries to adapt layout for different screen sizes):

  • All devices get the same assets: the same JavaScript, CSS, images etc. So there is a good chance that devices are downloading a lot more than they would absolutely need to.
  • All devices start with the same DOM. To get the DOM to look one way on one device and look another way on a different device could lead to overly complicated CSS.
  • Not much flexibility to customize the UI for different types of devices. You can do it with a media query approach but if you have a mobile view that is just completely different from a desktop view, you will have duplicate views and the application code has to be careful to handle both views at once, depending on screen size. That is, while creating a custom view for a certain type of device, you have to think about how it will work for all other types of devices.

Smus recommends developing separate UIs for three different device classes:

  1. mobile phones (small screen width + touch)
  2. tablets (large screen width + touch)
  3. desktops (no touch)

He suggests using device width and whether the device is touch enabled to distinguish between these device classes. How reasonable are these criteria?

As one of the commenters mentions, hindsight is 20/20. We live in an era of touchscreen desktop Windows 8 computers, and they don't appear to be going anywhere. We can no longer assume that lack of touch support equals desktop or vice versa. One of my big takeaways from this whole investigation is that all controls should be designed to be touch friendly.

What about the small screen/large screen divide? As I wrote in my previous post, we now have many large phones and small tablets such that the height of a large phone can easily exceed the width of a tablet. I still think a line can be drawn somewhere and I do think that it is useful to design a mobile friendly version of a webapp. But that line is continually moving and blurring.

Okay, now that we have 3 device classes (personally I only see two: mobile and desktop), what does Smus recommend for detecting and serving up these different experiences? Smus compares doing server side and client side detection and comes down on client side detection, mostly because it is feature detection based (more future proof) instead of user agent based. I agree there.

Smus suggests using Device.js (apparently one of his open source projects) to do this client side detection.

He also suggests using a MVC framework and only making separate View classes for the difference device classes. This allows you to get a lot of reuse while also being able to fully tailor the UI for a particular device class.

Overall, I'm impressed with this approach. If your application is best implemented with a different UI on mobile versus desktop, I think this is probably the best approach. Responsive Web Design seems to be a good fit only when the UI is basically the same on mobile and desktop with only the layout needing to be a little different. For example, at Walker Information, we have a survey application. On mobile and on desktop, the essential UI is the same, with only layout differing. Each page has a list of questions and controls for providing answers, with Back and Next buttons to navigate through the survey. This is a good candidate for being designed responsively. As a counter example, consider something like a webapp for MailChimp. On desktop it might be optimized for creating emails and setting up campaigns whereas on mobile the UI might be quite different and be focused on monitoring open rates, bounceback rates, etc. In this case, having two completely different apps would be a better fit.

There are some downsides with this separate app for device classes approach:

  • If the device class is part of the URL then bookmarks, shared links would include it as part of the URL. It would be nice to have canonical URLs.
  • Separate views for the device classes is extra work and has its own maintenance overhead
  • Doesn't respond to orientation changes or browser resizing
    • However, it would be possible to combine both approaches. You might create a separate view for the mobile device class that itself uses media queries to adjust the UI between phone-like sizes and tablet-like sizes.

On a closing note, there is one other thing I like about Smus' approach. He recommends having links in the app to the different device classes. This way if you are on a mobile phone and really want the desktop view, you can get to it. I think this is in line with the thinking from the last blog post that challenges the consensual hallucination that we as web developers tend to participate in. Our assumption about what is mobile, what is a desktop computer are being challenged all the time. It would be good to make fewer assumptions. Letting a user switch to a non-default device class, to me, fits in with that line of thinking. We only have a limited understanding of the kinds of devices that exist today. Hopefully the devices that arrive in the future will surprise us and challenge our assumptions. And hopefully our webapps will be ready.

Additional Resources:

  • Really liked this post by Brad Frost that Smus links to. He makes the point that while media queries are great, the most important thing to optimize on mobile is performance.

Sunday, January 18, 2015

Researching Responsive Webapps

In a previous post I wrote about my initial thoughts regarding responsive Single Page Applications (SPAs). I've now done a bit of digging to find out what other folks think about this topic.

Among the blog posts I read I found Jason Grigsby's series of blog posts Responsive Design for Apps especially interesting.

Consensual Hallucination

In the first blog post in this series, Jason makes the case that web developers and web UI framework authors have been participating in a consensual hallucination regarding what phones and tablets and desktop computers are limited to, just as we once assumed desktop browsers were 960 pixels wide. Web UI frameworks tend to have a library of mobile widgets (e.g, jQuery Mobile) and a separate library of desktop widgets (e.g. jQuery UI). The reasoning given by framework authors is that phones and tablets and desktops are fundamentally different platforms. But what are these fundamental differences? A cellular radio? The answer isn't clear and Jason is dubious that a good answer exists.

Jason looks at the size of phones and tablets and points out that the height of the larger phones out there easily exceeds the width of the smaller tablets available. His article was published in early 2013 and since then the gap has only narrowed. In fact Jason at one point says

The small gaps that exist are either things that seem inevitable (high-dpi on large screens) or are so small to be inconsequential (does it matter that we don't have six inch displays?).

And of course, we now have 6-inch phones and 6-inch tablets.

There's no clear line between phones and tablets, but what about desktops? We used to be able to assume that touch was a fundamentally distinct mode of interaction on mobile devices. However, Windows 8 and all of the touch screen desktop and laptop products that are built for it obliterates that assumption. He points to research to suggest that touchscreen desktops are not a fad. I've yet to have a chance to play with a Windows 8 touchscreen device myself but I agree. I have to believe that eventually Apple will have to catch up too.

One of the key takeaways for me from this article is that every application should be designed for touch interaction. Primarily this means making targets big enough to be easily tapped on with fingers. Because of Fitts's Law, desktop users using a mouse will also benefit because these larger targets are easier to hit.

Making desktop app responsive

In Jason's second post he looks at a typical desktop app and tries to reimagine it as a responsive web app.

One of the problems he ran into is that if you take a desktop app design and try to make it responsive, you kind of run into a brick wall. He starts making progress when he takes a mobile first strategy. He designs a version of the web app that is optimized for mobile.

Once he has an optimized mobile design, he then looks at how it maps to the desktop app and finds that it maps pretty well. That's important for a responsive web app; each screen in the mobile design needs to be able to map to a corresponding screen in the desktop design. If there isn't a mapping, that is, if the mobile design is not just a different layout compared to the desktop design, then responsive web design probably won't work.

Finally, he takes another look at the desktop design and rethinks it in terms of the mobile design. This is also an important step in evaluating if responsive web design is feasible. For the mobile design he had to compromise in some places and display less information than on the desktop design. So its important to step back and look at if these mobile design components can be used in the desktop design.

Desktop and mobile design patterns

In the third part of the Jason's series Jason looks at how desktop operating systems have been incorporating mobile design ideas. In particular he looks at Apple's Mail app on iPhone, iPad and Mac OS X.

The iPhone Mail app uses a nested doll design pattern: moving froma list of items to greater detail or sub-lists of that item. On the iPad, we see a slightly different pattern, what has been called the bento box pattern: the list of email messages is displayed on the same screen as the detail. The iPhone and iPad app actually share views (for example, mail accounts and folders listing screens).

On Mac OS X, the Mail app there shares a lot of similar design elements although it does have a different look. One could definitely imagine there being a single Mail app that runs across all Apple devices and that adapts to the available screen real estate.

To me it is a little bit of stacking the deck to use the Mail app. Because information in the Mail app is arranged hierarchically (mail accounts list, folders list, messages list), it is not too hard to design a responsive Mail app. But not all apps are so simple. Word processing apps tend to have a main content area and several controls for affecting layout and formatting. A mobile word processing app design would be quite a different design, not likely to share much with its desktop counterpart.

Also, Jason only looks at views that display lists of accounts and emails and the views that display the email itself. That is, he only considers the views related to reading email. The desktop Mail app includes formatting options and stationary options when composing email, which would take up too much real estate on mobile. This is because on mobile users are typically more interested in reading and filing and flagging and deleting email. On mobile users only need to be able to write short responses, typically. On desktop the email composing needs are very different.

Nevertheless, I think his conclusion that

responsiveness for apps is inevitable

is mostly true. Responsive web design can be a good fit for some apps and even apps that are better served by different UI designs on mobile and desktop will benefit from responsive design techniques on mobile (for example a mobile UI that responds to more real estate on a tablet versus a phone).


I find Jason's arguments compelling. The idea that phones are fundamentally different from tablets and desktops and so require different UI frameworks and separate apps is undermined by the evidence that not much actually separates these different devices in terms of technical capability.

However, one thing that I think is missing a little from the discussion is how these different devices are used and what they are used for. Yes, technically, there isn't much difference between phones and tablets and desktops except screen size. On the other hand, users on mobile devices may have different tasks in mind that they want to accomplish versus users on desktop devices. As I mentioned above regarding the Mail app example, mobile users mostly want to read and deal with email by flagging, filing, deleting etc. Composing longer or more format heavy emails are saved for when the user is at a desktop computer. Now, this isn't a big difference in goals for mobile and desktop users for this particular app, but for certain apps mobile users may have very different goals from desktop users. This needs to be kept in mind when designing optimal desktop and mobile UIs. I'll expand on this a bit in future posts, but to me this is one of the most important reasons why you might want separate mobile and desktop apps.

Saturday, December 20, 2014

Initial thoughts on Responsive Single Page Applications

Is it feasible to build a responsive, mobile-first Single Page Application (SPA)? Here are my initial thoughts on the feasibility and challenges of building a responsive SPA. I plan to do more research in the coming weeks to hopefully answer this question more completely.

I was recently working on a mobile version of FuelMyRoute. I started by using jQuery Mobile and Backbone, but I found trying to use jQuery Mobile as a UI framework frustrating so I decided to give the Bootstrap CSS framework a try. I was able to convert my code over to Bootstrap fairly easily, but I started reading about and thinking about the responsive features of Bootstrap. This got me to thinking maybe I could make a responsive Single Page Application, one website that would work well on mobile devices and on desktop computers.

The benefits are pretty obvious I think. I don't relish the idea of maintaining two separate web applications. Especially when a lot of the non-UI code would be very similar. I could get a mobile site for my application while at the same time updating and modernizing the existing desktop site. That's a huge win!

I should probably define what I mean by responsive SPA. First of all, a Single Page Application is a web application where there is only an initial full page load. From that point forward AJAX is used to interact with the server to fetch data (e.g. get new mail) or to perform server side actions (e.g. send an email). The DOM is manipulated as appropriate in response to user actions and requested information. A responsive SPA is one where the UI of the SPA changes based on the size of the viewport, so that it is more appropriate/usable on smaller viewports but also can adapt and take advantage of more screen space on larger viewports. Responsive to me means also taking a mobile-first approach to web application development, where the mobile phone/small tablet use case is given primary (or at least equal) consideration.

But, I don't really see or hear much about responsive SPAs. I'm talking strictly about web applications, not web sites. If you are building, for example, a blog, then there is a lot of advice and support for making it responsive. However, for applications, it's different. The received wisdom is that it is better to have two different sites, one for mobile and one for desktop. Why? This is a question I want to answer along with the following:

  • What are the problems/tradeoffs that are encountered when making a responsive SPA?
  • Is it possible to use only CSS, only media queries to switch between different layouts for mobile and desktop usage? Or would it be necessary to have the JavaScript code be aware of whether the application is in mobile or desktop mode? (Ideally the responsiveness would be implemented in CSS only)

In this blog post I cover my initial thoughts about how a responsive SPA could work and what the challenges are likely to be.

Responsive Mobile UI Patterns

How would this work in practice? In this section I'll go over a couple of common mobile UI patterns and how they would adapt to a larger viewport.

Separate "pages" (mobile) vs in-page controls (desktop)

Sometimes the ideal view on mobile is very different from the ideal view on desktop. A common pattern here is that on desktop you have enough room to display all controls on the same screen, but on mobile you might want a separate full page view for certain actions. For example, imagine an airplane flight search application. On desktop you could have the fields for departing city and arriving city and dates on one page and display the results under those controls. On mobile, there isn't enough room for this so you would rather have a separate full page view for specifying search criteria.

In some ways, this is the least ideal situation. It is always better to be able to reuse the same controls and just style them differently using media queries. However, we must anticipate that this might not always be possible and think about what we could do in that situation.

To accomplish this, we could simply include the mobile full page alternate view in the page, hidden unless the width of the page is wide enough. By default, the mobile view is hidden.

#mobile {
    background-color: #fff;
    position: absolute;
    top: 0;
    bottom: 0;
    left: 0;
    right: 0;
@media only screen and (max-width: 480px) {
    .desktop-only {
        display: none;
    #mobile {
        display: block;

I created a very simple demo of this concept using the airplane ticket search example. In practice, you would want to have your application code add and remove CSS classes from a top level element to drive hiding and showing different views, but I've left that sort of thing out.

This "separate page" view could possible have a use on the desktop layout. You might have a situation where not all controls fit on the desktop layout so the same view to show all controls can be used on mobile and desktop. On mobile it might be styled as a full page view, whereas on desktop it could be styled as a modal popup.

Data binding is a little complicated in such a situation. Ideally, if the user changes the size of the browser window then switching from "mobile" to "desktop" or vice versa should be seamless from a user input perspective. Using the airplane ticket search example, if I am in the "mobile" view and I type in a Departing from city and then decide to expand my browser and get the "desktop" view, then ideally the Departing from control in the "desktop" layout should be populated with what I had typed on the "mobile" view. This means that I need to bind to the keypress event and update my model as each key is typed in Departing from and keep the "mobile" and "desktop" Departing from fields in sync.

Another challenge with this approach is that you, obviously, have two different views that have to be maintained. Arguably, this is one of the benefits of adopting MVC in the first place: your models are independent of views and models can have more than one view. However, it is still something extra that has to be maintained. It is probably better than having two separate sites though.

List and detail views on separate pages (mobile) vs both on the same page (desktop)

A common pattern with mobile apps is that you have a view(s) that display lists of data and tapping on a list item takes you to a view that displays details for that item. Examples include inbox listing/email detail and contact listing/contact details.

On desktop however there is enough space to show both the list and the detail, typically with the list on the left hand side and the detail view on the right. For example, an email client.

Media queries can be used to achieve both of these layouts. One nice thing here is that the same views are used on mobile and on desktop. Its just on mobile they are separate "pages" and on desktop they are all on one page.

How would you achieve this with media queries? I won't flesh out an entire example here, but I will outline how it would be done. The key I think is to have your SPA router add/remove CSS classes to a root element of the DOM. When the "list" class is added to the root element, the mobile media query will make just the list view visible, hiding the detail view. For desktop, there is no additional work needed. Likewise, when transitioning to the detail route, the "list" class is removed from the root element and a "detail" class is added. The mobile media query would then hide the list view and make the detail view visible. On desktop, the presence of the "detail" class on the root element might cause the currently selected item to be highlighted.

One challenge that this approach highlights (and this was true of the "separate view" UI pattern above) is that although on mobile the user is seeing only one view at a time, those other views are still there. For example, in an email client app, only the detail view may be visible, but the list view is still there and still responding to model updates. So for example, if you have a periodic check for new email, then the list view is updating to display new email received. This is more of a problem for mobile where off screen updates may cause performance to drag. On desktop the presence of alternate views that aren't on screen is unlikely to cause much of a problem.

Challenges with doing responsive SPA

Some of these challenges were mentioned above. Here I'll summarize them and also discuss how to address some of them. Not having experience developing a responsive SPA, this is mostly speculation about what I anticipate would be challenges building one.

Sizing of controls

It's possible to use media queries to size controls differently. You could for example make buttons large, more "tap friendly" on mobile screens and smaller on desktop screens.

However, one would have to assume that small screens are tapped on and large screens are clicked on. And that assumption isn't valid in a lot of cases. For example, a mobile phone might have a stylus that is able to make very precise touches. As another example, there are now several Windows 8 devices, some that are tablet/laptop hybrids, that are basically desktop devices but allow for touch interaction.

So I think a reasonable approach is to just size all controls for tapping. The tradeoff is that on desktop the controls are going to be "fatter" than necessary, meaning you won't be able to fit as many controls on the same page, but I don't think there is any reasonable alternative unless you want to aggravate uses with large touch screens.

Also, the fact that you can't have as many controls on a desktop view is not necessarily a bad thing. It will lead to a simplification of the UI, which will probably end up being easier to use.

Off screen view updates on mobile

I mentioned this one above. What can be done? For one, I think some testing and validation that this causes an issue is necessary first. Are DOM updates that are off screen as intensive as on screen ones for the browser to handle? Maybe, hopefully, not. I think it can very much depend on the application and might only affect certain views but not others.

If it becomes a problem I think one thing that could be done is to delay re-rendering the view if the view is off screen. Whenever it is ready to be brought back on screen the view could first be fully re-rendered. The problem here is that JS code now needs to know if the app is in "mobile" mode or "desktop" mode and so far I've been trying to keep the differences purely in CSS media queries.

Duplicate UIs

This one is mentioned above too. This is most applicable when the "mobile" version of the app needs a completely different view from the "desktop" version.

To mitigate this, first, obviously, try to use the same views for "mobile" and "desktop" and simply have them laid out differently.

Also it should be said that the duplication of effort and maintenance is probably not nearly so much as having two separate sites.

Also as mentioned above, there is also the data binding consideration: you'll want to keep the "mobile" and "desktop" views in sync at all times because the user could at any time transition from one to the other. In practice I think this requires only a little extra effort. See the discussion on listening for keypress events above.


Well that's it for my initial thoughts. I hope to investigate this further and try some of these techniques out.

Tuesday, June 24, 2014

A Backbone-JQuery Mobile skeleton project -

I've been playing around with integrating Backbone and jQuery Mobile. I'm planning on using them as the framework for implementing a mobile version of FuelMyRoute.

I started with Christophe Coenraets' backbone-jquerymobile sample app and made changes to bring it up to date with the most recent versions of jQuery Mobile and jQuery. I also made a couple different design choices. In this post I'll go over the changes I made.


A couple of jQuery's event listener methods were removed in 1.9: live and bind. I updated several event listeners, like the mobileinit event listener, to use jQuery.on instead.


To configure jQuery Mobile, you set up a listener for the mobileinit event and set properties on the $.mobile object. Here's what I have so far.

$(document).on("mobileinit", function () {
    $.mobile.ajaxEnabled = false;
    $.mobile.linkBindingEnabled = false;
    $.mobile.hashListeningEnabled = false;
    $.mobile.pushStateEnabled = false;
    $.mobile.autoInitializePage = false;

This is identical to Coenraets' config except that I also added setting autoInitializePage to false. We'll get to that in a bit. The other settings are there to turn off the routing and link hijacking behaviour in jQuery Mobile so we can use Backbone for routing instead. Coenraets explains in his blog post on the topic and the jQuery Mobile project also has notes on integrating with Backbone.


By default jQuery Mobile will call initializePage() when it starts up. initializePage() is important because it initializes the pagecontainer and sets up navigation events. It will try to find the first div with data-role="page" and change to that page. If there isn't a page in the DOM, it will create an initial dummy page. This generally works out fine if you are using jQuery Mobile in the more typical way where you have multiple pages defined in the one page. However, with our Backbone integration, there isn't any page until the router runs and injects the first page into the DOM so it doesn't make sense to automatically call initializePage().

So what I did was set autoInitializePage to false. The Router will call initializePage() after it adds the first page to the DOM.

var AppRouter = Backbone.Router.extend({

    changePage:function (page) {
        // Render and add page to DOM once
        if ($('#' === 0) {
        if (this.firstPage) {
            // We turned off $.mobile.autoInitializePage, but now that we've
            // added our first page to the DOM, we can now call initializePage.
            this.firstPage = false;
        $( ":mobile-pagecontainer" ).pagecontainer( "change", page.$el,
                { changeHash: false });

Managing Pages as Views

There are a couple different ways to go when managing page Views. You could remove them and recreate them each time or you could not remove them and just let jQuery Mobile hide and show them. Coenraets went with the "recreate each time" approach. I went with the approach of letting jQuery Mobile hide and show pages. My page Views are rendered and then added to the DOM once.

I did this because it seems a better fit with jQuery Mobile. Also I think there is a performance benefit on mobile to keeping DOM manipulations to a minimum.

However, I am still concerned about my page Views being bound to models even when they aren't being shown. Offscreen pages might re-render unnecessarily due to model/collection updates.

I might add to my router the ability to let pages know when they are being hidden or shown and that would allow a page to deal with offscreen rendering performance issues. One thing a page View might do is unbind its listeners when being hidden and rebind them when being shown again, which might be appropriate if intermediate events can be safely ignored. Another thing a page View might do when not being shown is continue to listen for events but defer any re-rendering until actually shown. I'll explore this more as needed, but I need a real world example to guide the design.

Enhancing pages

I did a little exploration into how you would handle jQuery Mobile enhancement if you re-rendered page. Basically, whenever render() is called, the page needs to be re-enhanced. jQuery Mobile will automatically enhance a page the first time it is changed to, but after that you need to call it yourself. I implemented a View base class I call PageView that has an enhance method. It allows you to implement render like so:

render: function () {
    // do some rendering
    // ...
    this.enhance(); // See PageView.enhance for details
    return this;

Keep in mind, though, re-rendering and re-enhancing the entire page is discouraged for performance reasons.

Minor stuff

  • $.mobile.changePage is deprecated. I switched to the change method on the pagecontainer. See the changePage method on the AppRouter above.
  • Instead of <div data-role="content">, use <div class="ui-content" role="main">
  • Contrary to Coenraets, I didn't find I needed to disable the first page transition, so I removed that code.
  • I also switched to project to use Bower and RequireJS to manage dependencies.
  • I never got around to dealing with transitions. Delegating routing to Backbone means you miss out on the declarative transition stuff in jQuery Mobile. I'm thinking that eventually I might add a transitions hash to the Router that would allow you to define page to page transitions, something like
    transitions: {
        'page1:page2':  'slide',
        // etc...

Sunday, June 01, 2014

Git client setup

These are some settings and configuration I've found useful so far while working with Git.

Git global configuration

git config --global "Marcus Christie"
git config --global

Can also set an editor to use for commit messages

git config --global core.editor gvim

Or with MacVim on OS X

git config --global core.editor 'mvim -f'

However, I think I prefer to edit commit messages in the terminal.

You can also use gvimdiff as a merge tool, but I haven't tried this yet.

Excludes file

Set up a global excludes file in ~/.config/git/ignore. My entries so far:



On Windows you want

git config --global core.autoclrf true

I think this is the default on Windows also, so this may be unnecessary.

Credential helper

This tip is mainly for when you are working with a repo over HTTPS, for example, with GitHub, and you authenticate with a username and password. You don't want to have to type passwords over and over. For this you can specify a credential helper that will securely store your password. On OS X:

git config --global credential.helper osxkeychain

On Windows, download git-credential-store. Then start up Git Bash, go to the directory where you downloaded the executable and then run it from the command line

$ git-credential-winstore.exe


Shortcuts so you can run git ci -m "fixed bug" instead of typing out commit

git config --global commit
git config --global status
git config --global checkout

Bash completions

On Windows, Git Bash comes with these already configured. On OS X, I downloaded git-completion.bash, dropped it in ~/bin and in .bash_profile I have

## Git completions
source ~/bin/git-completion.bash

Web viewer

On OS X:

git config --global instaweb.httpd webrick

Now you can start up a web viewer with

git instaweb

As a Mercurial refugee, I got used to hg serve so I like to have a web view.

Haven't tried doing this on Windows yet.


Set push.default to simple:

git config --global push.default simple

This setting affects what happens when you do a git push without specifing a remote or branch to push. With simple git will push the current branch to the upstream tracked branch. This mode also is the new default in Git 2.0.

Make sure that when you first push a branch to a remote server that you also set it as the upstream tracked branch. You can do that with the -u option:

git push -u origin mybranch

From then on every push can be done simply with

git push


Set merge.defaultToUpstream to true

git config --global merge.defaultToUpstream true

This setting affects what happens when you do a git merge without specifying a branch to merge from. With this set to true, git will merge in changes from the upstream remote tracking branch, which is generally what you want.

Anything else?

Are there any other things you do to configure Git on a new machine? Let me know in the comments or on Twitter.

Monday, May 26, 2014

Backbone Overview

Backbone is a JavaScript Model-View-Controller (MVC) library that can be used to create single page applications (SPAs). This article introduces the most important concepts in Backbone (Models, Collections, Views, Events, Router and Sync) and how they relate to building a client side JavaScript application.

What is Model-View-Controller (MVC)?

Model-View-Controller might be one of the most misunderstood software patterns ever. I'm not even sure I really understand what the original idea was (at least, what it meant to Smalltalk developers when first developed at Xerox PARC), and of course it has evolved over time into several different closely related ideas.

So this is far from authoritative, and I'll try to keep it simple. To me, MVC is a way to organize the implementation of a user interface in a way that separates concerns. Here, at a high level, are the various parts of a MVC framework:

  • Model - this is the representation of data that models the domain of interest. For example, for a TODO application, a model might be a TODO item. But Models aren't just data structures, they also contain the domain logic. A TODO item might expose a complete method that knows how to mark a TODO item as completed and properly manage any additional details related to task completion.
  • View - views are visual representations of models. A view reacts to changes in a model by updating the view to reflect that change.
  • Controller - controllers handle user input, both displaying views that the user requests and handling keyboard and mouse events. Controllers typically translate user input into updates on Model instances.

The goal is separation of concerns. Models know nothing of views; in a web application, models would have nothing in them relating to HTML or CSS, for example. Views know only how to represent a model, but they contain no business logic. Views respond to changes in a model, but know nothing of what the user is doing. Controllers are the only place in the application to handle things like navigation through the application, display of multiple views at once, transitions between views and translating user actions into model updates. But controllers don't contain business logic.

How does Backbone relate to traditional MVC?

The Backbone API has the following types:

  • Events
  • Model
  • Collection
  • View
  • Router
  • Sync

Where do each of these concepts fit into the traditional MVC pattern?

Backbone.Events are the primary mechanism for loose coupling between the models and views. Backbone Views bind to changes on the Models or Collections.

Backbone.Model and Backbone.Collection are the M of MVC: these types can be extended to provide the data and the implementation of domain logic for the application.

Backbone.View classes are a little V and a little C when compare to classical MVC. Backbone.View contains a render method that is responsible for generating/updating the DOM that is the view of the model, and for doing so it is typical to have a template. The template is more the V of MVC than the View class. Backbone.View also acts as a Controller in that it binds user events to methods on the View class that will update Models.

Backbone.Router is also fairly controller-ish in the traditional MVC understanding. The Router responds to user requests for specific URLs and can handle them by showing the right type of Views and by making sure that Model instances are available.

Backbone.sync is the RESTful persistence mechanism for saving/updating models. In Backbone, the models (Model and Collection instances) know how to persist themselves (which endpoint to call, how to serialize/deserialize, etc.). In that sense, sync is more in the M of MVC than anything else, but I'm not sure that persistence is in the scope of traditional MVC. (Another way to think of it is that sync is a translation layer between a client side model and a server side model, which are just two representations of the same domain object.)


Backbone.Events provides standard event listening and triggering behavior.

  • Events.on(event, listener) adds a listener
  •, listener) removes listener
  • Events.trigger(event)

Backbone.Events can also be mixed in to other objects or classes via underscore's _.extend mechanism, and it is mixed in to Backbone.View, Backbone.Model etc. So these methods are available from most Backbone types.

By convention, Backbone Events are often namespaced. For example, you can listen to all changes on a model with model.on("change", listener), but you can also listen to just a change of the property "name" with model.on("change:name", listener).

But keep in mind there is no extra support in the implementation of Backbone.Events for namespaced events really, not like jQuery namespaced events. "change:name" works because Backbone.Model dispatches an event for each property that changes and also a "change" event. As another example, if you listen for "foo" and a "foo:bar" event is triggered, your event listener will not be called. You would have to trigger both "foo" and "foo:bar" in your code if you wanted to support namespacing.

One problem with setting up event listeners, especially with a View listening to changes on a Model, is that the object being listened to has a reference to the listener. For example, let's say you have a ContactView that is listening for changes to a Contact Model instance. If you dispose of the ContactView but forget to remove all of the event listeners, then the Contact Model still has a reference to your ContactView. This leads to a couple problems. First, your ContactView instance won't get garbage collected, so your app is now leaking memory. Second, whenever the Contact Model updates it will continue to call the event listener on the zombie ContactView and update it, so you have a lot of unnecessary code execution (and debugging this can get really confusing when you see code executed several times instead of just once as expected).

To solve this, Backbone.Events has two helpful methods, listenTo and stopListening. listenTo has this method signature

object.listenTo(other, event, callback)

Whereas you call on on the object you want to listen to, listenTo is called on the listening object. The advantage here is that the listening object can keep track of all of the listeners and can remove them all at once, which is what stopListening does.

One other note about events. In a Backbone app, you typically have two types of events: Backbone events and DOM events. DOM events are typically set up for a View in the events hash, which we'll get to later. When using the events hash, this refers to the View, pretty much what you expect. However, keep in mind, if you programmatically use the jQuery API to bind to DOM events then this refers to the DOM element.


To create a Backbone.Model, extend the Backbone.Model class. You can specify default values for various properties.

app.Todo = Backbone.Model.extend({

    // Default attributes ensure that each todo created has `title` and `completed` keys.
    defaults: {
        title: '',
        completed: false

To instantiate a Model instance, call the constructor and pass in the attributes for the instance. Any defaulted attributes that aren't specified will receive their default values.

Models have get and set functions for reading and writing attribute values. As mentioned above, calling set("myattr", newvalue) causes two events to be dispatched: "change:myattr" and "change".

Models also have a special property called id which uniquely identifies a Model instance. This can be set to an integer or UUID string. You pass it in the attributes hash when creating a Model instance. You can also set the idAttribute property on the Model class if you have a property on your Models that can be used to uniquely identify instances.


Create a new Collection by extending Backbone.Collection. You typically set the model property to the Model class of this collection.

var TodoList = Backbone.Collection.extend({

    // Reference to this collection's model
    model: app.Todo,


Collections redispatch Model events, so you can simply listen, for example, to "change" events on the Collection and you'll be notified whenever a Model instance changes.

You can add and remove Models to and from a Collection. These methods will dispatch "add" and "remove" events. Removing a model occurs when you call remove and pass in a Model instance that has the same id as a Model instance already in the Collection. Collections also have a reset method which updates the Collection all at once and dispatches just a single "reset" event, which is more efficient for example when initially loading a Collection.

Collections have several Underscore methods, like _.each, that you can call directly.

Collections are typically where you will set up the RESTful URL by setting the url property. You can then call fetch to retrieve all of the model instances in the collection and add them to the collection instance. We'll look at this more in the Sync section below.


Backbone View's always have a DOM element that they can render into. By default Backbone.View will create the DOM element for you, but if the DOM element you want to attach this View instance to is already in the page you can set el to a selector for that DOM element

var MyView = Backbone.View.extend({
    el: '#myview',

If you let Backbone create your DOM element, you can specify tagName, className, id and attributes to be set on that DOM element and Backbone will apply them. That is, if you specify a tagName of li and a className of todo-item, Backbone will create a <li class="todo-item" /> element in the DOM for you.

As a convenience, View's also have a $el property which is the jQuery wrapped reference to the View's DOM element.

A typical thing to do when you initialize a View is to pass it the model or collection instance you want it to bind to. In the View's initialize method, you can then bind to changes to that Model or Collection:

var TodoView = Backbone.View.extend({
    tagName: "li",
    className: "todo-item",
    initialize: function(){
        this.listenTo( this.model, "change", this.render );

var todo = new TodoView({model: aTodo});

Besides binding to events on the Model, a View typically binds to DOM events. This is one of the controller-ish things a Backbone View does. To bind to DOM events, specify the events hash when creating the view. The keys in the events hash are in the form of 'eventName selector' and the value of each is the name of a function (or a function reference instead if you want).

var TodoView = Backbone.View.extend({
    events: {
        'click .toggle': 'toggleCompleted',
        // ...

Inside of a DOM event handler, this refers to the View.

To actually render a view to the page, you provide an implementation of render. The job of render is to update this.el however necessary. The typical way to do this is to have a String based template, by default, an Underscore template. You'll set template in a view to a template function that takes an object with the properties of your model and returns a String of HTML with the model properties applied.

There are several approaches to how to organize your templates, but the simplest way is to put them in the web page inside a <script> tag with type set to text/template.

<script type="text/template" id="template-id">
    <input type="checkbox" <%= completed ? 'checked' : '' %> />
    <label><%- description></label>

In your View class, you can read in the template once with

//... inside View class
    template: _.template( this.$('#template-id').html() );

Then you can implement render like so:

//... inside View class
    render: function() {
        this.$el.html( this.template( this.model.toJSON() ) );

        // Anything else you might want to do...

        return this;

Note that this.$ is a reference to the jQuery object. Also, render returns this so that parent View components can render child View components and then include them in themselves. For example, a container of these TodoView instances might do something like:

    render: function() {

        todos.each( function(todo) {
            var todoView = new TodoView({model: todo});
            this.$el.append( todoView.render().el );

When you are done with a View, you can call remove on it. This removes this.el from the DOM and also calls stopListening to remove all of its event listeners.


Backbone.Router allows mapping URLs to actions and events. You create a router instance by extending Backbone.Router. You can specify a routes hash that maps url patterns to function names (or function references). This is somewhat similar to the events hash in a View.

Route url patterns can use the :param syntax of the *param splat syntax. :param is used to match a part of a URL. A splat matches the rest of the URL.

var Router = Backbone.Router.extend({

    routes: {
        '/search/:query': 'search',

    search: function(query){

As an example of how you would use a Router, consider an email application. When the user navigates to an email folder, the app will display a list of the email messages in that folder. You would set up a route for an email folder, maybe like so:

routes: {
    '/folder/:folderId': 'goToFolder'

Then when a user clicks on the email folder, you can call Router.navigate('/folder/123', {trigger: true}). If you want to handle updating the view to show the folder and just have the router update the URL, you would not pass {trigger: true}.

So now you need to kick things off for your app and have your Router handle whatever the current URL is (for example, if the user bookmarked that email folder link and navigated to it directly). To do that you call start on Backbone.history.

var appRouter = new Router();
Backbone.history.start({pushState: true});

Backbone.history is a kind of global router. It can make use of the History API, calling pushState if available, falling back to updating the URL fragment if not available. You have to pass {pushState: true} to start to make use of pushState; it is something you opt into in Backbone.


Backbone.sync handles persistence. By default, it supports RESTfully retrieving and saving models to a server, assuming a JSON API. In the simplest cases, you just define the base url on your Collections.

app.Library = Backbone.Collection.extend({
    model: app.Book,
    url: '/api/books'

When you call the following methods, the following URLs are invoked via AJAX:

  • Collection.create maps to a POST to the URL /api/books
    • Collection.create is a convenience function that saves the new model to the server and adds it to the Collection.
  • Collection.fetch maps to a GET to the URL /api/books
  • Collection.update maps to a PUT to the URL /api/books/{id}
  • Collection.delete maps to a DELETE to the URL /api/books/{id}

There's a lot you can customize however. Models can implement Model.parse to have custom response parsing logic. You can override Backbone.ajax to customize the AJAX logic. And you can go whole hog and override Backbone.sync to completely customize how to load/persist data, for example, using LocalStorage as a backing store for your app.

Additional Resources