Mobile clients and Enterprise Search – What are the Implications?

As we all know the smartphone user base is growing explosively. According to www.statcounter.com, internet access from handheld mobile devices has doubled yearly since 2009 adding up to 8,5 % of all page views globally in January 2012. And mobile users want to be able to do all the same things that they are able to do on their PC. And that includes access to the company’s Enterprise Search solution!

The benefits of the sales force being able to search for vital customer information before a meeting or for field service personnel being able to find documentation quickly are quite obvious. So how can an organization tweak its search solution in order to provide convenient access for the mobile users? And above all, what will it cost?

Well, to answer the last question first: much less than you think. Providing for the mobile user is mainly about creating a new front end/UI. The main bulk of your search solution remains the same; indexing, metadata structure and content publishing, for instance, remain essentially unaffected.

But you do need to provide a quite different UI in order for the user interaction to work smoothly considering the specific characteristics of the mobile client primarily when it comes to screen size/resolution and text input. But the smartphone also has a lot of features that the PC lacks – it is always available and it knows exactly where you are, it always has a camera, microphone, speaker, possibly a magnetometer and accelerometer and of course a touchscreen with motions like pinching and swiping etc. And many of these features can be quite useful as the following examples prove:

Illustration 1. Google Mobile Voice Search on the iPhone. Courtesy of UX Matters, www.uxmatters.com

  • Google Mobile App for iPhone: in this app, the iPhone senses when the phone is lifted towards the ear and hence knows when to listen for a search command. Since the phone also knows where the user is, a search for “restaurant” automatically generates hits with restaurants in your vicinity.
  • Scanning a Barcode or QR-code: scanning a Barcode or QR-code with your phone is another way of entering a search string. An example could be a product in a store where the customer could open a price-search-engine and scan the QR-code of the product and see where the best price is.

As you can see, there are plenty of opportunities for those who want to be creative. But for the most part, the I/O will still be done via the screen. At UX Matters there is a great article by Greg Nudelman describing the considerations when implementing search for mobile clients and suggestions for various design patterns that can be efficient (see http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php). I have included a brief summary below together with illustrations courtesy of UX Matters. But first, some general considerations for mobile clients:

  • Use Javascript code to detect what type of device is accessing your search solution and if it is a mobile client you display the mobile interface.
  • Native App or Mobile Web App: Creating a Mobile Web App is easier and cheaper than creating a native App – for one thing you don’t have to create multiple versions for different OS’s (although you still need to test your solution with different browsers/resolutions). Performance wise there isn’t a big difference between Native Apps and Web Apps and mobile browsers are increasingly gaining access to most of the phones hardware as well.
  • Authentication: SSO for mobile web applications works the same as for desktop browsers.  There are also new solutions currently being launched enabling usage of the company’s existing Active Directory infrastructure. One example is Centrify Directcontrol for Mobile enabling a centralized administration within Active Directory of all device security settings, profiles, certificates and restrictions.
  • Use HTML5 instead of FLASH: iPhones don’t support FLASH but HTML5 is a very capable alternative
  • Testing: How the design looks for different resolutions can be tested through various emulators but it is always recommendable to test on a limited set of real smartphones as well.
  • Access needs to be quick and simple: user interaction is more cumbersome on a phone than on a PC. Normally try to avoid solutions that require more than 3 input actions.
  • Menu navigation: links on the right side are normally used to drill down in the menu hierarchy and left up/towards the home screen
  • Gestures: is a very powerful toolbox that can be used in many different ways to create an efficient UI. For example, use “pinch to show more” if you want to expand the summary information of a specific item in the search hit list or “swipe” to expose the metadata (or whatever action you want to assign to that gesture).
  • Be creative: the mobile client is inherently different from a PC, limited in some ways but more powerful in others. So if you just try to adopt design solutions from the PC and fit them into a mobile UI you are missing out on a lot of powerful design solutions that only make sense on a mobile client and you are definitely not giving the users the best possible search experience. Also, since mobile design is still evolving you don’t need to be limited by conventions and expectations as much as on the PC side – make the most of this freedom to be creative!
  • W3C mobile: for more information about mobile web development, see http://www.w3.org/Mobile/ which also includes a validating scheme to assess the readiness of content for the mobile web

Design patterns for mobile UI (with courtesy of Greg Nudelman/UX Matters)

Mobile faceting can be tricky but by using design patterns like “4 Corners”, “Modal Overlays”, “Watermarks” and “Teaser Design” the UI can become both intuitive and easy to learn as well as providing reasonably powerful functionality. As mentioned, these techniques are summaries from an article written by Greg Nudelman for UX Matters. If you are eager to learn more, feel free to check out Greg’s website and his upcoming workshops focused on mobile design http://www.designcaffeine.com/category/workshops/

