7

The Need

Our application has a chat feature that allows our users to chat with other users within their database.

However, we're adding a feature that allows clients to share data between multiple databases as an "Enterprise" configuration, and we've been asked to update the design of the chat feature to allow users to chat with other users within any of those databases.

We've looked at the numbers of possible users in these scenarios, and the number of chat users in these shared database environments can be as many as 5,000.

Users need to be able find people they need to chat with out of these thousands of contacts. However, up til now, we've had a list of contacts the users can browse. Since that is a user expectation, we were hoping to still maintain a browse-able list of contacts. We have ruled out trying to display a list of 5,000 contacts, as this doesn't seem to be anywhere close to useful or usable.

We've come up with three approaches to solve the problem:

Option One

Show a list of contacts from the local database that user's can browse. Have a second tab that allows users to search the "Full Directory", returning results from multiple databases.

enter image description here

Pros:

  • Allows us to show a browse-able list of relevant contacts
  • Clearly indicates to users that another source of chat contacts are available

Cons:

  • Search would be limited to the current tab, meaning users would have to be in the right tab to return the right result
  • Adds a possible source of user confusion: whats the difference between "contacts" and the "full directory"?
  • Adds another tab to what should be a simple chat list

Option Two

Show a list of contacts from the user's local database, but if they search for a contact, include results from other databases as well.

enter image description here

Pros:

  • Maintains a list of contacts the user can browse
  • Avoids adding adding another tab
  • One search field searches all sources

Cons:

  • Searching a finite contact list and returning results that weren't in the contact list may defy user's mental model of how the search will work.
  • Not clear that another source of contacts exist. May need to add explanatory text that says "Search to see contacts from the full directory".

Option Three

Add a dropdown that allows a user to select a what to search in: the local database, or the full directory.

enter image description here

Pros:

  • No additional tab required
  • Indicates to users that another source of chat contacts are available, though not as clearly as option 1

Cons:

  • Search still isn't universal: the right search category must be selected to return the right result
  • Users may not notice the dropdown or understand intuitively what its function is. May require explanatory text in search results, reminding the user they can expand the search to the full directory

Thoughts?

Right now I'm leaning towards option two, but is there another option I'm not considering here? Is there another alternative worth considering?

Thanks!

4 Answers 4

1

I would recommend implementing an autofilter search box with match-highlighting and checkboxes for directory/database filters:

enter image description here

You could have the filter automatically update the list of contacts displayed in case someone typed a name and forgot to select a directory or selected the wrong directory. It will prevent them from having to redo the name entry action.

I leave the technical challenge to you :)

0

personally I would go for Option 2 - initially limiting the number of results per area (to for e.g. 5) but adding a link next to the area (or at the bottom) that says something like "... see more" which would then limit the result to the specified area.

3
  • Thanks for the response Leon. Are you suggesting the initial results limit to make sure users see there are results for both sections?
    – FreedomMan
    Jun 23, 2016 at 12:39
  • exactly - that way the user can see everything without having to filter ahead of time which usually just adds complexity.
    – Leon
    Jun 27, 2016 at 19:13
  • @whoever downgraded - at least add your own feedback to make this a constructive (negative) score :(
    – Leon
    Jun 27, 2016 at 19:16
0

With 5000+ contacts you'll want additional filtering control. Depending on culture and country, lots of people can have First and Last names that are similar.

How about:

[First name] [Last name]

[Directory]

5
  • Tom, can you expand on what your suggestion? Are you suggesting individual searches for first and last name?
    – FreedomMan
    Jun 23, 2016 at 19:27
  • Correct! Outlook also does it like this with their advanced search.
    – Tom.K
    Jun 24, 2016 at 8:50
  • Tom, thanks for the clarification. What is the advantage of two fields over one field that can accept first, last, or both names as a search query? I'm assuming that its technically easier, but is it just to more precisely match results? And, since I don't the ability to user test this, what is your instinct on how the additional field weighs against the perceived increased complexity of the search control?
    – FreedomMan
    Jun 27, 2016 at 4:11
  • The filtering reduces the amount of potential useless results. If you know the last-name is Charles, you don't want people with the first name Charles (and without last-name Charles). it's about making sure the user receives relevant information, and avoiding giving them information we know they're not looking for. In a database of 5000+ it can be daunting to find that one person you are looking for. As such, removing any unwanted data and frustration can improve the user experience.
    – Tom.K
    Jun 27, 2016 at 6:53
  • 1
    Solid feedback, thanks Tom. I'll bring this up with my team.
    – FreedomMan
    Jul 5, 2016 at 17:04
0

Option 2 seems to be the best. If finding the right person is important, regardless of what network the person is in, you would remove the separation and let search rank do its job. You could than still mark the each find along with its network name(s). i.e. "Ann Harvey (line break) Network Name [small text]" This way you can handle the duplicates when a find belongs to more than one network. If finding the right person in the same network is more important than I would again give those finds some weight (in the algorithm) to move them up in the list.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.