There's another requirement in this project: a responsive design that works on devices with smaller screens. Well, it turns out that the UI we've come up with already looks pretty good on a tablet, with one caveat. You have to be holding the device in landscape mode. This is a problem that you don't really have to consider on the desktop, but it becomes critical with mobile devices.

From an architectural standpoint, we need to understand how the layout of the application will differ between screen sizes in order to decide how to assemble the application. In the designs so far, there are two panes side by side; there simply won't be enough screen space to allow for this on a portrait phone or tablet.

Instead, we'll hide or show the "left" and "right" panes depending on user actions. If they click on a thread of messages or the New Message button, the threads will be hidden and the correct right-hand pane will appear.

The only other issue with a portrait screen is the application header; there are too many components in there to fit in the width of a smaller screen. Instead, we'll show a menu button when in portrait mode that hides some controls when toggled and shows others. This gives us a second level of menu that's only shown when the user needs it. Here's a mockup of some of these ideas:

When clicking on one of the messages in the left screenshot, the list is replaced by the message thread seen in the right-hand side screenshot.

In an HTML-based responsive website, CSS media queries can be used to style the page in a fashion appropriate for any screen and orientation. While we can obviously still make use of CSS alongside Ext JS to do customization, our requirements are more complex; can Ext JS provide any extra features to assist?

The responsive plugin allows developers to tailor any component configuration based on a set of rules relating to the current device screen. Here are a few example scenarios in a theoretical responsive application:

In the webmail application, we've already mentioned showing and hiding header items. This can be done something like this:

{ 
    xtype: 'button', text: 'My Button',
    plugins: ['responsive'],
    responsiveConfig: {
        'portrait': { hidden: true } 
    }
}

There's a built-in rule called "portrait" that allows you to specify a configuration object that will only be applied when the rule is in effect. As architects, we must carefully consider the best way of making use of this feature without ending up with lots of messy configuration.

In the desktop version of the application we have two panes side by side. For this, we can use the hbox layout. However, for the portrait orientation, we'd like to be able to switch between one pane and another. This seems like a good use of the card layout. We'll also have to consider how to trigger the switch of the panes and have this code run in portrait orientation only.

The important takeaway is that the responsive plugin—in a similar fashion to view models—allows you to avoid writing lots of glue code that responds to the state of the application environment, and instead lets us declare our intentions at configuration time. After this, Ext JS takes care of most of the rest.

This is another example in which analyzing the requirements with a strong understanding of the available technology can result in a simpler architecture and a clearer code base.