Surface Computing offers some interesting challenges for software designers when trying to adapt even the most typical desktop or web usage scenarios onto the table. One such example is searching and filtering data. This may seem a silly topic of reflection as search on the desktop is so ubiquitous. However, the anatomy of a desktop search application is inherently incompatible with a true Surface experience.
That’s because search on the desktop is fundamentally an introverted activity. Search applications hardly even make an effort to share what you’ve found with others. Search is just not social. That’s not fair, the current interaction metaphors that we use to search are not social. So how do we make search social?
I approached the problem this way:
1) Make the content autonomous
2) Un-tether the search navigation
3) Provide shortcuts to common search use cases through visual indicators
When building a Surface experience you need to make sure that the content and navigation are accessible to everyone at the table. This can be done in a number of ways. One of my favorite ways of doing this is taking advantage of the ScatterView control to create floating content and navigation tokens.
For the floating navigation, it’s nice to make it collapse-able so that if the users want to focus solely on the content they can push it off to the side and not have it interfering with what they are doing. It should be very apparent that the navigation is very different from the content elements themselves. You can use shape, color, or animation to differentiate the navigation elements from the content.
In my search example I have created three search short cuts for common search use cases that enable the users to find customers with 1) upcoming renewals, 2) recent claims on the policy, and 3) recent customer call-in. The toggle buttons that wrap themselves around the Search text field enable the users to quickly find all the customers that belong to this category.
Finally, the users can further refine their search using the text search. This will cause a Value Converter to be fired to update the opacity based on the customer’s inclusion in the search results.
This is a very simple example of how we can enable new business processes within the enterprise to take advantage of social software that facilitates better teaming within organizations.
Lastly, I will leave you with a list of possible enhancements that could be implemented to improve this solution. This is where I get to play devil’s advocate on my designs. 🙂
1) The UI metaphor does not scale very well. The ScatterView approach does not solve this problem if we were perusing 5000 customers simultaneously. It enables us to browse an already small sample size of a population. On solution to this might be a better use of ScatterView within a “Time Machine” view so that there are multiple ScatterViews that can be navigated through a timeline control to show different content on its effective date. While, this approach might give us some inroads on temporally bound data we would need to come up with alternative approach for outlier cases.
2) Using the border as the visual indication method is effective if the category search is modal (meaning only one category can be toggled at a time). If we wanted to enable the users to see more complex mappings of the data such as which customers have had recent claims AND have upcoming renewals it might get noisy to the eye if we just add additional borders. Especially as the quantity of search categories increases this problem would be exacerbated.
3) The opacity filter has a profound effect but could cause the disruption of other users exploring content when one user decides to conduct a name search. You could see how this plays out in qualitative user trials to see how big of a problem it is or you could select a different visual indicator for text-based filtering.