Zooming, Context, and Detail: Design Decisions

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Sat Jan 16, 2010 2:13 am Post

grgwrzbcki wrote:I think the challenge you face with timeline & event zooming is that they are discrete and non-linear -- and thereby much closer to the problem of zooming calendars and GPS/maps than zooming A/V apps. While A/V apps lend themselves to straight forward linear scaling of frequency, amplitude, graphics, etc., calendar and GPS/map apps don't.

I don't quite follow this reasoning of linear as opposed to non-linear.

In an A/V app, specifically an audio editor that I chose as an example, there is of course a linear timeline and within that linear timeline are discreet, non-linear events at irregular intervals, such as words spoken that you may want to cut or shift or process. I think it's similar enough to a story timeline that one could be inspired by aspects of, for instance, TwistedWave navigation implementation.

In particular, this may be true of the 'orientation pane', similar to the Context Bar in Event View.

TL044_01.jpg
TL044_01.jpg (39.13 KiB) Viewed 1286 times

The above screen dump, for instance, is confusing to me. There's one event before 1950 and the timescale there is apparently half year intervals. Next is a segment with two year intervals, although that segment also contains just one event. Between 1960 and 1970, there is no event at all. But suddenly, there's an equal scale step comprising only two years, 1970–1972! The result is that the impression of the time frame from Eva's birth to the next event down, where she's 8 years and her marriage, 23 years old, in 1972, is completely distorted.

With my admittedly limited powers of abstract thinking, I couldn't make heads or tails of a representation like that… :shock:

I visualize time as a linear flow, with events at irregular, non-linear, places along that linear timeline.

I think that the screen dump also shows some of the problems with the Context Bar in its current guise. In fact, I haven't quite got my head around how to use it.

First, and very simple to fix, I think the yellow bar may not have enough contrast. I also think it might be a good idea if the cursor would turn to a 'hand' inside the yellow bar, so that you could slide it around without the display jumping to where you happen to click inside it.

Also, it would help if the yellow bar had well defined borders where you could click and drag to contract or expand it without its focus changing.

The TwistedWave 'context bar' should provide a good example of well structured and consistent operation.

One thing that might help, also borrowing from TW and other editors, might be if a selected event in the Time Margin would anchor the display at that spot during zoom in/zoom out.

The more general issues brought up by Matt, I have to think about some more… 8)

Best,

Joachim

User avatar
igregor
Posts: 146
Joined: Tue Dec 30, 2008 2:57 am
Platform: Mac + iOS
Location: Fairfax Station, Virginia, USA

Sat Jan 16, 2010 1:48 pm Post

Spitfire31 wrote:I don't quite follow this reasoning of linear as opposed to non-linear.

In an A/V app, specifically an audio editor that I chose as an example, there is of course a linear timeline and within that linear timeline are discreet, non-linear events at irregular intervals, such as words spoken that you may want to cut or shift or process.


While the word (or note or whatever) in an audio app might be discrete, the waveform that the app uses to represent the word is a simple linear graphic -- and, thus, readily lends itself to linear scaling. The audio app does not actually scale the word itself, but rather the waveform that represents the word. Nowhere in an audio application do you find the words represented by waveforms actually spelled out (written) onto the display.

This is not quite the case for an event in a calendar (or timeline). Calendar apps must represent and scale both the event time (linear) and the words that describe the event (non-linear). If the words that are written onto the display are treated as linear, then scaling them will increase (decrease) the size of the letters representing the words in a way that interferes with their ability to be represented graphically (making them appear too large in some cases, or too small in others). So, the calendar app must confront this non-linear characteristic of the word-as-displayed that the audio app can conveniently ignore. That's why calendar apps offer discrete levels of detail with which users can view them (days, weeks, months, years, etc.). Each level offers a different level of detail which is designed to summarize and scale the words legibly within the viewing area on the monitor/screen.
-- iGregor

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Sun Jan 17, 2010 1:29 pm Post

Thank you, grgwrzbcki, for the clarification! I see what you mean now, but I have to think some more before I can decide for myself if a timeline isn't, after all, something of a halfway house between calendar app and A/V app. ;-)

