You are currently browsing the archives for the Mobile category

AT&T Best Practices Guide for App Development

When considering the various best practices surrounding the design of Mobile Web Experiences and Architectures, such works as the W3C’s Mobile Web Application Best Practices guide, or the excellent Mobile Web Best Practices site, and of course, the seminal text, Mobile First, are likely to come to mind. The concepts and strategies presented in these works are a staple in the design of many modern Mobile Web Experiences and are without question an invaluable resource. In addition to these and other similarly related works, another new and valuable resource has been made available from a very important player in the Mobile Space indeed – an actual Wireless Carrier, AT&T.

Recently, I was contacted by a representative of the AT&T Developer Program informing me of the research conducted by the AT&T Research Labs and, the subsequent resources made available by AT&T as a result of their findings. Since I was unaware of this work, I was very interesting in learning more and, after reading the introductory statements, I was quite eager to apply AT&T’s recommendations as well; to quote specifically:

We quickly saw that a few, simple design approaches could significantly improve application responsiveness.

Having read through the material in it’s entirety (provided below) I must say I am rather impressed. The information provided has very real and practical implications on the design of Mobile Web Applications. Specifically, I found the clear and concise explanation of the underlying implementation of the Radio Resource Control (RRC) protocol to be particularly relevant and useful. RRC is by far one of the most important design factors to consider in terms of battery life and Application responsiveness and, as the research suggests, this may not have been common knowledge.

By far, the most interesting and notable aspect of the AT&T Research Lab’s work in this area is the fact that all of the information provided is applicable in the context of all Wireless Carriers, not just AT&T. That is, the recommendations given, such as those regarding the RRC State Machine, for example, are all based on carrier-independent standards and protocols implemented by all Wireless Carriers. As such, understanding the implementation specifics and recommendations provided is certain to prove valuable for all users of your Application, regardless of their Carrier.

If you haven’t all ready, I highly recommend reading and applying the principles provided by AT&T’s research to your current and future Mobile Web Application Designs.

AT&T Research Labs: Mobile Application Resources

Build Efficient Apps
Profiling Resource Usage for Mobile Applications: A Cross-layer Approach

January 15, 2012 Android / Browsers / Design Patterns / HTML5 / iPad / iPhone / JavaScript / Mobile / Mobile Web / Software Engineering / Tablets / User Experience Design
No comments

Configuring iOS HTTP Monitoring

When developing Web Applications for the Mobile Web Experience it is often useful to have a clear view into all HTTP requests and responses sent between the client and server. This is quite simple to accomplish when developing Web Applications for the Desktop as, the browser is running locally so any standard HTTP Monitor will suffice. And, while it is a normal part of a typical development workflow to run an application locally the majority of the time, testing on each target device is obviously an essential part of the process as well.

Luckily, with Charles, on iOS this is quite simple to accomplish.

Configuration

To configure Charles to proxy all requests from an iOS device, simply follow these basic steps:

  1. From your iOS Device, open Settings.
  2. Go to Wi-Fi, select your Network and select the Blue “arrow” icon.
  3. Scroll to HTTP Proxy and select the Manual Button.
  4. In the Server field, enter the IP address of your development machine.
  5. In the port field, enter port 8888 (the default port to which Charles binds).
  6. Leave Authentication set to Off.

And that’s all there is to it. Now, open Mobile Safari and go to your Web Application’s URL (or any page on the web for that matter). On your development machine, in Charles you will receive a prompt with the IP Address of your Mobile Device, click “Allow” and you are all set. When you are done working, make sure to turn off HTTP Proxy on your device.

Additional Note

While this article may be focused on Mobile Web Applications, these same configurations apply to all HTTP traffic from any application on your device that requires resources over the web.

December 16, 2011 AJAX / Browsers / Mobile / Mobile Web / Tablets
No comments

DHTMLX Touch 1.0 Released