4 Corners: instead of stealing scarce real estate by adding faceting options directly on the screen together with the search result, semitransparent buttons are available in each corner enabling the user to bring up a faceting menu by tapping in a corner (see illustration 2).

Modal Overlays: the modal overlay is displayed on top of the original page. The modal overlay works well together with the 4 corners design – tapping a corner opens up the overlay containing faceting functions like filtering and sorting (see illustration 2).

Illustration 2. Four Corners and Modal Overlay patterns. Courtesy of UX Matters, www.uxmatters.com

Watermarks: a great technique for guiding users and showing the possibility of using new functions. The watermarks, possibly animated, show a symbol for the available action, for instance arrows indicating that a swiping gesture could be used (see illustration 3).

Full-Page Refinement Options Pattern: gives the user plenty of refinement options to choose from (see illustration 3).

Illustration 3. Two variations of the Watermark pattern and a Refinement Options pattern. Courtesy of UX Matters, www.uxmatters.com

Teaser Design: show part of the next available content so that the user is aware that there is more content available (see illustration 4).

Illustration 4. Teaser design pattern facilitates the discovery of faceted search filters. Courtesy of UX Matters, www.uxmatters.com

Persistent Status Bar: always maintain a persistent status bar containing the search string together with applied filters in the search result page. This helps the user maintain orientation. Note that all of the illustrations above have a persistent status bar.

Conclusion

Although Best Practices for mobile UI design are still evolving, plenty of progress has already been made and there are several solutions and design patterns to choose from depending on the specific circumstances at hand. So an implementation project need not be rocket science, as long as you learn the right tricks…

Bringing enterprise information to the field, readily available in a mobile handset or tablet, will mobilize your employees. The UI requires rethinking as we have seen. And security needs to be addressed properly to avoid having sensitive data compromised. But other than that, you are ready to go!

Combining Search and Browse – Integrated Faceted Breadcrumbs

Finding information can be tricky and as I have written about in one of my previous posts improving findability is not about providing a single entrypoint to information. Users have different ways of finding information (browsing, searching and asking). They often combine these techniques with each other (berrypicking) and so they all need to be supported. Peter Morville states that.

“Browse and Search work best in tandem… the best finding interfaces achieve a balance, letting users move fluidly between browsing and searching.”

A lot of sites are improving their search experience through the implementation of faceted search. However, very few successfully integrate faceted search and browsing on their site. Searching and browsing are treated as two separate flows of interaction instead of trying to combine them which would provide the users with a much better experience.

That is why I was glad to learn about an idea from Greg Nudelman which he presented in his session at the IASummit which I attended last week. In his session Greg introduced his idea about Integrated Faceted Breadcrumb. According to him breadcrumbs are intuitive, flexible and resourceful and they are design elements that don’t cause problems but simply work. To test his idea he conducted usability tests on a prototype using the Integrated Faceted Breadcrumb. According to his evaluation the integrated faceted breadcrumb has a lot of advantages over other faceted solutions:

  1. Combine hierarchical Location & Attribute breadcrumbs
  2. Use Change instead of Set-Remove-Set
  3. Automatically retain relevant query information
  4. Label breadcrumb aspects
  5. Make it clear how to start a new search
  6. Allow direct keyword manipulation.

I find this idea interesting and I am currently thinking about whether it could be applied into one of my own projects. (According to Greg it has not been implemented anywhere yet even though the findings from the usability testing were positive.) However I wonder if this is a concept that works well only for sites with relatively homogeneous content or if it would also work on larger collections of sites such as intranets? Can it be used in an intuitive way with a large number of facets and can it cope with the use of more complex filtering functionalities? For some sites it might not be the best idea to keep the search settings when the user changes search terms. These are some things I would like to find out. What do you think about this? Could you apply it to your site(s)? I recommend that you have a look at Greg Nudelman’s presentation on slideshare and find out for yourself. You can also find an article about the Integrated Faceted Breadcrumb on Boxes and Arrows. I look forward to a discussion about whether this is any good so write me a comment here at the findability blog or find me on twitter.

Faceted Search by LinkedIn

My RSS feeds have been buzzing about the LinkedIn faceted search since it was first released from beta in December. So why is the new search at LinkedIn so interesting that people are almost constantly discussing it? I think it’s partly because LinkedIn is a site that is used by most professionals and searching for people is core functionality on LinkedIn. But the search interface on LinkedIn is also a very good example of faceted search.