For one thing, it might perhaps help to set up a few scenarios for how Aeon TL could be used. Currently, I'm not thinking of much more than setting up a chronology in order to check for consistency in character ages and events that have to conform to a cause/effect order. But perhaps it could be used much more ambitiously, as a kind of outlining app, too?

I'd welcome Amber's take on this discussion…

Best,

Joachim

User avatar
igregor
Posts: 146
Joined: Tue Dec 30, 2008 2:57 am
Platform: Mac + iOS
Location: Fairfax Station, Virginia, USA

Sun Jan 17, 2010 2:45 pm Post

Spitfire31 wrote:Thank you, grgwrzbcki, for the clarification!


You are very welcome. It is due to this difficulty in scaling written words that I posted a suggestion last week for Matt to consider something similar to the Apple Dock auto-magnification feature.

Here's one way I envision that such an approach might work:

The user starts by choosing a particular level of detail in which to work -- let's say at the week level. All of the material of immediate relevance (over the past several days, or so) would be scaled to be in the "week" view in such a manner as to be readable along a horizontal time line from left to right. If the user wished to view information in the immediate past or future (last few weeks or months), he/she could easily scroll to it without adjusting the level of detail.

But what if the user wanted to find something in the distant past -- let's say, several years or decades earlier? If he knew the date, then, as with a calendar app, he could enter the date and the relevant time period would come into view immediately. But, what if he was unsure of exactly when the distant event occurred? Finding such an event could quickly become a real pain unless there was some simple way to review all of the events easily and without a whole lot of distraction.

That's where the dock-like auto-magnification feature comes in. Envision a miniature horizontal time line at the bottom of the page/window in which both time and words are scaled to represent the entire sequence of events from start to finish, AND which auto-magnify as scrolled. Voilla! The user is now able to work in the large upper portion of the window at a desired high level of detail, while having easy access to a READABLE representation of events contained in the entire time horizon of his/her story. Further, once an event is located in the miniature time line it could be called into view easily in the upper window, if so desired, for further work/adjustments.

Greg
-- iGregor

ma
matt
Posts: 1180
Joined: Mon Jul 30, 2007 9:35 am

Sun Jan 17, 2010 11:53 pm Post

I think I like your suggestion, but just so we're on the same page... any chance of you creating a mock-up picture of what you are talking about.

My main concern is - I assume you want the magnifier to work on the "Context Bar" - but that would probably still need to take up significantly more space to be able to accomodate tiny and magnified text.

Also, are we talking about Entity View or Story Arc View? And how would it look in the other?

Thanks,
Matt

User avatar
igregor
Posts: 146
Joined: Tue Dec 30, 2008 2:57 am
Platform: Mac + iOS
Location: Fairfax Station, Virginia, USA

Mon Jan 18, 2010 3:23 am Post

matt wrote:any chance of you creating a mock-up picture of what you are talking about.


