As a hobby hacker I am excited that Android is open source.  Yes, Android is open source, not open development. No one claimed otherwise and it hardly means it’s all for naught. Open development for Android would be great, but the *fact* is that there are potential downsides including incompatible devices using unreleased code and fragmenting the ecosystem even more. It might not be a big deal for me personally, but I can certainly see how it could be big deal for others (including Android app developers).  Pretending there are no downsides isn’t being honest.  No Honeycomb was not open sourced for good reasons AND Google was rightfully taken to task for it.  Yes, both can be true.  Ice Cream Sandwich is open source.  I’m excited by the precedent that the success of Android set for device manufacturers to look more seriously at open source. I love that I have a hackable device in my hands with so much capability.  I love that we’ll be able to purchase a Spark with Plasma Active. I love the precedent that the Spark sets for future devices with a Free software stack.

We cannot be so myopic to pretend that unless we have everything, nothing matters.  I love that the KDE community lives up to every one of those bullet points above in both words and deeds. Yes, no one gets a free pass and we must be uncompromisingly vigilant in pointing out to Google and others the specific areas they fall short.   It  is both this vigilance and the recognition we provide when companies do the right thing, that has gotten us to where we are today.  However, these Tourette’s-like outbursts declaring the end of the world is nigh, are actually counterproductive.  Why? Because when we use the exact same words to describe far worse offenders, it drains those words of any meaning and it deprives the rest of the community of the rhetorical tools we need to fight for the goals of this movement.

Gitorious has been an absolutely wonderful host for this fun little project for the last 2 years. In that time there are many things I’ve learned and there will certainly be many things I’ll miss.  That said, I am definitely looking forward to working more closely with the KDE community.

So this is your invitation to join in on the fun.  As always, Bangarang remains a project I spend time on for no other reason than the joy of it.  Good energy in, good energy out.  Rumor has it that the KDE community has oodles of good energy!

I really enjoy creating stuff.  Occasionally, if I’m at all like other folks (debatable, I know), I look at the stuff of other people’s passions (music, paintings, architecture, whatever) and say man I wish I could do something like that.  I often find myself wishing for the passion of others while ignoring my own passions, my own motivations.  Working on Bangarang is one of my own avenues of creative expression. I do it with joy.  I’ve learned that, much like others who explore their own avenues of creative expression, I’m most creative when I choose not to do it from a place of anxiety or obligation to the work.  It sounds stupidly simple but I have the most fun when I’m actually having fun.  Fun breeds fun. Joy breeds joy.  And it is not just ok, but better, to take breaks when the fun diminishes.  That is the luxury of a hobby instead of a job. I do it for fun and I can take breaks whenever I want to.  And the fun does diminish.  It is the nature of living.  We can’t go about prancing around like we’re blissfully happy and eternally creative all the time.  We’re not.  And that’s ok, because it allows us to appreciate those joyful times all the more.

And the Bangarang 2.1 release paired with the holiday season is one of those times for me.  Happy holidays!

(Release notes are here).

There was once a 2.1 target features list, but as I’ve realized over the last few months, with just myself as the main developer, it just makes sense to work on whatever motivates me, when I’m motivated to work on it.  I’ll do target features and and more fixed release schedules if the number of contributors grow. Fun is my biggest motivation and it’s gotten quite a bit done thus far.  And yes, I do enjoy knocking out bugs as much as I enjoy adding features.

I think there were enough new features to warrant the bump to 2.1 instead of another 2.0 bugfix release.  Anyway, I’ve really enjoyed these last few months of development and if anyone wants to join in on the fun, holler! Till then please help me test and report any issues you encounter.

I just committed some of these updates to master and I’m looking for feedback.  Feel free to use the bug tracker or Google+ to share any feedback with me. You can use the comments here as well. Here are a couple current screenshots of Bangarang in touch mode (bangarang –touch):

