My App Clye has a pretty powerful messaging interface, that allow context sensitive potentially shared notes. This way every user has the correct notes in places whenever he is in any conversation or viewing a page in Clye. However, the application might not be able to guess right what you want to see all the time. This makes some filter functionality necessary.

So lets have a deeper look what the requirements actually are. Every note has some information the user might want to filter after. It can be represented approximately be the following json document:

{
  "id": "unique",
  "about": ["Profile:id", "Call:id", "Page:id"],
  "sharedWith": ["user1", "user2", "Community:id"],
  "author": "user3",
  "createDate": "2018-01-01",
  "updateDate": "2018-01-01",
  "readAt": "2018-01-01",
  "archived": "2018-01-01"
}

So as you can see quite some stuff. In actual use the user might view the page of another user. Now he would expect to see all messages he exchanged with this person, or that originated from this person, and the current user has access too. And of course all messages that are about this person. So the query might look something like:

about=user1 OR author=user1 OR sharedWith=user1

This is enough because no user will be able to see messages not shared with them. This however is probably pared with a filter to not show messages that were archived. So the full query looks more like:

(about=user1 OR author=user1 OR sharedWith=user1) AND !archived

Thats however not where the queries end. If the user is in a Call, all messages with the participating users should be shown. This means the query for a call with a total of 4 participants, excluding you user1, user2 and user3 would result in the following query:

(
  about=user1 OR author=user1 OR sharedWith=user1 OR
  about=user2 OR author=user2 OR sharedWith=user2 OR
  about=user3 OR author=user3 OR sharedWith=user3
) AND !archived

Thats not too complicated, but the interface has some additional constraints it must fit into a single line of a sidebar that is 380px width. So yeah, that is not short enough and maybe not how I would want to present it.

Shortening by abbreviation

Fortunately it can be shortened by introducing some shortcuts. For example to combine about, author and sharedWith into with This allows a much shorter version

(with=user1 OR with=user2 OR with=user3) AND !archived

And it gets even shorter if or is allowed in assignment position:

with=(user1 OR user2 OR user3) AND !archived

That definitely looks more like something that could be shown in a single line of a sidebar. The users could be represented as Avatars and would thus consume extremely little space. The or operator can be replaces by | and the and operator by &. The result is similar to:

with=(😃|😄|😆) & !archived

This starts to look like something that you could reasonably want to put into a small sidebar. With a specific UI it can be made even more compact by replacing the & archived part by a fixed toggle button that displays the archived icon.

In part 2 we will make it a lot more powerful, so stay tuned