The Tech Connection

Peter Wilkerson

 by  Peter Wilkerson, Search & Discovery Practice Area Manager

Part 1. Understanding the Coming Problem

The primary goal of a mobile site or app is to deliver the right content in bite-sized chunks to the right person. Understanding the problem and exploring different options will establish a good foundation for understanding why a well-designed Mobile Search Interface is required and why it isn’t enough to just have a search bar.

Content Navigation Patterns

Top Category Navigation Pattern

First, not having advanced navigation isn’t always a problem. If the volume and variety of content available is small enough, a user can easily navigate a handful of top categories and quickly scroll through lists. Depending on a brief list of top categories is a time-honored approach that works well in many cases. However, if the volume and variety of content is larger than this “Top Category Navigation Pattern” can manage, you have frustrated users. Frustrated users mean people who are going to search for alternate sources to find the information needed. A retailer ought to panic at this idea. After all, if their customers can’t find it, they won’t buy it from your site – but they will go to a competitor’s site. Within an enterprise, staff will look elsewhere for the information. That can have disastrous consequences as well.

Hierarchical Navigation Pattern

What is going on? As a site grows content is being grouped together into increasingly larger chunks. The user is now choking on what were once “bite-sized” chunks of content. In their frustration they look for other sources. The solution is to make content “bite-sized” again. A way to do this is to extend the “Top Category Navigation Pattern” (described above) and divide the Top Categories into sub-categories. This “Hierarchical Navigation Pattern” now presents content in bite-sized chunks again.

 As a side bar, there is often confusion between talking about content navigation patterns and web widgets and techniques used to implement the patterns. For example, the Top Category Navigation and Hierarchical Navigation content patterns can be implemented using a variety of techniques and web widgets. A site might use Horizontal or Vertical Bars with a secondary Sidebar Navigation, Tabs Navigation, Breadcrumb Navigation, Tags Navigation, Fly-Out Menu and Drop-Down Menu Navigation. At the end of the day all these patterns are different ways of implementing the Top Category and Hierarchical Content Navigation Patterns.

For more on mobile widgets and techniques for implementing the Content Navigation Patterns, see the Android [Design] Patterns page . If you want to see similar patterns for web sites check out this page .

Where’s Waldo or Stump the User Game

If you have ever designed a web site’s navigation, you know what comes next. As the volume and variety of content continues to increase, you have to add a combination of top categories and sub-categories so you can present content in bite-sized chunks. At some point, the number of top categories and sub-categories get so large that your users are overwhelmed with all the choices they have to make and their frustration level increases and the site’s success criteria decreases. One of the symptoms is that people have to jump through the hierarchy as riding a pogo stick. They have to navigate through a hierarchy to see if it contains the content they are seeking. If not, they try a different path until they either find what they are looking for or give up. If it weren’t so frustrating, this could almost be a game of “Where’s Waldo?” on your site. Usually users feel as if they are involuntary guests on the game show “Stump the user.”

Guided Facet Navigation Pattern

To avoid the Navigational Pogo Game (aka Stump the User) sites turn to a different Navigation Design pattern: Guided Facet Navigation. Often encountered on retail sites, the pattern can be found on company intranet websites (but not as frequently since access to those sites require passwords). Instead of presenting users with a pre-determined navigational path (as required by Top Category and Hierarchical Navigation patterns), this pattern permits the user to choose a path that makes the most sense to them. This approach is often implemented using a search engine under the covers. An excellent example of this approach is found at Littleton Coin.  Select one of the Top Categories along the top (such as Half Dollars) and the next page shows an example of the Guided Facet Navigation in action.

The Coming Problem for Mobile Devices

A design goal for any mobile app is to get the most relevant content to the user as quickly as possible. We just thought we had to be quick using a desktop web browser. With Mobile Apps and Browsers we have to be even more responsive. Many sites today are depending heavily on various implementations of the Top Navigation and Hierarchical Content Navigation patterns using a combination of toolbars, tabs and lists. Some have developed outstanding implementations. Two of my current favorites are the Amazon app store and the BBC new app – both for Android phones. I find that they are easy to navigate and get me to content quickly. However, they only present a sliver of what they will need or could present in the future. The BBC site is already there. There is far more available via the website than the mobile app. One explanation is that mobile users only want a subset of content rather than all the content.

I predict that this design approach of making only a subset of content accessible is going to be the heart the problem. Users are not going to be satisfied with only a subset of content available through their computer browsers. Adding more and more categories to maintain bite-sized chunks of content will not solve the problem.

The only approach that I see that will meet the needs of users without overwhelming them will be an implementation of the Guided Facet Navigation Pattern. However we won’t be able to easily port the implementation approach taken by many retail sites today. Today users are presented with multiple facets from which to choose. There simply isn’t enough screen real estate on a mobile phone to do that. A different design implementation and user interaction pattern will have to emerge to solve this problem – and that is the problem I will be discussing through this series: How to Build a Successful Mobile Search Interface.