Last week, shortly after I blogged about the release of jQuery Mobile 1.0, I received an email informing me of the release of another Mobile Web Framework: DHTMLX Touch 1.0.

Being that I was unfamiliar with DHTMLX Touch (as I have been using jQuery Mobile almost exclusively), I was quite interested to learn more; and, having tried the Examples and reviewed the Documentation, I was rather impressed by DHTMLX Touch.

And so, if you haven’t already, check it out.

November 23, 2011 AJAX / Android / HTML5 / iPad / iPhone / JavaScript / Mobile / Mobile Web
No comments

CSS3 Attribute Selectors

The power of CSS Selectors can not be understated; for, without them, there would be no simple means by which developers could target specific elements for styling in a manner abstracted from, or external to, the actual markup to which the styles will bind.

In addition to some of the more common Simple Selectors, such as Type Selectors, Class Selectors and Id Selectors, we have have Attribute Selectors, which, as the name implies, allow us to match elements based on their attributes.

Attribute Presence and Value Selectors

CSS2 introduced four Attribute Selectors; referred to as Attribute Presence and Value Selectors, which allow for course grained matching of specific elements based on their attributes and / or attribute values. These include the following:

e[attr]
Where e is an element and [attr] is an attribute of element e. For example, p[title] would match all p tags with a title, regardless of the value of the title.

/* Matches all <p> tags with a title and changes their background color to red with white text */
p[title]{
    background-color: red;
    color: white;
}
e[attr=val]
Where e is an element and [attr=val] represent an attribute of element e which contains the exact value of val. For example, p[title="Example 1"] would match all p tags with a title which equals “Example 1″ exactly.

/* Matches all <p> tags with a title equal to "Example 1" and changes their background color to green and text color to white */
p[title="Example 1"]{
    background-color: green;
    color: white;
}
e[attr~=val]
Where e is an element and [attr~=val] is an attribute of element e which has a value containing a whitespace-separated list of words, one of which equals val exactly. For example, p[title~="Example-1a"] would match all p tags with a title containing the word “Example-1a” in a list of whitespace delimited words.

/* Matches all <p> tags with a title containing the exact word to "Example-1a" and changes their background color to black and text color to red */
p[title~="Example-1a"]{
    background-color: black;
    color: red;
}
e[attr|=val]
Where e is an element and [attr|=val] is an attribute of element e that has a value of val exactly, or begins with val immediately followed by a hyphen “-”. For example, p[title!="Example"] would match all p tags with a title containing the word “Example-”, followed by any other value, such as “Example-1″, “Example-A”, etc..

/* Matches all <p> tags with a title containing the word to "Example-" and changes their background color to blue and text color to white */
p[title|="Example"]{
    background-color: blue;
    color: white;
}

View Example

Substring Matching Attribute Selectors

In addition to the above Attribute Presence and Value Selectors, CSS3 expands on this by defining three additional Attribute Selectors; referred to as Substring Matching Attribute Selectors. These additions allow for fine grained matching of specific elements based on their attribute values.

In simplest terms, the new Attribute Selectors in CSS3 can be used to match an element with a given attribute whose value begins, ends or contains a certain value. The following is a basic description and example of each new Attribute Selector:

e[attr^=val]
Where e is an element and [attr^=val] is an attribute of element e which contains a value that begins with val.

/* Matches all linked resources sent over https */
a[href^="https"]{
    color: red;
}
e[attr$=val]
Where e is an element and [attr$=val] represent an attribute of element e which contains a value that ends with val.

/* Matches all anchor tags to .html documents */
a[href$=".html"]{
    color: green;
}
e[attr*=val]
Where e is an element and [attr*=val] is an attribute of element e which has a value that contains val.

/* Matches all anchor tags which contain a query string */
a[href*="?"]{
    color: blue;
}

View Example

