Timeline chart to show item counts and filter items based on date ranges

[lfcnassif]

It could display a line or bar graph with item/event counts with configurable range and granularity (year, month..., minutes, seconds, milliseconds). User should be able to specify all or some event types (mac times, url access dates, email, message dates, exif dates...). Selected time ranges would filter results displayed in table, gallery and other tabs.

Maybe some refactoring would be needed to create an unified "timestamp" and "event type" columns. Those fields could be multivalued for items with more than one time event (e.g. mac times), that should be enough for event counting and filtering in the new tab. This relates to #35

But not sure if those different events per item would be displayed as different entries in table tab (for sorting and event sequence analysis), that could increase by x4 the number of entries in case in worst scenario. Maybe it could be made configurable at index or analysis time...

[lfcnassif]

possible impl with jfx https://docs.oracle.com/javafx/2/charts/jfxpub-charts.htm

maybe differentiate event types by color

[lfcnassif]

@tc-wleite @fmpfeifer any ideas about the last point of the first comment?

[thalespr]

JFreeChart (LGPL license) can also be a solution.

[thalespr]

Did a prototype using JFreeChart and it worked well. See the image below:

[lfcnassif]

But not sure if those different events per item would be displayed as different entries in table tab (for sorting and event sequence analysis), that could increase by x4 the number of entries in case in worst scenario. Maybe it could be made configurable at index or analysis time...

I had an ideia about this, maybe a button in Table Tab (like the buttons in gallery) to expand/collapse items with multiple timestamps (like MACB) into multiple entries in Table. I "think" it should be fast or at least have acceptable performance using Lucene SortedSetDocValues for the timestamp column. So there will be no need to index 4x the number of items and user can enable it at analysis time and do timestamp sorting on table. Filtering timestamps in the new tab could benefit of this.

[lfcnassif]

Good news, did an initial test and the expand/collapse timestamps in table view took ~110ms in a case with 1mi items, so it will not be a problem for a few million items.

[lfcnassif]

Talking to @patrickdalla, he suggested some frequency filter like all events after business time, at weekends, at specific time ranges per day. That is a good idea to look for patterns.

[lfcnassif]

@patrickdalla I'll assign this to you to let other devs know you are working on this to avoid duplicate efforts, thanks for helping with this!

[patrickdalla]

I think that we could implement the timeline graph that consults a diferent IMultiSearchResult object. This search result would have the same filters, but should be ordered by date, wouldn't have any non dated item, and should be sumarized by event type and the date granularity (by month, week, day, etc.. ) defined on the graph view.
So, the results seen on the table view could not be ordered by date. When the selects an item, the timeline centers on that item, and the user would have two views one that give him a contextual time perspective and other another selected contextual perspective (sorting).
What do you think? Sounds good?

[lfcnassif]

I think that we could implement the timeline graph that consults a diferent IMultiSearchResult object. This search result would have the same filters, but should be ordered by date, wouldn't have any non dated item

That is exactly my idea!

and should be sumarized by event type

I totally agree. Maybe it would be also useful to have an option to plot all events without event type distinction.

I agree on all points, but:

the user would have two views one that give him a contextual time perspective and other another selected contextual perspective (sorting).

This I didn't follow, you mean other table views? Wouldn't be enough to switch the table tab to timeline mode to get a time perspective, keeping the same selected item? I didn't see the selected perspective, could you give an example? I have strong concerns about memory usage to display multiple table views at the same time if you are working on cases with dozens of millions of items listed at the same time. I would try to reuse existing UI components as much as possible.

[patrickdalla]

I chose to implement Timeline in iped-viewers-impl project. But I needed to reuse the class DocValuesUtil that is implemented in iped-engine, which iped-viewers-impl does not depends. Or I do declare this dependency on BuildPath of iped-viewers-impl, or I move the class DocValuesUtil to another more independent project (maybe iped-utils)? It would be good to implement DocValuesUtil in a decoupled way from lucene, as it uses lucene classes on its methods signatures.

For now, I chose the first option, also with lucene dependency added also to iped-viewers-impl pom.xml.

What do you think?

[patrickdalla]

Sorry, but the chosen way didn't work as it created a circular dependency. We have to refactor this class DocValuesUtil.

[patrickdalla]

Another easier option would be implement the timeline graph not in iped-viewers-impl, but in iped-app directly.

[lfcnassif]

I vote for the last option.

[patrickdalla]

Ok. I'll do that.

It depends also on TimeItemID from iped-engine.

[lfcnassif]

DocValuesUtil is very specific for lucene to easy its usage and was not meant as a generic interface. iped-utils should have as few dependencies as possible. And I think iped-viewers shouldn't depend on lucene

[lfcnassif]

TimeItemID

This we can try to move to iped-api

[patrickdalla]

I need some suggestions of options of user interaction and graph syncronization.

1. When a user selects an evidence item in the Table, this item can have multiple timestamps associated. I was thinking in centralizing the timeline graph on the timestamp of the item, without changing graph zoom neither domain granularity options. But if I am not in the timeline view mode, an selected item can have multiple timestamps. Should we define some timestamp priority? If I do not change zoom configuration, it could not be possible to include all the timestamps on the same visualization.

[patrickdalla]

Another: once a filter is defined in timeline chart, it reflect also on the chart itself, that rebuilds accordingly. That how it is being implementend.

but a second option is the chart maintain a separate search result that reflects all the filters except its own filters. This option can be a little more complicated to implement, and, if deemed necessary, should be opened as a new separated Issue.

[patrickdalla]

I also detected an issue that maybe could not be the desired result: when I filter some itens by timestamp interval, the table timeline view shows all the item events of any item that has at least one of the timestamps in the filter interval, even those events that are not in the time stamp interval.

Should I correct this, right?

[lfcnassif]

Sorry @patrickdalla I was working on iped-4.0 release...

1. When a user selects an evidence item in the Table, this item can have multiple timestamps associated. I was thinking in centralizing the timeline graph on the timestamp of the item, without changing graph zoom neither domain granularity options. But if I am not in the timeline view mode, an selected item can have multiple timestamps. Should we define some timestamp priority? If I do not change zoom configuration, it could not be possible to include all the timestamps on the same visualization.

Originally I thought about the opposite workflow: when user selects a timestamp range in timeline tab, it would filter results on table tab. I think your idea could be useful indeed, but I think it just makes sense if the table timeline view is enabled, so you could centralize the timeline chart just in the/one selected timestamp. Maybe we should move/duplicate the "Table Timeline View" switch button into the Timeline Tab, to easy the switching between table views by the user, that could make things more intuitive.

Another: once a filter is defined in timeline chart, it reflect also on the chart itself, that rebuilds accordingly. That how it is being implementend.

Not sure If I understood this. I think the chart shouldn't rebuild automatically, but could have an "Update/Synchronize" button to optionally redraw itself based on the new filtered results on table tab.

but a second option is the chart maintain a separate search result that reflects all the filters except its own filters. This option can be a little more complicated to implement, and, if deemed necessary, should be opened as a new separated Issue.

Hum... and if user selects a wrong date range and would like to change the timestamp range filter? Maybe we should also have a "Clear" button (like the metadata filter panel one) that clears the date range filter and trigger an update table results, so user could apply another date range filter again over the original item set (it will return to table view because previous filters will be applied again, except the cleared date range).

Should I correct this, right?

Hum... I think I remember this behavior, but you are right! Users will expect to view just the timestamps into the selected date range. Please fix, thank you!

I would appreciate a lot if other devs could also give opinions on this important feature. @tc-wleite, @hauck-jvsh, @fmpfeifer, @thalespr?

[lfcnassif]

Closed by #1193