A few of the updates for touch mode include flickable scrolling in the media lists, playist and Info View, disabled some mouse hover interaction mechanisms and redesigned others to work better in touch mode, adjusted more widget graphics, size and spacing to work better in touch mode, touching the video during playback shows or hides the playback controls and a few bugfixes.  No, I’m not totally pre-occupied with these touch mode enhancements – I’d like to tackle some bugfixing over the next few weeks.  Anyone interested in helping is welcome.

I’m really grateful to the Kubuntu folks and Canonical for their generosity.  I have much more touch mode work to do and, so far, having a tablet for development testing has made it much more efficient and fun.

So just how much do I think ownCloud rocks? This much:

You can browse and play the music on your ownCloud (or any Ampache server) from Bangarang.  Added to master this weekend after a couple days of hacking.

Did I mention that ownCloud rocks?!

Remembering what it was like being 15 years old, I wonder how similarly impatient, clumsy, creative and anxiety-ridden KDE will be over the next few years.  Perhaps KDE will weather those years much more gracefully than I did.

I had already made a conscious effort in the existing UI design to account for lower resolution displays like netbooks.  Now I hope to get to the threshold of being at least tolerable on tablet devices.  This primarily means accounting for sometimes higher dpis as well as the more obvious transition from a mouse and keyboard to touch.  At a minimum, this means increasing target areas and increasing the pixel size of some visuals and text.  (More completely, it means a full evaluation of all the interaction mechanics necessary to execute the basic use-cases and adjusting the design accordingly).

So the result of this first step are in the following screenshots:

Touch disabled(left) and enabled(right)

And at what I think is the WeTab resolution:

I also disabled drag and drop in the Media Lists view when touch is enabled since it’s likely to be running fullscreen.  Note that this is not all QMLified and fully optimized for touch (including swipe scrolling and all that)… yet.  Like I said, I’m mostly hoping to get it tolerable first.

But here’s the deal. I don’t have a tablet with Plasma Active to test on.  Which means I’m mostly doing this with my overly active imagination. So if anyone would like to test and can provide some feedback you can get the latest from http://gitorious.org/bangarang. To enable touch, run “bangarang –touch [any character]“.  Thanks!

Fixes include:

• fix crash when playing video with phonon-gstreamer 4.5.0
• tag sorting
• updated translations

A quick recap from the first entry:

• Ideally, use-cases should be implementation-agnostic.
• The best UI allows the user to accomplish their goal(s) with minimum cognitive impact.
• Reducing or eliminating elements with low Information Values should a goal of the UI designer.
• Minimizing or eliminating high Interaction Impulse elements that do not support the use case should be a goal of the UI designer.

In this entry, I’ll take a look at layouts from a pretty high level.  The focus will mostly be on the high-level layouts you see when you first encounter an application, a desktop environment, or website, not necessarily the low-level layout used for individual UI elements. These high-level layouts may also be how you recognize or remember the application.  For example, when you think of a Windows 7 desktop what is the first image that comes to mind? For me that image has two general sections: the desktop area on top and the taskbar area below.  How about a web browser like Chrome or Rekonq?  Address bar + tabs on top, page content below. How about a file manager like Dolphin or Nautilus?  Places on the left, list of file icons on the right. I’m talking about that high-level layout you encounter when you first ask yourself  ”Ok, how does this thing work?” and proceed to visually scan the application for clues.  Go check out your favorite app, desktop environment or website and see if you can identify the top level layout pattern.

Consider the layout patterns in Figure 1.

Figure 1 - Two Section Layout Patterns

Each layout pattern has two areas or sections arranged in different ways. In order to answer “How does this thing work?”, the user looks at each section, tries to understand its purpose then move to another section if necessary. Depending on the UI elements in each section and, in some cases, depending on the t layout pattern itself, a visual hierarchy will emerge that encourages the user where to look first, then where to look next. As the user moves from section to section, they may also try to understand how the sections relate to each other.  This visual scanning allows the user to accumulate the necessary information to answer the question.

