Rules In-Depth

Timing's rules system is very powerful, but it can also be a bit overwhelming to beginners.
This article covers everything you need to know to create sophisticated rules.

What are Rules?

Rules are Timing's way of automatically determining what projects and filters an app activity belongs to.
They are applied differently for projects and filters:

  • Project rules are applied once a new app activity has been tracked:
    After Timing has recorded a new app activity, it will go through all projects and check if the project's rule matches the app activity.
    The app activity will then be assigned to the first project with a matching rule.
    In particular, changing a project's rule does not affect any app activities tracked so far
    it will only apply to new app activities tracked from now on.
    Have a look at this article on how the order of project rules is determined.
  • Filter rules are applied whenever they are selected:
    When you select a filter in Timing's filter list, Timing will go through all app activities it is currently displaying and only keep the ones that match the filter's rules.
    In particular, the filter's rule applies to all app activities Timing has tracked — not just new ones.

There are two main reasons why project rules can not be applied retroactively:

  1. Projects also let you manually re-assign past activities for refinement. This would be nearly impossible if those re-assignments conflicted with some rules.
  2. Activities can only be assigned to one project at a time, to make projects act as "buckets". This would be nearly impossible to realize if rules also applied retroactively.

Another big difference between projects and filters is that an activity can only be assigned to at most a single project, but multiple filters (i.e. filters can overlap).
See this article for details.
Note that rules always only apply to app activities, not tasks.

Editing Rules

With that out of the way, how can we create or edit a project's (or filter's) rule?
The easiest way to add a rule is simply by ⌥-dragging an element from the Review screen onto the project/filter (see this article).
Often, simply adding a few keywords or domains as a rule will go a long way towards categorizing your activities.

In case you do need to add more complex rules or edit an existing one, double-click the project/filter to edit it, then click the triangle next to "Rule Editor": Wow, quite a lot!
We'll now go through all possible rule types one by one.

Compound Rules

At the root of a project's rule is always a compound rule.
Those rules consist of several subrules, and they match either when at least one (Any) or all of their subrules match, depending on the rule type.
In most cases, the root rule will be of the "Any" type to allow matching by several different subrules.
If you need to create a nested sub-rule (e.g. title contains x AND title contains y), hold ⌥ pressed while clicking the + button.

Property Rules

In order to create a useful rule, compound rules are not enough.
We need to apply some criteria to one of the app activity's properties, after all!

Property rules consist of three parts:

  • The property we want to match on. You can select one of the following:
    • Keywords. These are all the keywords extracted from the app activity's title and path (see here).
      Note that keywords are always single lowercase words, so rules like Keywords contain 'foo bar' or Keywords contain 'Foo' will never match.
      If you want to match multiple keywords, use a compound rule like this instead:
    • Domain (e.g timingapp.com). If the activity is about visiting a website, this is the website's domain (see here).
      E.g. for http://timingapp.com/xyz and https://timingapp.com/xyz this would be timingapp.com, while for http://www.timingapp.com/xyz it would be www.timingapp.com.
    • Full Website URL. When visiting a website, the full website URL.
      For e.g. https://www.timingapp.com/xyz?abc this would be the full https://www.timingapp.com/xyz?abc.
    • File Path. When the activity is about viewing or editing a file, this contains the file's path in a normalized fashion, e.g. /Users/daniel/Documents/file.txt
    • Title. The window title or document title Timing extracted for the app activity.
      Depending on the app, this is often just the apps's name, the name of a screen in the app, or the name of the edited document.
    • Path (File or URL). The path Timing extracted for the app activity.
      This also depends on the app and often is a website URL or a file path (see above).
      There are a few special cases — for example, in Mail.app the path represents the mailbox hierarchy the current email is in (which is neither a file path nor a URL, but still a kind of path).
      The keywords, domain, full website URL or file path properties from above are more specific, so it is recommended to use those instead if possible.
    • Application. The application you were using.
  • The relation the property should have to the value we specify.
    The possible relations depend on the property the rule is about — for keywords this can e.g. only be "contain", meaning that one of the app activity's keywords is the word in the text box on the right.
    For string properties, this can be one of the following:
    • is. The property must be identical to the string specified in the text box on the right.
    • begins with. The property must begin with the string specified in the text box on the right.
    • ends with. The property must end with the string specified in the text box on the right.
    • contains. The property must contain the string specified in the text box on the right.
    • is like. The property must match the string specified in the text box on the right.
      ? and * are allowed as wildcard characters, where ? matches exactly one character and * matches zero or more characters.
    • is not. The property must not be identical to the string specified in the text box on the right.
    Note that all string comparisons ignore upper/lowercase and diacritics, so "foo" and "FøÖ" would be considered identical.
    Note that the "Domain" and "Application" properties also have a special "in" relation available. These are for use in the sample projects (to match e.g. the graphics editing applications Timing knows about) and are not recommended for your own use.
  • The value the property should have (or not have, depending on the specified relation).
    In most cases this is simply a string as explained above.
    For the "Application" property you can select which application the rule should match (or not match).

What if an activity would match several rules?

Speaking of conflicts — sometimes an activity might match more than rule.
In that case, Timing will associate the activity with the first matching project it finds.
To determine what's first, there's a pane in Timing's preferences. It lets you change the order in which Timing applies rules.
Newly created projects by default get the highest priority, so they will override the sample projects' rules.

Specific Examples

Can I automatically categorize all time spent reading emails from a particular address?

If you are using Mail.app, this is possible.
Timing categorizes time spent reading in Mail.app as "(Inbox Name) > (Email Folders) > (Sender Address) > (Subject)".
So if you create a "Path contains 'abc@xyz.com'", rule, Timing will automatically assign all time spent reading emails by abc@xyz.com to the corresponding project.
If you would rather like to categorize time for all emails from e.g. xyz.com, use "Path contains '@xyz.com'" instead.
(Please note that this only applies to time spent reading emails, as Mail.app does not provide this kind of information when writing an email.)