You’ll be able to follow this series through our monthly eNewsletter as well as via our blog The Tech Connection . It’s designed to not only educate but to begin a dialogue related to the fulfilling the demand for effective mobile accessibility.

———————————————————————————————————————————————————————————————-
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth Jarvis and request to be added to our E-Newsletter list. Thank you!

Dave Jacob

 by Dave Jacob, Managing Partner, WebSphere Practice 

 December 20, 2005. It’s the day IBM announced the acquisition of Bowstreet and Davalen started down the path of retooling our Domino staff to IBM Web Experience Factory (or Portlet Factory as it was called in those days).

 Davalen had already seen revenue and opportunities for Domino developers maturing and we were quickly moving into the Java space to sharpen our skills and continue to grow. For many Domino developers, the leap to Java was large and not nearly as intuitive as Lotus Designer.

Enter IBM WebSphere Portlet Factory (WPF).  

Originally, we saw a faster opportunity for the Domino community to retool and expand its reach than going down the classic Java path. We were right about the market but wrong about the Domino developer shift other than at Davalen. For some reason, Domino developers continue to lament the demise of Domino and its opportunities instead of leveraging what they know to move into the next paradigm shift.

Welcome to IBM Web Experience Factory (WEF) - where @functions are replaced by builders which link together to build applications, sound familiar?

With the latest release of WEF and its support for mobile devices and rapid web application development, opportunity is exploding.

  Are you awake yet?

You’re six years late but still on the front end of the curve. Davalen is at full employment and experiencing rapid growth thanks to WEF and will be hiring and training many of you willing to make the shift. You’re welcome.

Whether you want to join Davalen or just improve your career options, join the WEF club!

———————————————————————————————————————————————————————————————-
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth Jarvis and request to be added to our E-Newsletter list. Thank you!

Dave Jacob

by  Dave Jacob, Managing Partner, WebSphere Practice

For this month, I would like to repost a LinkedIn article from Adam Ginsberg, IBM who is responsible for both Web Experience Factory (Portlet Factory) and RAD Portal Toolkit. It gives some insight into when to use various IBM tools as well as the advantages of Portlet Factory for supporting a plethora of mobile devices quickly with a minimum (none) of hand coding.

“Our goal is to make the development of exceptional web experiences as easy as possible for the largest group of developers. In the market place there are many different development technologies and approaches preferred, almost religiously, by different developers including Java Developers, .NET/C#, PHP, Ruby, Scala etc. Even grouping Java developers together is really hard with all the different approaches, tooling and frameworks preferred by different developers. For example, Java developers need to choose between tooling and frameworks like Spring, JSF, Struts, DOJO to name a few.

So from my perspective, with intent to be as open as possible, it probably makes sense to group developers looking at delivering exceptional web experiences via a WebSphere Portal platform into 3 key categories:

Type 1: Enterprise Java developers who are coder-naughts by trade and prefer a traditional enterprise Java development approach, and while there may be tooling, you ultimately dealing with lines of Java code. We provide tooling like RAD Portal Toolkit, but as mentioned above there are definitely groups of developers who prefer or have been instructed (via enterprise edict) to use other Java development tools. At the end of the day we keep them whole by the ability to “house” standard based JSR168, JSR286, WSRP based portlets, regardless of the development platform used.

Type 2: Agnostic coders – this group of developers, have strong understanding of development principles, but may not have deep J2EE skills. Note this includes Type #1, J2EE Developers and many other types of developers like .NET developers who can use a MODEL based development tool like Web Experience Factory to develop sophisticated solutions, without a lot of hand coding or need to get into the weeds of specific tooling. Sure, there’s an extension point if you do know Java, but it’s really not required for development of solutions. Another attraction point is the out of the box builders to connect to many different types of back-ends, like SAP, Domino and Oracle PeopleSoft without needing to know the ins and outs of those platforms.

Type 3: The traditional web developer who’s not going to get caught up in building of enterprise applications. They would prefer to use their web development platform of choice, and would perhaps be happy to wrap it up as an iWidget for including in a portal driven exceptional web experience.

From speaking to customers and partners I find that organizations who are Type 1 will tend to stick to the traditional development tooling, and they are privileged to have a strong pool of deep java developers. That said there is a super-set of developers (i.e. including Type 1, 2 &3) who can use a model-based tool like Web Experience Factory to develop and extend out of the box functionality.

So, with the intent to reach a larger audience and skill set of developers we continue to provide strong investment in Web Experience Factory.

At IBM we also tend to use it for internal development projects like our Unified Task Portlet, IBM Connections Portlets, our IBM Industry Toolboxes for WebSphere Portal. Key reasons include:

1. For ease of development and
2. To allow a broader audience of developers to be able to modify and extend out of the box solutions, if needed.

We also find that model-based approach of Web Experience Factory with “builders” make it very easy to:

1. Explain to developers what’s happening within a specific bit of code. If you look at a wizard-like interface and don’t have to reverse engineer code. This improves the learning curve and maintainability of solutions.
2. Maximize re-use – using models and builders, with predefined patterns helps maximize re-use of common assets across teams and projects.