Note that while I’ve framed the user’s question as “How does this thing work?”, answering that question is not really what the user is, in the end, hoping to accomplish. The user hopes to accomplish a specific goal (use-case) by using your application as a tool.  Answering “How does this thing work?” is a means to that end, not an end in itself.  During the visual scan the user accumulates information that is relevant to the use-case they are trying to satisfy. This implies that the user is generally not terribly interested in scrutinizing every icon, reading endless text and twiddling all the knobs and dials of your application to see what happens just for the sake of it.  Again, the user is interested in accomplishing a specific goal. Once the user has enough information to satisfy the use-case, every remaining UI element that was not scanned by the user is entirely extraneous to that use-case.  The quicker the user can answer the question the better, which means that the Information Value of each UI element in a section, and of the section itself, must be high enough that the user can quickly determine the section’s purpose and its relationship to other sections.

The arrows shown in the layout patterns are intended to show the relationship between sections. If the user is just gathering information visually then consider the arrow to mean “provides context for”.  If the user  is interacting with the application , consider the arrow mean “can affect”.  So in all the four layouts, it could be said section 1 provides context for, or can affect, section 2. In layout pattern D, section 2 provides context for, or can affect, section 1.  In each section high Information Value elements (again, relevant to the use-case) help the user figure out the “provides context for” relationships and high Interaction Impulse elements (relevant to the use-case) help the user figure out the “can affect” relationships.

So consider Dolphin, for example, which has the Places panel on the left and the file listing on the right as in Figure 2.

Figure 2 - Dolphin

When the user is just gathering information, the files displayed in the file list section generally corresponds to the selection in Places section – the Places section provides context for the file list section. The highlighted Home element in the Places section also appears in file list section as the “header” (breadcrumb control) in that section (even with a similar icon), providing a relatively high Information Value for understanding how the two sections might be related. The familiar selection highlight in the Places section also provides a high enough Interaction Impulse to suggest to the user that they can make a different selection in this section. If the user makes a different selection in Places, the file list section is updated to reflect that selection – the Places section can affect the file list section.  However, if the user selects a different icon in the file list section, the Places panel doesn’t (generally) change – the file list section doesn’t (generally) affect the contents of the Places section.  These sectional relationships suggest that the layout pattern is similar to Pattern A in Figure 1.

The default KDE Plasma or Windows 7 desktop environment is similar to Pattern D with the panel/taskbar area in section 2 and the desktop area in section 1. Can you recognize these patterns in your favorite application, desktop environment or website?

Of course, there can be more than just two sections in a layout pattern.  Generally, the more sections in a layout, the greater the opportunity for increased effort on the part of the user.  For every added section, the user may have to visually scan more sections and spend more time figuring out the purpose of each section and the relationships between sections.  That doesn’t mean a successful design is impossible with more sections. It just means greater design effort is needed to minimize user effort. Figure 3 shows some three section layouts.

Figure 3 - Three Section Layout Patterns

Section relationships, if they exist, should always be between adjacent sections. Pattern I and III shows what I think are good relationships between sections.  Pattern II and IV shows section relationships that might be a bit more challenging for the user to deal with.

It can also be helpful to keep the relationships going in the same general direction (Pattern I and III).  When the user is visually scanning the interface, this can help create a consistent mental model of how to gather information from the application. E.g. “Start at the left to get general information, move to the right to get additional information.”  The choice of direction can, in some cases, be influenced by right-to-left (RTL) writing systems.  Also, there may be times where keeping the same relationship direction may be unavoidable or even desirable, like for toolbar sections surrounding a central content section.  One example might be a photo editor or painting application with toolbars on both sides of the picture or painting.

Let’s look again at Dolphin, this time with a three section layout as in Figure 4.   On the left is the Places panel, the middle the file list and on the right is the Information panel.

Figure 4 - Dolphin, three sections

The layout is similar to Pattern I from Figure 3.  As before the Places panel provides context for and can affect the file list view. With the added Information panel, the file list view now provides context for and can affect the Information panel.

Other three section patterns can get a little more challenging.

Figure 5 - Other Three Section Patterns

