I played a little bit with the new views. My favourite is the column view, but I enjoy the time view as well. I think each view has its strength and it is good to have options.
I also like double click to root a folder and the new behaviour when opening a folder triangle in list view.
Nice work.

Some observations:
- I find myself always looking up when searching for the path bar. I know the Finder has it on the bottom too. But for me the top of the browser feels more natural.
- Hoovering over a dot in the browser no longer displays the Playback controls. Are they simply not jet implemented or is there a new way to reveal previous/next captured instances?
- What is the meaning
- Hiding irrelevant Layers is a good idea. But I would suggest to place the Show hidden layers command in the layers menu as well.
- In time view I can't select a certain instance in time. QRecall always selects all instances (the whole lance of pierced instances). When I ercall I get the last captured instance.
- What is the meaning of the different colours of the layer labels in time view?

Johannes

Johannes wrote:I played a little bit with the new views.
...
Nice work.

Thanks!

Some observations:
- I find myself always looking up when searching for the path bar. I know the Finder has it on the bottom too. But for me the top of the browser feels more natural.

I struggled with that myself. The problem is that if you put the path control above the item pane, it ends up between the item browser and the layers. The interface is already pretty busy there, and it gets obscured by the timelines. If you put it at the very top, now it's well away from the item views and feels disconnected from it.

- Hoovering over a dot in the browser no longer displays the Playback controls. Are they simply not jet implemented or is there a new way to reveal previous/next captured instances?

The individual item playback controls have not been (re)implemented. I was debating whether to keep them or not. With the ability to automatically hide uninteresting layers, their utility is considerably lessened. As an alternative, I've considered a keyboard short-cut that hides/reveals the layers based on the currently selected items. Functionally, that would be identical to the old playback controls. It would be less intrusive (interface wise), and ultimately more flexible, since one could select multiple items and navigate them as a group.

- What is the meaning

42

- Hiding irrelevant Layers is a good idea. But I would suggest to place the Show hidden layers command in the layers menu as well.

Good suggestion.

- In time view I can't select a certain instance in time. QRecall always selects all instances (the whole lance of pierced instances). When I ercall I get the last captured instance.

I originally wanted to allow one to select individual items in the time view, but when it came time to implement the recall actions it became clear that such a selection would create some serious problems for QRecall. QRecall's database model centers around the concept of a single range of time, within which one can operate on one or more items. If you select a file from layer 4 and a folder from layer 19, there's no way for QRecall to frame that selection in terms of a single operation.

But just like the playback controls, it would also be easy to create a short-cut that would let you click on an item in the time view and automatically shade the layers so that the item you clicked on is now the latest item, ready to be recalled or restored. This would be vaguely similar to Photoshop's Command+Option+click shortcut, which jumps to the layer of whatever you click on.

- What is the meaning of the different colours of the layer labels in time view?

It means they happened on different days. QRecall arbitrarily color codes the layers so that it's easy to pick out layers from different days/weeks/months, and see groups of layers that occurred on the same day. Also, the depth of each layer is (logarithmically) proportional to amount of time encompassed by that layer. So week layers are thicker than day layers, which are thicker than hour layers.

James Bucanek wrote:I struggled with that myself. The problem is that if you put the path control above the item pane, it ends up between the item browser and the layers. The interface is already pretty busy there, and it gets obscured by the timelines. If you put it at the very top, now it's well away from the item views and feels disconnected from it.

You are right. Leave it at the bottom.

The individual item playback controls have not been (re)implemented. I was debating whether to keep them or not. With the ability to automatically hide uninteresting layers, their utility is considerably lessened. As an alternative, I've considered a keyboard short-cut that hides/reveals the layers based on the currently selected items.

The Problem is that there is no obvious way to select an instance in the past. With the shortcut you still have the last instance selected and you need to start shading layers in a second step. Maybe (double-)clicking on the block-mark in the timeline could shade to that layer?

42

Now we only need to know what the question was

If you select a file from layer 4 and a folder from layer 19, there's no way for QRecall to frame that selection in terms of a single operation.

The easiest and most user friendly way would be to restrict selection in the time view to one item (or items within on layer).

But just like the playback controls, it would also be easy to create a short-cut that would let you click on an item in the time view and automatically shade the layers so that the item you clicked on is now the latest item, ready to be recalled or restored.

In this view the shortcut is useful. (Because it is the only view where you can select an item in the past directly.)

Too more things:
- I miss a toolbar item for instant recall
- I would prefer if switching browsers-styles would retain root, selection and layer shading

Johannes