I decided to have a closer look into their search. The first thing I realized was just how many different kinds of searches there are on LinkedIn. Not only the obvious people search but also, job, news, forum, group, company, address book, answers and reference search. LinkedIn has managed to integrate search so that it’s the natural way of finding information on the site. People search is the most prominent search functionality but not the only one.

I’ve seen several different people search implementations and they often have a tendency to work more or less like phone books. If you know the name you type it and get the number. And if you’re lucky you can also get the name if you only have the number. There is seldom anyway to search for people with a certain competence or from a geographic area. LinkedIn sets a good example of how searching for people could and should work.

LinkedIn has taken careful consideration of their users; What information they are looking for, how they want it presented and how they need to filter searches in order to find the right people. The details that I personally like are the possibility to search within filters for matching options (I worked on a similar solution last year) and how different filters are displayed (or at least in different order) depending on what query the user types. If you want to know more about how the faceted search at LinkedIn was designed, check out the blog post by Sara Alpern.

But LinkedIn is not only interesting because of the good search experience. It’s also interesting from a technical perspective. The LinkedIn search is built on open source so they have developed everything themselves. For those of you interested in the technology behind the new LinkedIn search I recommend “LinkedIn search a look beneath the hood”, by Daniel Tunkelang where he links to a presentation by John Wang search architect at LinkedIn.

Search Driven Portals – Personalizing Search

To stay in the front edge within search technology, Findwise has a focus on research, both in the form of larger research projects and with different thesis projects. Mohammad Shadab and I just finished our thesis work at Findwise, where we have explored an idea of search user interfaces which we call search driven portals. User interfaces are mostly based on analysis of a smaller audience but the final interface is then put in production which targets a much wider range of users. The solution is in many cases static and cannot easily be changed or adapted. With Search driven portals, which is a portlet based UI, the users or administrators can adapt the interface specially designed to fulfill the need for different groups. Developers design and develop several searchlets (portlets powered by search technology), where every searchlet provides a specific functionality such as faceted search, results list, related information etc. Users can then choose to add the searchlets with functionality that suits them into their page on a preferred location. From architectural perspective, searchlets are standalone components independent from each other and are also easy to reuse.

Such functionality includes faceted search which serves as filters to narrow a search. These facets might need to be different based on what kind of role, department or background users have. Developers can create a set of facets and let the users choose the ones that satisfy their needs. Search driven portals is a great tool to make sure that sites don’t get flooded with information as new functionalities are developed. If a new need evolves, or if the provider comes with new ideas, the functionality is put into new searchlets which are deployed into the searchlet library. The administrator can broadcast new functionality to users by putting new searchlets on the master page, which affects every user’s own site. However, the users can still adjust new changes by removing the new functionality provided.

Search driven portals opens new ways of working, both in developer and usage perspective. It is one step away from the one size fits all concept, which many sites is supposed to fulfill. Providers such as Findwise can build a large component library which can be customized into packages for different customers. With help of the searchlet library, web administrators can set up designs for different groups, project managers can set up a project adjusted layout and employees can adjust their site after their own requirements. With search-driven portals, a wider range of users needs can more easily be covered.

Improving Findability – Is your Content Really Available to Users?

Web service award recently issued a press release stating that the web is being flooded in 2008. This flood of information is caused by the demands for availability as well as the users’ demands for finding all information possibly needed, online. So Swedish websites are being flooded with information and navigation and structure aren’t coping with the problem. And so the users can’t find the information… Time to improve findability.

I believe something has been missed here. There is a big difference between just publishing your content online to make it available to users and making it findable. Could you really say your content is available when it’s not findable? When talking about search, I always like to use the quote: “If the user can’t find the information, it’s not there.” You don’t make the information available to users just by publishing it; you also have to make the information findable.

This also has consequences for search. I usually talk about the differences between enterprise search and web search; Enterprise search being more complex with more information sources, more complex information types, where information discovery could be the goal rather than information retrieval. That’s some of the reasons why enterprise search is in need of more complex functionality such as faceted search, categorization or clustering, query suggestion, tunable ranking etc.

Perhaps we have now come so far that “ordinary web search” also is in need of this functionality to get a grip of the vast amount of content available online? At Findwise we see a tendency for our customers to want more functionality in their search applications, in order to add more value for the users of their site.

In the end it all comes down to three questions (asked by Peter Norville in his Google Tech talk)

  • Can our users find our website?
  • Can they find their way around our website?
  • Can they find our product services and information despite our website?

So, making information findable is not about providing a single way of retrieving information. Your site should be able to support several information retrieval models; browsing, searching and asking.