To summarize, there are a total of seven Attribute Selectors in CSS3, three of which are new. Whether used for general matches, such as global Attributes; e.g. *[hreflang|=en] or more specific matches, such as chaining; e.g, a[href^="https"][target="_blank"], Attribute Selectors provide a powerful mechanism for selecting both general and specific content within a page.

November 10, 2011 Browsers / CSS3 / HTML5 / JavaScript / jQuery / Mobile / Mobile Web
No comments

Test Driven Javascript with QUnit

For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.

For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:

test("Test expected namespace override", function() {
    var expected = "someNamespace-";
    var actual   = $.mobile.ns;
    equal(actual, expected, "expecting namespace to have been set.");
});

Figure 1 (run) (source)

The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.

As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.

A Complete Example

As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).

September 19, 2011 Agile / AJAX / CSS3 / HTML5 / iPad / iPhone / JavaScript / jQuery / jQuery Mobile / Mobile / Mobile Web / Refactoring / Software Engineering / Tablets / Test Driven Development / User Experience Design
No comments

The convergence of Mobile and Desktop UI Design

Successful User Experience and User Interface Designs are inherently intuitive and simple. Not necessarily simple in the “less is more” aspect alone but rather in that the designs focus on essential tasks – and provide an experience which allows for completing those tasks easily and efficiently.

With this in mind it is not surprising that many modern Desktop UI Designs are being influenced by Smartphone UIs; for they, by necessity of constraint, address many design challenges which can be easily overlooked in Desktop UI Designs.

Both Apple and Microsoft have borrowed from their respective Mobile designs in their latest Desktop OS offerings; Lion and Windows 8.

Ultimately, I believe this convergence of the Mobile and Desktop paradigms will lead to better Use Experiences. In fact, I have been leveraging many mobile concepts in Desktop UIs for some time now to much success.

July 4, 2011 Mobile / Software Engineering / Tablets / User Experience Design
1 comment

A Step Backwards In Usability?

I recently read a preview of a column which is to be published in the next addition of ACM CHI magazine, Interactions. This particular article is a rather interesting read in that it touches upon what the authors argue are the many short-comings in current Gestural Interfaces; stating that they pose a huge step backwards in terms of Usability.

This may not have raised many eyebrows if it were not for the expertise of the articles authors, Donald A. Norman and Jakob Nielsen; both of whom know quite a bit about HCI.

Experimentation in new technology and the process of learning what works and what does not can be challenging. This article raises some important, yet mostly overlooked, concerns surrounding new technologies which are built upon Gestural Interfaces; i.e. current touch screen devices such as iOS and Android. Certainly a good read for anyone interested in Touch Screen development. Gestural Interfaces: A Step Backwards In Usability

May 30, 2011 Android / iPad / iPhone / jQuery Mobile / Mobile / Mobile Web / News / Tablets / User Experience Design
No comments

Put your Best People on Mobile

So first the biggest number – 5.2. That is in billions with a B. There are 1.2 billion personal computers in use worldwide including desktops, laptops and tablet PCs like the iPad. There are 1.1 billion fixed landline phones. There are 1.0 billion automobiles registered and in use. There are 1.6 billion television sets, 1.7 billion credit card users, 2.0 billion internet users, 2.2 billion people with a banking account, and 3.9 billion radio receivers in use worldwide. Mobile utterly dwarfs them all – with 5.2 billion currently active, ie fully paid mobile phone subscriptions. Active mobile phone accounts. 5.2 billion. yes, 4.5 times more mobile phone subscriptions than personal computers or landline phones. 2.5x more mobile accounts than all internet users. 3 times more mobile subscribers than the total number of television sets. Mobile is huge. – Tomi Ahonen

These numbers are simply staggering.

For sometime now Myself and pretty much everyone else for that matter have been speaking quite a bit about the significance of Mobile. And while it may seem quite obvious that Mobile is huge, understanding the sheer magnitude of Mobile is truly put into perspective when some real world comparisons are made.