One more suggestion on the path navigation placement:
Place the history arrows and an "up" Button at the left side between layers and browser. This would not obscure the time lines and help all users like me that tend to search at the top of the browser to navigate. Because that is mainly what I want: go back in history or up. Wait: Is there a situation where the back button would not simply go up? If not we can drop the up-Button.
The Navigation bar for big jumps would remain at the bottom.

Johannes

Johannes wrote:The easiest and most user friendly way would be to restrict selection in the time view to one item (or items within on layer).

I also would hate to do that too, for a number of reasons.

I haven't given up on selecting individual historic items in the timeline. I implemented the current method simply because it was consistent with the other views and I knew it wouldn't create any complications. I'd still really like the ability to switch to the time view, zoom through time, pick out an older version of some file, and immediately recall it. I just have to figure out how to do that in a way that doesn't make other things so complicated that people's heads explode.

Too more things:
- I miss a toolbar item for instant recall

Noted

- I would prefer if switching browsers-styles would retain root, selection and layer shading

Whoa, it should be doing that now. If it's not, then that's a bug (or probably five).

When switching between views, the root folder should remain the same and QRecall will attempt to preserve the current selection. Now there are obvious limitations, as some views (like list and column) can select nested sub-items that can't be represented in other views. But at the top level of each view, the selection should be preserved when switching between views. If it's not, please note the circumstances and I'll try to fix the problem.

Johannes wrote:One more suggestion on the path navigation placement:
Place the history arrows and an "up" Button at the left side between layers and browser.

All good suggestions. The UI is still in flux. I've also considered moving the history buttons to the toolbar, make them into keyboard shortcuts, add a column of navigation shortcut buttons to the left margin of the window, or any combination of those things.

So please keep your observations and suggestions coming.

James Bucanek wrote:When switching between views, the root folder should remain the same and QRecall will attempt to preserve the current selection. Now there are obvious limitations, as some views (like list and column) can select nested sub-items that can't be represented in other views.

Okay I think that was the point that confused me. I tried to check the behaviour systematically and all the time, when it "did not work" it was a selection in list or column view somewhere down the hierarchy. So it seems to behave accordingly to your programming. No bug then, but different philosophy than expected

Personally I would prefer this: preserve selection and change the root (or unfold) if necessary. But I have no idea what to do with cross folder selection in list view when switching.

I admit: what ever you do, it will compromise something and it is difficult to decide what.

I will have to do some meditation on this ?

Johannes

Just for the records: revealing an item via Service or Spotlight brings up QRecall but not the item. I guess this is related to the not yet implemented search.

Johannes

Johannes wrote:I tried to check the behaviour systematically and all the time, when it "did not work" it was a selection in list or column view somewhere down the hierarchy. So it seems to behave accordingly to your programming. No bug then, but different philosophy than expected

That's a good observation, and I might change how the column view handles this. I was trying to be consistent (read, the application shouldn't do unexpected things) in preserving the current browser path across all views. I didn't think that changing the view should change the folder or volume you were anchored at, nor should it create history.

Apple's Finder has the same problem and they went with the 50/50 solution; the Finder is consistent half the time.

Apple's list view acts just like QRecall's. Expanding and selecting items in subfolder doesn't change the the path of the browser window. If you switch from list to icon view, the icon view shows the top-level items in that folder and any selected sub-items disappear.

Column view is different. The Finder treats selections in a sub-columns as navigation. If you drill three folders into a column view and then switch to the icon view, the icon view shows the folder with the selected items. Also, selecting folders in column view adds steps to the navigation history.

So the Finder takes the approach that expanding folders and selecting items in list view does not constitute navigation, but selecting folders in column view is navigation. It changes the browser window's root path and adds steps to the navigation history.

I have to say that the Finder's approach, while somewhat inconsistent, has merit and wouldn't be terribly difficult to emulate in QRecall.

Johannes wrote:Just for the records: revealing an item via Service or Spotlight brings up QRecall but not the item. I guess this is related to the not yet implemented search.

It's closely related. Just one of the "many other things" that aren't yet re-implemented.

James Bucanek wrote:I have to say that the Finder's approach, while somewhat inconsistent, has merit and wouldn't be terribly difficult to emulate in QRecall.

Having thought about this for some days now, I would say: going with Finder behaviour might be the best for most users. Although I personally would like to always maintain selection, because when I switch views, the reason is that I want to do/see something in the other view with the selected item, that is not possible in the current view.

But while thinking about all this nice views and navigation between them, it came to my mind, that what ever road the the final UI will take, I will probably not see much of it. I rarely need to find and recall something from backup. If navigating is not exactly my personal taste, it won't trouble me often.
The missing AppleScript Trigger hits me more often. So: don?t waste too much time on the views

Johannes