Question about the placement logic of Timeline Events

When viewing timeline events, I'm often perplexed by how/where events are placed on the timeline. As an example, see the screen capture below to see the order of how events in the life of C.S. Lewis appear on the timeline. I would expect that under the blue hi-lited date range of 1898-1963, the events would be in chronological order from top to bottom in the list--i.e. 1917, 1924, 1929, 1931, 1952, 1955, 1955-1963, and 1956 (or possibly reversing the last two).

But instead, the order is 1931, 1929, 1924, 1917, 1955, 1956, 1952, 1955-1963. That's neither in chronological, nor reverse chronological order.

I don't get it! Sad

Find more posts tagged with

Comments

Robert Pupo

Hi Rick,

Don't read the list top to bottom. Read it left to right. The leftmost event is earlier and the rightmost is later. The blue bubbles follows the date timeline across the top. I hope this helps!

Robert Pupo

Rick Ausdahl

https://community.logos.com/discussion/comment/699094#Comment_699094

Hi Rick,

Don't read the list top to bottom. Read it left to right. The leftmost event is earlier and the rightmost is later. The blue bubbles follows the date timeline across the top. I hope this helps!

Robert Pupo

Hi, Robert! Thanks for your reply. Am I'm guessing a "Welcome to the forums" is also in order! [:D]

I realize the timeline works left-to-right, but why not also top to bottom? The norm is that we read left to right and top to bottom. Putting the oldest date at the top and working down to the newest date at the bottom, would still leave the older dates to the left of newer dates as they are now (i.e. no harm, no foul), but would have the added advantage of allowing us to follow our standard top-to-bottom reading flow as well. The way Logos places them on the timeline, to read them chronologically requires you to start reading near the middle of the event cluster and work your way up to the top, then drop back down almost to the bottom and work your way up to the middle, then drop all the way down to the bottom. I don't understand why Logos does that when the entries can just as easily be kept in chronological order while following our normal reading flow of left to right and top-to-bottom.

The way Logos is placing them makes me wonder if the developers think that old adage, "Why make it simple when you can make it complex and wonderful?", is actually a good thing. [;)]

NOTE TO DEVELOPERS: Just a little levity. I think you guys and gals do an awesome job!

Andrew Batishko

https://community.logos.com/discussion/comment/699161#Comment_699161

Unfortunately, simple in this case would not be a great experience. If you were to order all of the events chronologically from top to bottom, then you would end up with a giant stair-step pattern of events. There would be a huge amount of whitespace in the lower-left and upper-right corners. This would make it very awkward to scroll horizontally, because you would also need to keep scrolling up or down in order to see more events. In addition, the timeline tool would need to load in all events in it's database in order to determine how far down to display an event. This would be very slow.

Instead what happens is that events in the visible range are loaded in order using an internal priority number (this is why events about Jesus tend to float to the top). For each event the tool finds the highest position in the timeline where there is room to display the event. As you scroll, additional events get loaded and placed into the current layout without changing the position of events that are already displayed. The end result may not be in priority order, but will be influenced by priority.

In your screenshot, the events are actually showing up in the defined priority order. I'll forward a suggestion for improved prioritization.

Rick Ausdahl

https://community.logos.com/discussion/comment/699172#Comment_699172

Unfortunately, simple in this case would not be a great experience. If you were to order all of the events chronologically from top to bottom, then you would end up with a giant stair-step pattern of events. There would be a huge amount of whitespace in the lower-left and upper-right corners. This would make it very awkward to scroll horizontally, because you would also need to keep scrolling up or down in order to see more events. In addition, the timeline tool would need to load in all events in it's database in order to determine how far down to display an event. This would be very slow.

Instead what happens is that events in the visible range are loaded in order using an internal priority number (this is why events about Jesus tend to float to the top). For each event the tool finds the highest position in the timeline where there is room to display the event. As you scroll, additional events get loaded and placed into the current layout without changing the position of events that are already displayed. The end result may not be in priority order, but will be influenced by priority.

In your screenshot, the events are actually showing up in the defined priority order. I'll forward a suggestion for improved prioritization.

Andrew,

Thank you for weighing in and for providing the perspective (and technical) lessons. Based on the things you pointed out that are involved in the evaluation of how/where to place things (and there are probably other things involved as well), I suspect it would not be the best use of Logos staff time to worry too much about this. Before submitting this thread, I had considered how some of the things you mentioned might come into play if Logos is trying to put everything (including the kitchen sink) on the timeline when little-to-nothing is being filtered out, but I didn't think that need be the case when a very limited number of events (as in my example) are being displayed. I can appreciate though how the algorithms, priority models, and database structures that are needed to pack in all the results of unfiltered timeline displays, could result in what appear to be quirky displays for a heavily filtered timeline such as the one in my example that is displaying relatively few events. So unless it's an easier fix that what I think it would be, please don't worry anyone about it.

Thanks again for the insight!