Blog Details

Ok, I’m at it again with Part 2 of this blog series about using Sencha Touch, more specifically Sencha Architect to create a mobile application. In this part of the series I will be covering the following topics:

  1. Defining the Goals
  2. Define the Requirements
  3. Define our Application Structure
  4. Detail the functionality of each Screen and how I plan to achieve it

Defining the Functionality

 Ok, the first thing we are going to need to do is define what we want and the functionality that the application is going to have. In order to do that though, we need to know what our goals and our requirements are. I touched on this in my previous blog post so I will just give you a brief outline since the goals and requirements are not that complex.


  1. Presentation piece for BlueBolt to demo our capabilities in the mobile space
  2. Demonstrate the capabilities of Sencha Touch platform
  3.  Deploy the BlueBolt content in the mobile space
  4. Leverage PackFlash Constellation and DotNetNuke as a content management back-end tool for a mobile application



  1. Use Sencha Touch to integrate with DotNetNuke and PackFlash News
  2. Present our Services
  3. Present our Case Studies
  4.  Present our Blog content

So now we have a clear and simple definition of our goals and requirements we can determine our site structure and our functionality. Again, we are just trying to keep this simple so here is an outline of the site structure:

    1.  Loading Screen
    2.  Home Screen
        a.  Latest Published Items*
        b.  Navigation List*
        c.  Latest Tweet*
    3.  Services
        a.  List of services*
    4.  Case Studies
        a.  List of Case Studies*
    5.  Blogs
        a.  List of Blog Entries*
    6.  About
        a.  BlueBolt Process
    7.  Detail Screen
        a.  Content for the associated piece that was used to direct you to the screen.

*denotes page functionality

Generally what we do is use a spreadsheet to create a document that lays out all the pages of the site, the site map, each page’s functionality and each piece of content that is applicable to that page. When we are done with that we have a nice inventory list of everything that needs to be accounted for on the site.

Ok, so let’s go through each screen and briefly talk about what will be entailed in creating that screen. From here on out though, instead of using the term screen, I will be referring to screens as Views. Sencha is based on MVC, Model View Controller based architecture and using the term View will help you understand how everything is related when we get into more technical discussions.

Loading View


The loading view is pretty simple, it’s just going to be an image that shows up on the device while it is loading up our application.  


Home View

The home screen is going to be broken up into 3 or 4 pieces of functionality, I haven’t quite decided yet. We have been kicking around the idea of adding something to the home view that would allow our existing clients to easily submit bug tickets to our bug tracking system but that is still up in the air.

What the home view will have however is a navigation list that will link to all of the other views in the app. This list will be created as a list class and it will be connected to a static data store that will have the navigation data hard-coded into it. We will get into the details of how to do all of this later on in the series.

The home view will also have a link to the 5 most recent pieces of content that we have added to the site. Essentially this will link to our blog view and will pass a variable to it that will be used to filter our blog content. We will also have a tie into our twitter feed that will show the last 3 tweets that have gone out. We can achieve this in 2 ways, we can embed a twitter widget into the html of that home view or we can connect to the twitter API and pull the information we want.

 Services View

The services view essentially is another list...but lists are so boring and we are trying to make this a “show piece” or a “kitchen sink” type of application, so I’m not going to use a list the way you may think. Instead what I am going to use is a block of icons, each icon representing one of our services. Creating the icons should be pretty easy, they already exist on our regular site so creating this view is just a matter of using a few container classes nested inside one another. Each one of the icons will “link” to the detail page. When the detail page is loaded, the content will be pulled from the data store I set up for it and rendered onto the screen.

Case Studies View

The Case Studies view is also essentially another list but like I said before, lists are boring, so we are going to use the carousel class to present this information. Users will be able to swipe from one case study to the next. When the user clicks onto a case study, they will be directed to the detail view and there will be an ajax call that loads up the appropriate information. 

Blogs View


The Blogs view, while lists are pretty boring this view will be kind of text heavy so I am going to go ahead and just use a list class but I will be doing some customization to the list class to achieve the desired result. 

Detail View


The detail view will be used for all three of our content types, Services, Case Studies and Blog posts. The detail view will consist of nested container classes. The important thing with the detail view is going to be the model that is used to define the data. The model then can be rendered onto the screen using what Sencha calls the ItemTpl or the html template for that view.


About View


The about view will essentially look like the detail view and will be a template for any other static content that I may want to add to the application.

Aside from the views, the application will also have a navigation bar in the top and a contact button that will pull up a contact modal panel. This functionality will be universal to all views inside the application and will be driven by using a NavigationView class which will serve as the root class that all content is pushed into. The beauty of the NavigationView is that it handles your navigation history and manages your back button for you so you don’t have to do anything special with the code, it’s built into the class. Take a look at the outline of the application below: 

If you are interested in seeing the wireframes in action, you can find them here,

This wraps up this week’s blog post, in my next post, I will present the designs I have come up with and I will start to dig into the real technical stuff as I start to go more in depth into the MVC architecture the site will use and I start to talk a bit more about the classes I will be using.