[jasong]

Originally Posted by Lizard

see also http://blog.omnigroup.com/2008/06/25...-of-omnifocus/

Ken says in that entry

Matt’s next issue was with our column resizing behavior: “Have you ever seen a Mac program where when you widen and narrow a column the entire window widens and narrows like that?” Well, actually, I’m guessing you have, since we borrowed that behavior from the Finder! If you open a Finder window and switch to Column view, then drag the last column wider and narrower, you’ll find that it makes the whole window wider and narrower.

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

This is under 10.5.3.

Anyone else seeing what I see?

Ken also asks

Now, just because there’s precedent in the Finder doesn’t mean I’m saying that this is the most desirable behavior. But what is? What exactly do you expect to happen when you make the title field wider or narrower? Should we just pick another field at random to make wider or narrower to compensate for that change? Or should the column widths no longer match up with the width of the window, leading to lost fields off the edge or to dead space on the inside of the edge? Most approaches we’ve seen lead to lots of fiddling to try get all the columns to add up to just the right width to fit within the window.

I'd prefer, in order:

* How Mail under 10.5 does it: you can resize columns so the total width can't go beyond the width of the window. This works great: I can set a desirable window width, then adjust column widths until they all fit as I want.

* How every other Mac application does it: when you resize columns, you get a horizontal scroll bar and columns which don't fit the window size scroll off the right. This is a well-established behavior on the platform, and I don't think it would confuse users.

[Ken Case]

Originally Posted by jasong

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

Are you perhaps in List view rather than Column view? Or not dragging the column width past the right edge of the window?

I do think your suggestions are reasonable; we were trying to avoid the little time-wasting dance seen in every other app (including OmniOutliner) where you spend time trying to get the column widths and the window width to line up exactly right, but I think we could move that behind a preference and stop the debate. :)

[Toadling]

Originally Posted by jasong

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

I think you need to grab the last, right-most column handle - the one on the right side of the last column. On my system (also 10.5.3), moving that handle back and forth does, indeed, resize the window.

That being said...

Originally Posted by jasong

I'd prefer, in order:

* How Mail under 10.5 does it: you can resize columns so the total width can't go beyond the width of the window. This works great: I can set a desirable window width, then adjust column widths until they all fit as I want.

* How every other Mac application does it: when you resize columns, you get a horizontal scroll bar and columns which don't fit the window size scroll off the right. This is a well-established behavior on the platform, and I don't think it would confuse users.

I agree. I think Mail's approach is best.

-Dennis

[jasong]

Originally Posted by Ken Case

Are you perhaps in List view rather than Column view? Or not dragging the column width past the right edge of the window

I see... drag a column wide enough to "push" the width of the window bigger.

That's not what OF does, though.

OF's window width is the total width of all the columns. Resize column A by 20 pixels, the window shrinks by 20 pixels. You never see a horizontal scrollbar.

Finder, though, shows a horizontal scrollbar when you resize a column unless and until you drag that column's width past the edge of the window. When you make the column narrower, the Finder window shrinks back, following this column's width until the Finder window is its original size, at which point, the Finder window locks to that width and the column continues to get smaller.

[Ken Case]