In the patterns in Figure 5, each section is adjacent to two other sections, which means there are potentially two relationships to figure out per section.  If adjacent sections potentially  have bidirectional relationships then there are up to six potential relationships between sections for any of these layout patterns.  Again, this does not mean it is impossible to create a successful design with these patterns.  (I confess that the Dolphin layout in Figure 2 may actually be more similar Pattern I here but I’ll get back to this in a little). Convention can assist the user in making a decent guess about these sectional relationships.  But sometimes the convention the designer is appealing to may not be one the user is familiar with.  That can be one of the weaknesses of relying solely on convention, especially conventions based of poor precedents.

Of course, it gets even more challenging as we add more sections.

Figure 6 - Four Section Patterns

So how do we handle more complex patterns that can sometimes be necessary as applications become more complex and full featured?  One way is by embedding layout patterns or subsections into each section, as in Figure 7.

Figure 7 - Embedded Two Section Patterns

Using grouping elements (whitespace, color, framing, etc.) to provide strong, unambiguous visual hints for each section, the user can easily identify and deal with a collection of sections as one section. This can be helpful since, it reduces the number of sectional relationships the user has to figure out.  For a successful design that uses Pattern I of Figure 7, the user would only need to identify the relationship between section 1 and 2 and, where necessary, between section A and B within section 2. Compare to Pattern III from Figure 5, where the user may need to figure out the relationships between all three sections.

Now let’s look at Dolphin again. So I cheated a bit earlier since I basically ignored the menu and toolbar. If you consider them, then the layout pattern is actually similar to both Pattern I in Figure 5 and Pattern II in Figure 7.  However, due both to very strong convention (how menus and toolbars are used in most apps) as well as whitespace and framing, I think most users consider the menu and toolbar as one section – a kind of header – and the lower portion as another section containing the Places panel and file list view (and Information panel if present). In that sense the Dolphin layout pattern is more like Pattern II here. If you look even closer at Dolphin, you’ll see that the file list view area actually contains another three section pattern with the breadcrumb section on top, the list view in the middle section and the status and zoom controls in the lower section. There, even more so, most of the information and interaction relationships are strictly between those subsections with little-to-no outward relationships to top level sections.

Since I’m most familiar with Bangarang, I’ll talk a little about how what has been mentioned so far influenced the current UI design. The top-level application layout pattern is basically a two section pattern (Pattern D from Figure 1). Embedded section patterns/subsections are used in many places to minimize the number of sections at each level. The intent was to keep the application looking relatively simple and easy to scan and interact with.

Figure 8 - Bangarang Now Playing

The Now Playing view has an upper and lower section. The lower section contains mostly playback controls as well as a control to get to the Media Lists View. When the playlist is visible, as shown in Figure 8, the upper section contains two subsections – the now playing art/info and the playlist view.   Color is used to create a relatively strong visual hint for the upper section and its contents and to distinguish it from the lower section.

Quick note: It took some trial and error to settle on the final contents of the lower section.  One decision was to put the Shuffle and Repeat controls in the header subsection of the playlist view instead of in the lower section beside the full screen control.  A survey of several media player UI designs uncovered a split between designs that consider Shuffle and Repeat to be player properties (like fullscreen) and designs that consider them to be playlist properties.  For several reasons, including the desire to minimize the number elements in this lower section, I chose the latter. We end up with less elements in the lower section for the user to scan, and the new placement of Shuffle and Repeat took advantage of the existing relationship between the playlist view header (which at that point in the design process already contained the Clear Playlist control) and the playlist contents.

Figure 9 - Bangarang Media Lists

The Media Lists view has an upper section and a lower section as shown in Figure 9.  A little white space as well as vertical alignment of the framing elements of the upper section help to define both the upper and the lower sections.  Additionally the lower section has the same height as the lower section of the Now Playing view which helps reinforce it as a separate section with some persistence and visual weight. Another result of this lower section height is that the upper section in the Media List view “replaces” the upper section from the Now Playing view when switching between the two views. These help maintain the application layout pattern and keeps a conceptual connection between Media Lists view and the Now Playing view even though they look quite different.