Note, we currently invest just as strongly in RAD Portal Toolkit, but we just don’t have the luxury of developing all our out of the box capability in both Web Experience Factory and RAD. As above, we’ve chosen Web Experience Factory.

Additionally, I would strongly recommend that organizations that are looking to leverage Web Experience Factory invest in skilling their developers correctly with training from IBM or via our partners, like you would any other development platform. I would also encourage engaging with IBM services or a partner on the first project, at least from a mentoring perspective, to ensure you build up the necessary skills for successful project.”

See the original posts and comments as well as add your own questions and thoughts here. 

———————————————————————————————————————————————————————————————-
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth Jarvis and request to be added to our E-Newsletter list. Thank you!

Peter Wilkerson

by Peter Wilkerson , Search & Discovery Practice Area Manager

Companies are capitalizing on the dramatic upswing of the use of iPhones(r), iPads(r), Andriod(r) phones, smart phones and other mobile devices. IBM has recently updated their portal development tool IBM Web Experience Factory (previously IBM WebSphere Portlet Factory) to include a new set of mobile-optimized automation components to help developers construct mobile applications.

While some companies are depending on the ability of mobile devices to zoom in and out on their website, the companies making the biggest inroads are taking a more proactive approach.

In a nutshell this means that they are keeping the following points in mind:

* Communicating within the context of user mobility
Smart phone users are often not sitting at a desk focusing only on their phone. They are walking. They are talking. They might be talking on the phone while looking for information to answer their customer’s questions. They are likely to have short attention spans as they hail a taxi, board a flight, order lunch, or avoid being run over by somebody else talking on their cell phone.

* Mobile devices can report data as well as consume data
If the user chooses (privacy is important), a smart phone can relay significant contextual data about their location and the time of day. You’ve probably already seen examples of how restaurants, theaters, hotels and the like make use of this information. This information can also be used to identify nearby colleagues and customers.

* Choosing to Mobilize rather than Miniaturize
As I mentioned earlier some sites are depending on zoom in/zoom out functions to view websites. But really — who wants to zoom into a page with multiple portlets and have to move around a page to piece together what they need to know? iPad(r) users don’t have it so bad because of the size of their screens. The rest of us aren’t so lucky. Additionally, choosing to design for mobile doesn’t necessarily mean breaking all the pieces of a page into their own separate pages. You have to get to those pieces and guiding users intelligently to those pieces can be the difference between a successful or unsuccessful site.

* Prioritize content
One way to get users to the right pieces is to prioritize content. It’s not important to have everything. What is important is make the right things accessible. One of the first things to keep in mind is this question: Who is the customer of your mobile site? The more you understand who your customer is, what his needs are, what decisions she is responsible for making, what tasks need to be completed — the more you can make sure you are getting the right information in front of your customer.

Once you know who your customer is, you can decide how you want to build the paths for that person to follow to get to the info. Two common patterns are: Navigational and Search patterns

A site using the Navigational Model (in a mobile context) often has a hierarchical structure of topics which a user selects to navigate, much like navigation on a web page except a mobile setting may have only two or three tabs with a limited set of choices underneath. This model tends to work well when you are not supporting many different types of users and when the information is only a couple of clicks away.

However, we live in the age of data sprawl. In an enterprise setting there might be many, many different users to be supported and data is never only a couple of clicks away.

A mobile site using a Search Model will often have a search bar near the top along with a list of top categories. On some sites if you select a category you start down a path very similar to the Navigational Model. In other cases, your selection is entered as a search filter and the user sees a list of documents and can refine their search further with various choices. What you don’t often see is a more advanced search page that you find on websites. There just isn’t the screen real estate to support it.

There is a third model that would be useful for enterprise portals. For now I am calling it “Community Context-Driven Search.” The idea is not new but I have not seen it be applied to mobile devices. Every employee of a company can be described in terms of one more “communities of users.” The basic concept is that the search behaviors of communities of users are tracked. Two pieces of information would be tracked: a) Popular documents based on user ratings and b) the repositories in which popular documents are found. There would also be a mechanism for administrators to assign popular documents and repositories to different user groups based on input from subject matter experts.

This is how I see it working in a mobile context: A user would see a search bar along the top with a list of user communities below. They could enter a search term and get the “world” or they could select a user community. (If authentication is required for access to a site, users could be assigned a user community.) The result is that they would see documents relevant for the type of work they do based on the input of other users and subject matter experts.

In other words, they would get to the information needed quicker and more dependably. If you are on a phone call, looking for information to answer a client’s questions that could be the difference between closing a deal or losing it.

Now seems like a good time to repeat my tag line: “Search IS the Portal.”

In a time when mobile devices are taking off search is an obvious choice for solving the problem of how to get users to the right data quickly.

What do you see as your biggest needs for designing a mobile site? Email me at pwilkerson@davalen.com and let me know. Your feedback, thoughts, and questions will inspire me to write more.

Oh, and by the way, you can also contact me at the same email if you would like to have a more in-depth discussion about some of the challenges for designing a mobile site’s flow for your company.