My illustration skills are about nil. Sorry, but words are about the best I can offer. :(

matt wrote:I assume you want the magnifier to work on the "Context Bar" - but that would probably still need to take up significantly more space to be able to accomodate tiny and magnified text.


I think the Context Bar would be a perfect location in the Entity window. Scrolling the Context Bar could reveal auto-magnified event description "bubbles", instead of only dates as now.

Not sure why more space would be necessary. Might be less, even. As with the Apple Dock a preference could be set to hide the context bar by default, and have it appear only as a graphic overlay on mouse-over.

matt wrote:are we talking about Entity View or Story Arc View?


I think both. Along the left side in Entity view, and along the bottom in Story Arc view.

It occurs to me that -- following the Apple Dock analogy -- the Context Bar could be made independent of either view; with location selectable by the user (left side, bottom, etc.).
-- iGregor

ma
matt
Posts: 1180
Joined: Mon Jul 30, 2007 9:35 am

Tue Jan 19, 2010 11:25 pm Post

I have been thinking about this more, and I agree that I need to take another look at the context bar, and probably add some kind of magnify glass functionality to it (this was actually on my original plan for the context bar, but then I never got around to implementing it).

I think that before I make any changes in this area though, I need to get a clearer idea of how this zooming can work, with regards to the "too much information/only want an overview" issues I was talking about before.

Does anyone have any feedback on having event groups, or event priorities, or another possible mechanism to reduce the number of events to display as you zoom out?

Thanks,
Matt

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Wed Jan 20, 2010 12:52 am Post

grgwrzbcki wrote:… Envision a miniature horizontal time line at the bottom of the page/window in which both time and words are scaled to represent the entire sequence of events from start to finish, AND which auto-magnify as scrolled. Voilla! The user is now able to work in the large upper portion of the window at a desired high level of detail, while having easy access to a READABLE representation of events contained in the entire time horizon of his/her story. Further, once an event is located in the miniature time line it could be called into view easily in the upper window, if so desired, for further work/adjustments.

Greg

Spontaneously (although I've had to think about it for a couple of days), I like Greg's basic idea. The Dock is a clever concept in itself – mine currently helps me keep track of over 70 items.

However, isn't much of the Dock's usefulness due to the fact that it's based on very distinctive icons that are easy to spot as you roll past with the 'spirit-in-the-bottle' effect? Would it be equally useful if you had to actually read the text of otherwise similar items in order to pick your way through the maze?

Another question that pops up – would the proposed 'Context Dock' (CD) be a linear representation or, like the System Dock, just show Events at discreet annotated items in chronological order, with the actual timeline aspect reserved for the 'top of the screen' editable timeline (referring to Greg's proposal)?

On the other hand, if the CD were to reflect a linear timeline in its collapsed state, how would that work?

Just to invent a case: just assume I'm writing a crime drama spanning the life of Alfred Nobel, cross-referencing it with the great inventions of the second half of the 19th century, and with the triggering actions happening in the span of a week in 2009 (let's say that the Nobel Foundation has been hacked and all the prize money is gone) – how would you reconcile a span of some 70 years in the 19th century with a couple of days last year to be represented in the CD?

I'm playing the devil's advocate here, of course. Basically, I'm dead against mixing linear and non-linear in the same timeline. Greg's CD idea could separate non-linear search (to quickly find your point of focus) from linear editing (an accurate, visualisation of the timeframe of Events) into two clearly defined and separate functions.

Still, I suspect that in order for the CD to be clear enough for quick identification of Events and Entities, the user would have to be rather pedantic about colour coding and/or selecting different types of icons for different purposes.

Random thoughts for your consideration, FWIW, et cetera. On the other hand, if it were easy, anybody could do it.

Best regards,

Joachim

ja
janra
Posts: 471
Joined: Sun Jun 18, 2006 12:06 am
Platform: Mac
Location: Vancouver, BC

Sat Jan 23, 2010 12:49 am Post

On the one hand, seeing a timeline as a time scale that gives you a good idea at a glance of the relative timing of things is useful.

On the other hand, each item is an event (scene?), and no matter how far apart they are in time, they are close together in the book. (Not counting flashbacks and other non-chronological stories.)

I am a big fan of the non-linear timeline scale. I wish entity view showed duration as well, but I like the compression and expansion of the time scale to keep event densities more or less constant as I scroll through. (Yeah, the algorithm isn't perfect. But it's a darn sight better than iCal, which is what I tried before.)

One place where the overview breaks down is when your events are so close together they form a solid mass.

In particular, I had one story with some birth events decades before, some backstory events years before, then everything in the main story happened in the space of 6 months or less. The overview's "you are here" shading disappeared completely when I was anywhere in the main story. For this particular case, maybe birth events off all by themselves could be ignored for the overview display, to stretch it out a bit? I'm not sure just how well that would work.

For hiding stuff when you zoom out for an overview, maybe integrate it with tags? For example, a tag of "important" and a configuration option that when zoomed out past a certain zoom level, show only things with that tag. Users could configure any number of importance levels or turn it off.

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Sat Jan 23, 2010 5:00 am Post

janra wrote:On the one hand, seeing a timeline as a time scale that gives you a good idea at a glance of the relative timing of things is useful.

Yes!

janra wrote:On the other hand, each item is an event (scene?), and no matter how far apart they are in time, they are close together in the book. (Not counting flashbacks and other non-chronological stories.)

One interesting aspect of this discussion is that I've come to realize how many different (and perhaps irreconcilable?) interpretations there are of the word 'timeline'.

I'm approaching Aeon TL from the POV of an actual novel (or perhaps screenplay) project I'm planning, currently at a very early idea stage. I don't see events as being "close together in the book" at all.

What I would need is a simple and intuitive app that lets me map out characters' basic data and the main events on a linear time scale, so that I can get an unequivocal visual impression of what is happening when, that char A doesn't marry when he's 16 years old, that char B isn't too old when event C happens and that char D doesn't enrol in the army when he's 12 – that sort of thing.

Later, I'm planning to split up three storylines, in different timeframes, and tell them in parallel or rather 'intercutting', to use movie language. It's not flash-backs, technically, but parallel (though interconnected) stories. So, the events in the timeline will not be stacked next to each other at all. When I come to that stage, I'll probably work with the corkboard in Scrivener 2.

So, I wouldn't use the TL app as an alternative to an outliner, mapping out all and every event. Maybe I'd get around to appreciate a non-linear principle when I get to that stage, who knows. I'm very visually oriented; a timline where I have to squint at fine print to figure out if a scale step means months, years, decades or millennia is utterly confusing and counter-productive to me.

janra wrote:I am a big fan of the non-linear timeline scale. I wish entity view showed duration as well, but I like the compression and expansion of the time scale to keep event densities more or less constant as I scroll through.

This is were we have to agree to disagree… :wink:

I can well understand this POV if you're using the TL app as a pure outliner. But to work for me in this context, the non-linear expansion/compression would have to be clear and immediate on an altogether different visual level than what is currently implemented in Aeon TL.

For my purpose, sketched above, I would be quite happy with the TwistedWave audio app type navigation. Zoomed out, events would superimpose and become non legible. So what? If focussing, zooming and scrolling are quick and smooth enough, I just hit the cursor in the middle of the mess and use the scroll wheel to zoom in.

This simplified concept would probably not work so well if you're treating Aeon TL more as a detailed outliner, were every single event has to compete for space with others. If you want all the events, stacked neatly next to each other, that would indeed necessitate a kind of non-linear mode.

But then again, aren't we talking more about an outliner than a dedicated timeline app?

I hope that Matt can find a way to reconcile these two very different usage scenarios in one app.

janra wrote:For hiding stuff when you zoom out for an overview, maybe integrate it with tags? For example, a tag of "important" and a configuration option that when zoomed out past a certain zoom level, show only things with that tag. Users could configure any number of importance levels or turn it off.

Yes, tags are fine and functional, but at the same time they require much more input from the user. Maybe nitty-gritty classification is necessary at one stage in the development but again, I think it's becoming more and more important to define the scope of Aeon TL.

What is it supposed to do, and what might better be left to other types of apps, in order not to compromise the basic tasks?

FWIW,

Joachim

ha
hak
Posts: 5
Joined: Sat Nov 28, 2009 5:41 pm

Sun Jan 24, 2010 3:29 pm Post

Another example for zooming in on a shorter time-period: have you seen how MemoryMiner (http://www.memoryminer.com/) handles this?
Have a look at the attached jpg!
Within the timeline one can set a glider to the period you want (just a few days or weeks or months + + +) and then move the glider over the timeline.
Wouldn't this be a near to perfect solution for our needs in Aeon?

What do you think?
Attachments
ScreenCapGliderMemMin.jpg
ScreenCapture of Glider on Timeline
ScreenCapGliderMemMin.jpg (33.91 KiB) Viewed 1135 times

ma
matt
Posts: 1180
Joined: Mon Jul 30, 2007 9:35 am

Mon Jan 25, 2010 5:28 am Post

hak wrote:Another example for zooming in on a shorter time-period: have you seen how MemoryMiner (http://www.memoryminer.com/) handles this?


Thanks, I will download that app and look at it shortly.

WIth regards to the linear timeline:

One problem which was a continual issue when I started with the linear timeline, and which I have run into again if I add the option back in to switch between the two, is the time taken to calculate and produce the timeline as you zoom in.

The problem is not with the events themselves, which are fixed in number and take the same length to compute, but with the tick marks and dates/times written on the timeline itself: if your timeline spans 50 years, and you want to zoom into a day by day level, then the program has to calculate the position of and display 18,000 text items. If you want to look at something by the hour, this becomes 438,000 items.

It may be possible to work around this by only calculating the part of the window that is currently displayed, but this would require me to overhaul the entire scroll window and replace it with my own mechanism (note that the audio applications above all use the standard Apple scroll window). I am not against doing this if it will provide a definite benefit, but it will mean that more calculations will be required as you scroll, which may lead to its own slow downs (though not as noticeable as the hang that will currently occur).

Spitfire31 wrote:With my admittedly limited powers of abstract thinking, I couldn't make heads or tails of a representation like that… :shock:

I visualize time as a linear flow, with events at irregular, non-linear, places along that linear timeline.


I wonder if the issue is not so much the non-linearity that makes it difficult for you to follow, but the fact that there is no clear visual clue (other than carefully looking at dates) to show where the timeline is magnified, and where it is compressed (note that the selection of inappropriate zoom scales is a different issue, a bug rather than a design flaw).

Could there perhaps be some way to make this visual distinction more noticeable, and therefore easlier to conceptualise? I am not sure of the best way to do this, but the magnification on the dock would be an example, where the warping clearly shows the part that is magnified. Could a similar thing work for the timeline?

Matt

PJ
PJS
Posts: 1185
Joined: Sun Jul 22, 2007 5:05 pm
Platform: Mac + Windows
Location: Upstate New York

Mon Jan 25, 2010 3:36 pm Post

Spitfire31 wrote: janra wrote:On the one hand, seeing a timeline as a time scale that gives you a good idea at a glance of the relative timing of things is useful.Yes!

Another hearty yes.

Spitfire31 wrote:What I would need is a simple and intuitive app that lets me map out characters' basic data and the main events on a linear time scale, so that I can get an unequivocal visual impression of what is happening when, that char A doesn't marry when he's 16 years old, that char B isn't too old when event C happens and that char D doesn't enrol in the army when he's 12 – that sort of thing.

Isn't that exactly what A does now, if you create a (perhaps relatively) simple cross-match of entities and events? Or do I misread your question?

Spitfire31 wrote:However, isn't much of the Dock's usefulness due to the fact that it's based on very distinctive icons that are easy to spot as you roll past with the 'spirit-in-the-bottle' effect? Would it be equally useful if you had to actually read the text of otherwise similar items in order to pick your way through the maze?


I don't much like the Dock, but its magnifying effect seems to be a good idea for A. Would it be practical (from a design point of view) to generate that, and would it be workable (from an operational POV) to include within A a set of icons to be used as markers for events/entities? Or to allow insertion of personally-meaningful visuals to ID those items?

Phil
You can't conquer stupid — or cure it — with more stupid.

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Tue Jan 26, 2010 4:24 am Post

matt wrote:WIth regards to the linear timeline:

One problem which was a continual issue when I started with the linear timeline, and which I have run into again if I add the option back in to switch between the two, is the time taken to calculate and produce the timeline as you zoom in.

The problem is not with the events themselves, which are fixed in number and take the same length to compute, but with the tick marks and dates/times written on the timeline itself: if your timeline spans 50 years, and you want to zoom into a day by day level, then the program has to calculate the position of and display 18,000 text items. If you want to look at something by the hour, this becomes 438,000 items.

It may be possible to work around this by only calculating the part of the window that is currently displayed, but this would require me to overhaul the entire scroll window and replace it with my own mechanism (note that the audio applications above all use the standard Apple scroll window). I am not against doing this if it will provide a definite benefit, but it will mean that more calculations will be required as you scroll, which may lead to its own slow downs (though not as noticeable as the hang that will currently occur).

Not being a programmer (since dabbling with simple utilities in structured BASIC on a Sinclair Spectrum in the early eighties) I had no idea that a linear timeline would be this demanding. ;-)

That said, do we really need to be able to zoom continuously from a five decade timeframe into hours?

Would it be simpler if we could select a number of more sensible time spans, such as century > months, months > days, weeks > hours? This is not a considered proposal, just an example. But that kind of arrangement (a bit similar to the rudimentary timeline feature in StoryMill) might perhaps make the calculations more manageable?

matt wrote:
Spitfire31 wrote:With my admittedly limited powers of abstract thinking, I couldn't make heads or tails of a representation like that…

I visualize time as a linear flow, with events at irregular, non-linear, places along that linear timeline.


I wonder if the issue is not so much the non-linearity that makes it difficult for you to follow, but the fact that there is no clear visual clue (other than carefully looking at dates) to show where the timeline is magnified, and where it is compressed (note that the selection of inappropriate zoom scales is a different issue, a bug rather than a design flaw).

Could there perhaps be some way to make this visual distinction more noticeable, and therefore easlier to conceptualise? I am not sure of the best way to do this, but the magnification on the dock would be an example, where the warping clearly shows the part that is magnified. Could a similar thing work for the timeline?

Matt

Difficult to say, isn't it, until one could actually see an example of how it might work. For me at least, the overwhelmingly important consideration is that any non-linearity should be immediately apparent at a glance. If I need to squint at dates next to identical tick marks just to figure out if I'm looking at months, or years, or decades in the same continuous timeline, I might as well ask my Excel-savvy wife to knock up a spreadsheet for me… :wink:

I agree that it may be a matter of presentation. One forte of the Mac environment (especially with OpenGL) is visual presentation, isn't it? I won't start nagging about the TwistedWave analogy again (which is, in fact, quite similar to the Memory Miner navigation shown by Hak above); suffice to say that the beauty of it is that it is extremely clear and intuitive even at the briefest glance. To me, that means that I can focus my attention on the task at hand instead of being sidetracked figuring out where I am at.

The 'dock style' warping might be a way forward for all I know. Still, I suppose this 'enlargment' needs to be limited in scale. It's a bit difficult to imagine how I could slide a magnifier over a timeline covering a couple of decades, blowing it up to days or even weeks.

As I threw out above, perhaps an A TL project needs some limitation in scope? The user might have to decide on a range of time units available in each project. For instance, is it reasonable to expect to be able to fiddle with hours in a project spanning a century? Purely as an example, maybe you have to accept working in chunks of months in order to zoom into the 'hours' detail level?

This seems to be heading into an unstructured rant, so I'd better stop here for now. :mrgreen:

Conclusion: non-linear might work if presented in a crystal clear, visually unambiguous manner. For instance, I suspect that scale ticks would need look different for different time levels; identical ticks, of course, send a visual signal of constant scale.

Best regards,

Joachim

User avatar
Spitfire31
Posts: 242
Joined: Sun Oct 01, 2006 8:11 pm
Location: Sweden

Tue Jan 26, 2010 5:03 am Post

PJS wrote:
Spitfire31 wrote:What I would need is a simple and intuitive app that lets me map out characters' basic data and the main events on a linear time scale, so that I can get an unequivocal visual impression of what is happening when, that char A doesn't marry when he's 16 years old, that char B isn't too old when event C happens and that char D doesn't enrol in the army when he's 12 – that sort of thing.

Isn't that exactly what A does now, if you create a (perhaps relatively) simple cross-match of entities and events? Or do I misread your question?

You didn't misread. ;-) I just tried to restate my personal, basic needs in a timeline app. And while it's true that A TL does this in principle, and very competently, I'm thrown off by the, to me, confusing non-linear presentation mode.

However, as Matt pointed out above, my 'problems' might at least partly stem from some bugs in the implementation; difficult to tell really, until my eyes can try out a more representative version.

Best,

Joachim