To get an idea of just how big mobile is, consider the recent article published by Tomi Ahonen, (which I found thru Brian O’Connor) in which some rather astounding numbers are provided in his aptly titled post: All the Numbers, All the Facts on Mobile the Trillion-Dollar Industry. Why is Google saying: Put your Best People on Mobile?. Certainly a must read for anyone interested in Mobile Development.

April 28, 2011 Mobile / Mobile Web / News / Tablets / User Experience Design
No comments

Ergonomics of Mobile Touchscreen Design

Dan Saffer has published an interesting article illustrating the Activity Zones for Touchscreen Tablets and Phones which appear to provide the most natural level of usability.

The article is particularly interesting in that it touches on (pun intended) the human factors involved in how we physically interact with devices. The Activity Zones outlined in the article equate to the areas which provide the greatest level of physical comfort when interacting with a touchscreen device.

The general physicality of natural, symbolic and sequential gestures associated with designing touchscreen experiences as well as the environmental distractions and engagement models of mobile experiences is a topic which I find quite interesting. This is a significant leap forward from the traditional WIMP interaction model. All of these considerations allow for a more Human centered design focus, just as it should be; after all, this is the purpose of UI Engineering.

March 9, 2011 Agile / Android / iPad / iPhone / Mobile / Tablets / User Experience Design
No comments

Multiscreen Software Design

“We are in the midst of a revolution across a variety of screens”

You may recall first hearing the notion of a “Multiscreen Revolution” during the keynote at Max 2010. If you take a moment and think about it that’s a rather profound statement, and by all apparent indications a very true one.

This is also how Kevin Lynch, CTO at Adobe, begins his recent article, aptly titled “The Multiscreen Revolution” in which Kevin provides a succinct breakdown covering the driving forces behind this revolution and how it is guiding the future of the Flash Platform.

Allow me to digress for a moment as, in a way, for me at least, the “Multiscreen Revolution” tends to conjure up the hypothetical notion of a Multiverse. This may be a suitable analogy I suppose as we have been focused in a predominantly Personal Computer based reality for many years, and while this remains relevant, it is no longer exclusive.

I have been giving a lot of thought lately regarding designing software in a multi form factor paradigm and felt I would share some initial thoughts on the subject. Keep in mind much of this is still quite new and subject to change; however, I have made an attempt to isolate what I feel will remain constant moving forward, particularly in the context of developing native applications with the Flash Platform across a variety of screens.

First, User Experience Design

My initial thoughts on the implications of what a Multiscreen paradigm will have on the way we think about the design of software are primarily concerned with User Experience Design (UX Design). While simply using CSS3 media queries to facilitate dynamic runtime layouts will be needed for most HTML based web applications, I do not believe these types of solutions alone will allow for the kinds of compelling experiences users have come to expect. Sure they are useful, and for some HTML based websites they may suffice. However, in the context of more complex applications, RIAs in particular, but also just about every application developed specifically for a PC, too, I believe UX Design will need to encompass the best of what a particular form factor, “screen” or whatever you prefer to call it, has to offer, be it a PC, smartphone, tablet or TV.

For example, it is extremely rare that a UX Design intended for users of a PC will translate directly to a Mobile or Tablet User Experience. The interactions of a traditional physical keyboard and mouse do not equate to those of soft keys, virtual keyboards and touch gesture interactions. Moreover, the navigation and transitions between different views and even certain concepts and metaphors are completely different. In simplest terms; it’s not “Apples to Apples”, as the expression goes.

With this in mind, UX Design should remain at the forefront of Software Design, and in order for that to happen UX Design will not only need to continue to reflect the needs of users, but also by leverage the capabilities of the particular devices and screens on which an application will run. This is necessary as it better serves the needs of users in new and useful ways. Likewise, UX Design will need to account for the limitations (resources in particular) of those same form factors.

Second, Architecture

