You are viewing the Articles in the UX Design Category

HTML5 Structural Elements

The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.
Tim Berners-Lee

The HTML5 Specification introduces many new semantic elements intended to provide meaning to the structure of a document. These elements are quite important as they allow for marking up a document in meaningful ways which, prior to HTML5, would have otherwise required a rather ambiguous markup consisting primarily of divs, ids, and classes to provide some semblance of semantic structure.

Being purely markup based, it is understandable why these new semantic elements may not excite as much interest as many of the more attention grabbing HTML5 specifications, such as audio, video, Web Workers, WebSockets, Web Storage etc. However, it is important, perhaps even necessary, to emphasize the significance these new elements present in terms of helping to solidify the realization of what the web is intended to be: an open medium for disseminating homogeneous and heterogeneous information.

With this in mind, combined with an informed understanding of the context in which each new semantic element can be applied, overtime the Web will, quite naturally so, evolve in many new, exciting, and perhaps previously unthought-of ways.

Broadly, the new Structural elements introduced in HTML5 can be succinctly summarized as follows:

The <header> Element
The <header> element is rather self explanatory in that it allows for defining content which is to be denoted as a header of a page, or a header within a section of a page. Headers typically provide introductory and / or navigational content via hgroup and nav elements. What is important to keep in mind is that multiple <header> elements can be defined per page.

W3C Specification (section 4.4.8)
The <nav> Element
The <nav> element represents an important section of navigational links to specific pages or specific sections within the current page. As such, not all navigational links need be defined within a <nav>.

W3C Specification (section 4.4.3)
The <article> Element
The <article> element provides a means by which content can be represented independently from the document or application with which it is associated. General examples could include, as one may have guessed, an article from a newspaper, a blog post, a comment on a blog post, a self contained UI widget, and so forth.

W3C Specification (section 4.4.4)
The <section> Element
The <section> element defines generic sections of a document, article or entire application. The section element is intended to provide semantics for a document and is not intended to be used as a container for styling purposes, in which case a <div> element should be used.

W3C Specification (section 4.4.2)
The <aside> Element
The <aside> element represents content which is relevant to, or supportive of it’s surrounding content, but is not required to convey the information set forth by the surrounding content. General examples could include a pull quote, a blog roll, a sidebar etc.

W3C Specification (section 4.4.5)
The <footer> Element
As with the <header> element, the <footer> element is rather self explanatory in that it allows for defining content which is to be denoted as a footer of a page, or a footer within a section element for it’s nearest ancestor. A page can contain multiple <footer> elements, each unique to a particular section.

W3C Specification (section 4.4.9)

Putting it all Together

The following example is comprised of each semantic element described above to form a complete, valid HTML5 document:

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:

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).

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 User Experiences. In fact, I have been leveraging many mobile concepts in Desktop UIs for some time now to much success.

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

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.

Technological Innovations and the Arts

Successful innovators in sciences and technology are artistic people. Stimulate the arts and you stimulate innovation.

I have always maintained that any skill or talent acquired can be attributed in part to an innate creative impulse; be it to learn something new or build something new. I am sure many of you can relate to this: that never ending fascination and driving force which compels one to create. Ultimately, creativity is the driving force on which all software is based and, one could argue, on which everything is based.

Recently, I came across a rather interesting article on scienceblogs titled “The Art of Scientific and Technological Innovations”. The article describes numerous scientific and technological breakthroughs which are based on artistic concepts. These include breakthroughs in such fields as engineering, medicine, biology and more.

Certainly a good read for any UI Engineer. Also, for those who find the link between creativity and programming interesting, I highly recommend Pragmatic Thinking and Learning by Andy Hunt.