[bethkatz17582]

Someone on the old mailing list brought up that the title bar of the key window is only slightly darker than other windows. It looks like we don't have a choice with that burnished metal look. I guess it hasn't bothered me in lots of other apps. But if you could figure out a way to have the key window's title bar a little more distinctive, that would be nice.

[betatester]

One fairly simple solution that Omni could give us would be to knock back the opacity of their toolbar buttons, and importantly, on their Tab Drawer controls on inactive windows (i.e. like the close/minimise/zoom controls)... the actual themes themselves are in Apple's court, naturally.

Of course, since Apple's already acknowledged this issue with the window controls, standard toolbars should arguably handle button opacity for devs.

In the non-beta thread on this issue, someone lamented the loss of 10.0's semi-transparent inactive titlebars -- I'm in two minds about that, OT1H it does distinguish, but in practice what you often ended up with was too much visual noise, the same thing that's now happening to Vista... but OTOH it does kinda look cool... hmm, usabilty vs trendiness... these days that seems to be a harder decision than it oughta be!

-- oops, still logged in as 'betatester'!

marc nothrop

[JKT]

That would have been me - I found the translucency of inactive windows useful, not noisy - it gave you that little bit more feedback as to what windows you had open and it was definitely easier to tell which windows were active versus inactive. Though saying that, we didn't have Exposé in those days. If Apple kept the same degree of opaqueness for frontmost windows that it has now and had a low degree of translucency for background windows, that would make it much easier to distinguish active versus inactive than it currently is.

Vista's problem is that MS have gone for a "look at what we can do (now)" approach to the UI as opposed to the correct one of "what actually works and is functional". I can't believe they have made an even bigger error than Apple did with the overkill translucency of their title bars but, hey, that's MS for you - take an idea and make it much worse than it was originally. ;)

P.S. For people having big problems distinguishing active v. inactive in 10.4 - I wonder how many have calibrated their monitor? If the contrast isn't suitable, then it could be because their colour calibration is too washed out.

[marc]

I tend to agree with you in theory that transparency seems like it could play a useful role in distinguishing active windows/apps, but in practice it is hard to use it effectively, as both of the cited examples tend to prove! :)

Of course you can play around with this a little yourself, either with the for-pay WindowShade, or the free InvisRay http://www.davidestes.net/.

Anyway, this is stuff out of OG's control, and they don't really have many options, so IMHO the best option is 'greyed out' toolbar buttons, as noted before.

It's pretty simple to do, so I figured I's test it, and IMHO it seems like a workable solution with minimal effort and negative impact (you can still differentiate unavailable buttons/controls in background windows.)

Click to enlarge...

You'd also want to have lighter drawer thumbnail icons to help avoid the confusion when a background drawer appears to belong to the active window.

The other most visible element that would help to highlight the active window would be to reduce the opacity/fill of the page thumbnails in background tab drawers, which would be a much more visible indication of the active window.

The argument can be made that this is non-standard behaviour, but there is an evident issue in the UI conventions with denoting the active window, made even more evident with the Unified Toolbar theme (which is otherwise superior IMHO, offering a larger drag target, and reducing visual noise in the toolbar.)

I tend to think of this as an extension of the existing convention of greying out window controls and titles, or OTOH that convention is incompletely implemented, and should already have been extended to the toolbars.

Any thoughts?

[JKT]

It works for me, but this is something Apple needs to do at the OS level rather than leave it to the developers of applications. As they are unlikely to do that with Tiger,

Wrt Windowshade X - no thanks. Too many problems with it in the past for me too trust it today. I'm also with developers who consider haxie use as a PITA for troubleshooting and as I test a few beta apps, I try to keep my system hacks to the minimum.

[marc]

Originally Posted by JKT

It works for me, but this is something Apple needs to do at the OS level rather than leave it to the developers of applications. As they are unlikely to do that with Tiger,

Well, I agree, at first glance I think this should be a part of the normal behaviour... unless there's something better! :)

...but I also think it's valid for dev's to make some modification's if they add value; Apple's not above a bit of UI variety and experimenting. OK I'm being a bit glib, but this isn't an obtrusive change, other apps fade out their windows in the background, offer HUDs or go full-screen, even though those cases aren't explicitly covered in the HIG.

Originally Posted by JKT

Wrt Windowshade X - no thanks. Too many problems with it in the past for me too trust it today. I'm also with developers who consider haxie use as a PITA for troubleshooting and as I test a few beta apps, I try to keep my system hacks to the minimum.

I was really only pointing to them as ways to try these things in practice, which is really the only way to go. Initially I was sceptical of transparency in background windows, but now I'm playing with just that, and it's actually quite effective. I'm not sure if I'll stay with it, but real use can surprise you... YMMV. :)

[JKT]

Oops, I missed the last part of my sentence off in that post... "As they are unlikely to do that with Tiger," should have continued with "I wouldn't object to OmniGroup doing something like it now" ;)