Mulitiscreen design obviously poses some new challenges considering the growing number of form factors which will need to be taken into account. The good news is most existing well designed software architectures have been designed with this in mind all along. That is, the key factor in managing this complexity I believe will be code reuse. A common theme amongst many of my posts, code reuse has many obvious benefits, and in the context of Multiscreen concerns it will allow for different screen specific applications to leverage general, well defined and well tested APIs. Code reuse will certainly be of tremendous value when considering the complexities encountered with Multiscreen design. Such shared APIs can be reused across applications which are designed for particular screens or extended to provide screen / device specific implementations.

For example, the Architectures I have worked on are designed such that each is broken out into specific modules (libraries) which, on a high level, are typically as follows:

  • unittesting-support: Provides convenience extensions of unit testing and mock frameworks.
  • commons: Provides all generic, reusable APIs which have no dependencies outside of those of the Flex Framework and Flash Player API.
  • framework-support: Provides reusable extensions of a particular framework. There can be multiple framework-support libraries, each of which would be specific to an individual framework; e.g. parsley-support, swiz-support, robotlegs-support, cairngorm-support, springactionscript-support etc.
  • business: Provides domain dependent, business specific reusable APIs which are common amongst all projects within the business domain. This includes domain models, shared services, Presentation Models, UI components and anything else which is specific to the business domain. While all of the previously listed libraries could be used with any AS3 / Flex project, the business library is intentionally coupled to the domain.

All of the above projects are used by the different business applications, allowing for significantly reduced complexity of each individual application. Moreover, each library provides isolated test coverage which allows for a greater sense of confidence when building applications which are dependent on them. This type of structure also lends itself well with common SCM and build conventions, allowing for simplified branching and versioning.

Architectures designed similar to what I have described above I would consider to be “multiscreen ready” (provided they are optimized and efficient) in that much of the underlying implementation has already been completed, tested and proven. What’s left is the mobile, tablet or TV application designs which should be mainly concerned with UX, particularly interactions, navigation and device capabilities. From these screen specific UX Designs the application architecture is mainly focused around view concerns specific to those devices; leveraging the existing APIs as needed. This is where the Presentation Model Pattern (which I have been recommending for years) or similar patterns will be of great value.

I also anticipate additional libraries being abstracted in addition to those I have listed above as a result of these device specific projects being developed. For example, I could easily imagine “device-support”, “mobile-support” and “tablet-support” projects which would provide reusable APIs specific for those screens so as to be leveraged across applications. In fact, I am working on libraries such as these at the moment.

Reusable libraries are nothing new; however, their role now is perhaps even more important as it is quite likely that multiple implementations of the same application will be needed for the various form factors and contexts. Existing reusable libraries may also need to be further optimized to provide the best performance against the slowest devices in order to be considered suitable for devices with the most limited resources. A natural side effect of such optimizations is that implementations of an application targeting the fastest form factors (typically, PCs) will benefit greatly.

Some Concluding Thoughts

In short, I believe both users and developers alike will be best served by providing unique User Experiences for specific screens as opposed to attempting to adapt the same application across multiple screens. One of the easiest ways of managing the complexity of multiscreen design and development will inevitably be code reuse.

I also believe the main point of focus should be on the medium and small form factors; i.e. Tablets and Smart phones. Not only for the more common reasons but, also because I believe PCs and Laptops will eventually be used almost exclusively for developing the applications which run on the other form factors. In fact, I can say this from my own experiences already.

While there is still much to learn in the area of Multiscreen Design, I feel the ideas I’ve expressed here will remain relevant. Over the course of the coming months I plan to dedicate much of my time towards further exploration of this topic and will certainly continue to share my findings.

March 6, 2011 Agile / Android / APIs / Code Review / Design Patterns / iPad / iPhone / Mobile / Object Oriented Design / Refactoring / Software Engineering / Tablets / Test Driven Development / User Experience Design
2 comments
← Older Entries