I hope you read past my first paragraph on the subject? I never claimed that our behavior matched the Finder's exactly, I just said that we weren't the first application to change the window size when resizing a column. And then went on to say that I wasn't sure that we'd come up with the best solution, but that we were trying to solve the problem of fiddling to try get all the columns to add up to the exact width of the window (which is the downside of OmniOutliner's approach).

Mail solves the "exact width" fiddling problem by taking the size away from another field. We considered that approach, but then making the project field wider would make the context field narrower, which isn't usually what people are trying to accomplish.

[iNik]

Originally Posted by Ken Case

Mail solves the "exact width" fiddling problem by taking the size away from another field. We considered that approach, but then making the project field wider would make the context field narrower, which isn't usually what people are trying to accomplish.

Amazing how these seemingly-small details are such a bear to nail just right.

Resizing everything is awful, as is moving everything off the edge of the window. This is what I do ALL THE TIME in Excel, and SOMETIMES it does what I want, and SOMETIMES it drives me nuts and confuses me!

Resizing the window itself seems a bit goofy, but it fills the requirement of resizing the one column without affecting the other columns. Isn't that what you're trying to do in the first place?

[jasong]

Originally Posted by Ken Case

I hope you read past my first paragraph on the subject?

C'mon Ken....

I never claimed that our behavior matched the Finder's exactly, I just said that we weren't the first application to change the window size when resizing a column. And then went on to say that I wasn't sure that we'd come up with the best solution, but that we were trying to solve the problem of fiddling to try get all the columns to add up to the exact width of the window (which is the downside of OmniOutliner's approach).

I can appreciate that. The window-resizes-when-moving-a-column happens only in one edge case (no pun intended). Your comments in various places led me believe that it happened always when resizing Finder windows, and thus you modeled it after that behavior; based on your clarification in the blog comments, I thought that was your believe also. I apologize if I misread that.

If OF implemented resizing similar to Finder's behavior, I would be happy.

[Ken Case]

Originally Posted by jasong

Your comments in various places led me believe that it happened always when resizing Finder windows

Oh, sorry! I meant my comments in the more limited sense I just described, but as I review what I actually wrote I can see how it might be misinterpreted. (It seemed obvious enough to me in my own head!) I'll see if I can make the original post more clear so I don't confuse others about what I meant.

[jasong]

Originally Posted by iNik

Resizing the window itself seems a bit goofy, but it fills the requirement of resizing the one column without affecting the other columns. Isn't that what you're trying to do in the first place?

That probably wasn't directed to me, but:

My approach is "set a window width, make columns fit that width".

Others prefer "set all the column widths, make the window fit that width".

Neither is "right" or "wrong", per se, but expectations make it so (with apologies to Shakespeare).

People gave feedback on this months ago, in a long thread that has since been closed. Folks came down strongly on both sides of the discussion, so clearly there's no "right" answer.

If the goal is, as you say, "resizing the one column without affecting the other columns", the current OF way does that, but then, so did the Finder way and the Mail way.

So that couldn't have been the only goal.

(Kaebot from Omni offered his(?) opinion on why it was done this way:

Originally Posted by kaebot

One last thought related to the horizontal scroll bars and windows - with OS X window behavior, my understanding is that they implement extra, empty columns so that the window doesn't change size when you change the column width. (Check out Finder, iTunes, etc.) Part of the reason we'd rather not is because OmniFocus is about eliminating distraction and extra columns would be distracting!

I found that amusing; I assume kaebot was being funny because I'd hate to think that was the real reason!)

Here's where the current implementation is an issue, and why I'm glad the OF team is focusing (ahem!) on improving the behavior:

I keep the Inspector panel open on the right edge of my screen (OF is much more usable with it always showing).

I keep my main OF window open to the width of the rest of the window.

Upon first setting this up, I adjust the internal columns to be a particular usable width, fiddling with things so that they're readable, and at the same time making the window itself the right size.

Perfect!

Now, I open an unfortunately deep-nested action item, and the resulting content isn't readable. I widen the width of the column, which widens the width of my window, which obscures content in the window below the Inspector.

If widening the column simply added a horizontal scrollbar, all my content would remain a scroll away. Instead, I have to either resize the window or move the Inspector.

I know, I'm harping now. I apologize. The big issue for me is that for the year or so I've been using OF, this has never been considered a "problem" by the Omni team (at least, not that I recall). It's how it was designed, and works as designed.

I'm glad to see that this isn't (any longer?) the case, and that the team is looking at ways of making this better. I applaud them for doing that.

[Ken Case]

Originally Posted by jasong

Now, I open an unfortunately deep-nested action item, and the resulting content isn't readable. I widen the width of the column, which widens the width of my window, which obscures content in the window below the Inspector.

If widening the column simply added a horizontal scrollbar, all my content would remain a scroll away. Instead, I have to either resize the window or move the Inspector.

That's an excellent use case demonstrating a problem with the design.

The big issue for me is that for the year or so I've been using OF, this has never been considered a "problem" by the Omni team (at least, not that I recall). It's how it was designed, and works as designed.

Oh, sorry if we ever came across that way! Just because it works as designed doesn't mean that the design is perfect, and I apologize if you ever felt like we weren't listening to feedback on the design.

We introduced this resizing behavior fairly late in the UI design cycle (in November), and simply hadn't had a chance to revisit it since then. We don't quite have time now, either, but we hope to have time to work on issues like this very soon (once we get synchronization out the door).