The upper section itself contains two subsections: the Media Lists selection on the left and media list contents on the right. The “Media Lists” title – same text and font-weight as the control in the Now Playing view that the user clicked to get here – along with the surrounding white space serves as an anchor that establishes the left section as the starting point in the visual hierarchy. Early on in the design, one attempt at this title included placing it at a top-center location.  Another attempt included just setting the window text title to say “Media Lists”.  But, in neither case did the text actually provide much additional meaning or value (there’s that Information Value term again..). When it was moved its current location it started to make much more sense for reasons mentioned above.

Strong grouping elements (framing and color) are used to define the media list contents section on the right, which itself also has two subsections containing the list view on the left and the Info View on the right (you could also consider the header another section which helps reinforce the section as a whole).  The autoFillBackground property is purposefully turned on for the header of the media list contents so that the window background gradient doesn’t continue into the section. The background color in the Info View section was purposefully altered to use the view background color from the palette (to match the list view) instead of the window background color.

The relationship between the upper and lower sections of the Media Lists view is bidirectional. Because of the relatively high information density in the upper section, the lower section was kept relatively sparse, which minimizes the amount of information needed to understand the purpose of this section and its relationship to the upper section. In the upper section, the direction of the sectional relationships are maintained even within subsections. So the Media Lists selection section on the left provides context for and can affect the media list contents section on the right. The search field was placed in this left section instead of somewhere else in the interface since performing a search is just another way to affect the media list contents – one less sectional relationship the user has to figure out. Additionally, within the media list contents section, the list provides context for and can affect the Info View to its right.

The above discussion is not meant to imply there’s no room for improvement or that we got it all “right”. We are always looking for ways to improve Bangarang’s design.

Below are some other applications screenshots I found around the web.  What do you think are the application layout patterns, embedded patterns/subsections and sectional relationships? (Of course, it’ll be tougher to figure out interaction relationships if you’re not familiar with the application.) If you think there are deficiencies, how would you improve them?

Pages

KWord

iTunes

Outlook 2003

Take a look at your favorite application, desktop environment or website and see if you can identify the layout patterns, embedded patterns/subsections and sectional relationships. Mobile applications have fairly tight restrictions on space so careful attention is paid to layouts in the design process.  The transition from mobile to tablet applications gives designers a little more room to work with, but generally not quite as much as desktop applications.  Desktop applications have even more room, but there are limits since they do have to share the desktop space with other applications. There are likely are many, many lessons that us desktop application designers can learn from mobile and tablet application designs, especially in the area of layouts.  The desktop environment of course can use the entire screen.Websites tend to have less constraints vertically than they do horizontally, but even here some restraint can be a merciful relief for users.

Conclusion

So after all that yammering (geez ,I’m long-winded), here are some of my suggestions for my fellow hobby hackers. When laying out your UI, consider the following:

• Basic concepts from the first entry in the series. Remember to identify the use-cases and keep in mind the concepts of Information Value and Interaction Impulse.
• The number of top level sections. The fewer the better.
• Section contents. Try to ensure elements in each top level section have high enough Information Values to serve the primary use-cases of your application and to help direct the user to the starting point in the visual hierarchy.  Avoid dumping elements into top level sections that only serve obscure use-cases, or that are better functionally located elsewhere  - use other discovery mechanisms (menus, stacks, toggles, tabs, etc.) to reveal additional functionality. Also, avoid dumping functionally unrelated elements into the same section.
• The relationship between sections.  Unidirectional relationships are generally easier on the user than bidirectional relationships. Try not to force the user to re-examine a section they’ve already scanned. Use embedded layout patterns or subsections to minimize the number of relationships. Try to provide elements with a relatively high Information Value across sections to help the user quickly understand the “provides context for” relationships. If a primary use-case for your design requires user interaction in one section that “can affect” another section, provide the minimum elements with relatively high Interaction Impulse necessary to help the user quickly understand these relationships.

As with most design, you are just as likely to stumble into a solution before you understand why it works, as you are to understand what will work before you craft a solution.  For Bangarang, so far, it has been about 50-50, and many decisions are rarely absolutely “right” or “wrong”. What matters, for me at least, is coming to some kind of understanding of why a solution works.  And for this geek, that’s been a lot of fun!

Hope you find this helpful!