Tabs in Titlebar on Windows

[Benjin Dubishar]

This is likely an extremely old topic but a quick search didn't turn anything comprehensive up on the topic.  Every search result I see has just died or been closed without much discussion.

Drawing the tabs all the way up in the titlebar makes it extremely difficult to drag windows around when you have even a not-unreasonable number of tabs open, as it leaves only a small space open for grabbing the window with the mouse.  

As someone who runs Windows with multiple screens, using Chrome in a maximized state is such a pain that I still haven't been able to switch from Firefox, despite all the other functionality and speed improvements... and trust me, I dearly would love to.  I snap windows to the sides and tops of my screens constantly and having a program not play nicely ruins my workflow.  Yes, I know tabs can be drawn on the side, and yes, I know (and use all the time) the keyboard shortcuts for moving windows around, but that's really not the point.  The fix to address this is quite simple - add a checkbox in settings to draw the tabs 5px (enough to grab the window with the mouse anywhere along the border) from the top instead of all the way up against the edge of the screen - so it appears to be a conscious design decision to not easily facilitate window snapping on Windows.  I'm curious, what's the rationale there?

[Peter Kasting]

This isn't really the right list for this; chromium-dev is a technical development list.

On Thu, Feb 14, 2013 at 12:49 PM, Benjin Dubishar <ben...@google.com> wrote:

The fix to address this is quite simple - add a checkbox in settings to draw the tabs 5px (enough to grab the window with the mouse anywhere along the border) from the top instead of all the way up against the edge of the screen

We would never add such an option.  For an example of what happens when you try to add options for every user's individual workflow, see Seamonkey or VLC.

- so it appears to be a conscious design decision to not easily facilitate window snapping on Windows.  I'm curious, what's the rationale there?

Windows never used to allow movement of maximized windows, to my knowledge, and this was never an ability our UI was designed to support.

PK 

[Mike Frysinger]

On Thu, Feb 14, 2013 at 3:54 PM, Peter Kasting <pkas...@chromium.org> wrote:
> On Thu, Feb 14, 2013 at 12:49 PM, Benjin Dubishar <ben...@google.com>
> wrote:
>> - so it appears to be a conscious design decision to not easily facilitate
>> window snapping on Windows. I'm curious, what's the rationale there?
>
> Windows never used to allow movement of maximized windows, to my knowledge,
> and this was never an ability our UI was designed to support.

FWIW, i think it's in at least Windows 7 if not Windows Vista
-mike

[Zachary “Gamer_Z.” Yaro]

It was introduced in Win7.  Chrome was designed around XP and Vista.

—Zachary “Gamer_Z.” Yaro

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Benjin Dubishar]

On Thursday, February 14, 2013 12:54:42 PM UTC-8, Peter Kasting wrote:

This isn't really the right list for this; chromium-dev is a technical development list.

Sorry; I was recommended here by a Googler on Chrome.  What's the appropriate list for this kind of discussion? 

  

On Thu, Feb 14, 2013 at 12:49 PM, Benjin Dubishar <ben...@google.com> wrote:

The fix to address this is quite simple - add a checkbox in settings to draw the tabs 5px (enough to grab the window with the mouse anywhere along the border) from the top instead of all the way up against the edge of the screen

We would never add such an option.  For an example of what happens when you try to add options for every user's individual workflow, see Seamonkey or VLC.

 

I agree that an additional option is not the way to go; VLC, Seamonkey, Handbrake, and the like have rather poor user experiences for customization, despite being highly capable.

All that would need to be implemented is a non-zero top margin.  A pixel or two would completely absolve the issue, while only taking up a negligible amount of vertical space and, even then, only for Windows versions.  I think this is more significant than merely an individual's workflow.  Window snapping was probably the single most significant UI improvement introduced in Windows 7, and without any kind of margin above tabs, Chrome renders it nearly useless for instances with more than ~6 tabs. 

 

 

- so it appears to be a conscious design decision to not easily facilitate window snapping on Windows.  I'm curious, what's the rationale there?

Windows never used to allow movement of maximized windows, to my knowledge, and this was never an ability our UI was designed to support.

UIs ought to be updated with their OSes, no?  This UI change was introduced 2008, giving plenty of time for such a small-but-significant update.

 

PK 

[Thiago Farina]

On Thu, Feb 14, 2013 at 8:35 PM, Benjin Dubishar <ben...@google.com> wrote:
> All that would need to be implemented is a non-zero top margin. A pixel or
> two would completely absolve the issue, while only taking up a negligible
> amount of vertical space and, even then, only for Windows versions. I think
> this is more significant than merely an individual's workflow. Window
> snapping was probably the single most significant UI improvement introduced
> in Windows 7, and without any kind of margin above tabs, Chrome renders it
> nearly useless for instances with more than ~6 tabs.
>

Could you attach a screenshot of what it looks like?

--
Thiago

[Brett Wilson]

The zero top margin is explicit to get Fitt's law for tab switching. I
think supporting this use case is much more important that what you
want.

Brett

[Benjin Dubishar]

I'm not at a Windows machine right now, but there's a screenshot in the original post with the grab-able area in red.  Another tab open, and that would be reduced to only a tiny area (just over 16x16).

[Scott Violet]

FWIW You can actually grab the window in the notches between the tabs.

-Scott

[Benjin Dubishar]

@Brett

The Linux (or at least, Ubuntu+Unity/gPrecise, as that's what I'm on at the moment) and OS X versions both have non-zero margins because of the system menubars at the top of the screen, so neither of those versions are benefiting from Fitt's Law in that way.  At absolute worst, the ability to select a tab on Windows falls (infinitesimally) to the same level as the other two platforms.

When applying Fitt's Law to a design, it's important to weigh the calculated "ease of selection" by how often a task is completed.  Changing tabs is an extremely common task in a web browser and moving windows around is a few notches below that at "fairly common".  Given that it's not a rare or even uncommon task to rearrange windows, I don't think it makes sense to have the clickable areas so strongly slated in one function's favor at the expense of a still-often-but-less performed other function.  By adding a tiny margin above the tabs where one can grab the window, you hugely benefit the ability to grab the window while only barely impacting one's ability to select a tab.  Also, ask yourself what's easier: targeting a favicon-sized space or moving all the way to the border and then back some (as you currently must do for the OS X and Linux versions of Chrome).  It's possible for both functions to benefit from this aspect of quantitative UI design by taking advantage of the screen's edge.

@Scott

I know, but I those notches are nearly negligible because of the amount of precision you need to get them.  It's like trying to highlight a single character in a line of text on your first try - doable, but not quickly or without some concentration.

[Peter Kasting]

On Thu, Feb 14, 2013 at 3:22 PM, Benjin Dubishar <ben...@google.com> wrote:

The Linux (or at least, Ubuntu+Unity/gPrecise, as that's what I'm on at the moment) and OS X versions both have non-zero margins because of the system menubars at the top of the screen, so neither of those versions are benefiting from Fitt's Law in that way.

Which is probably the single most annoying thing about Chrome on OS X.

When applying Fitt's Law to a design, it's important to weigh the calculated "ease of selection" by how often a task is completed.  Changing tabs is an extremely common task in a web browser and moving windows around is a few notches below that at "fairly common".

Moving windows is uncommon.  Moving maximized windows is extremely uncommon.  That may grow over time as more people make use of Win 7+'s capabilities here but it's not remotely "fairly common".

By adding a tiny margin above the tabs where one can grab the window, you hugely benefit the ability to grab the window while only barely impacting one's ability to select a tab.

The Fitts Law loss is not "barely impacting".

The workaround here is: restore your window, then move it.

PK

[Jake]

I'm not seeing the issue here. I'm an avid user of chrome on windows and I have no problem moving maximized windows on Windows 7. There is plenty of room.

I've attached an image of a maximized chrome window with as many tabs open as will fit, and the areas marked in red were still available for dragging (There are other areas, obviously, but the ones in red were the ones I tested.)

I'm not sure I see this as a valid reason to stick with Firefox.

-Jake

[Benjin Dubishar]

@Peter:

Contrarily, I find the inability to grab the titlebar in the same manner as every other program the single most irritating thing about Chrome on Windows, enough that I'm willing to put up with a slower, memory-heavy, and comparitively buggy browser to avoid it.

Any time you're multitasking, you're rearranging windows.  You throw Eclipse on one screen and split the other between a terminal and a browser.  If you need to reference a file in conjunction with another project, you open a file explorer alongside that program.  Want to stream a soccer game or passively watch a Youtube video in one corner while you're working with the rest of the screen?  You rearrange your windows yet again.  There's a reason why Microsoft wrote two blog posts on the subject of task and window switching, why Canonical added Windows-style window snapping to Ubuntu back in 2011, and why there was a flurry of programs released for OS X to add snapping to the window manager following the Windows 7 launch.  Moving windows around is absolutely a common task, especially compared to tearing or rearranging tabs, the result if one tries.  You say "as more people make use of Win 7's capabilities" as though it's a new-fangled technology; it's been around for nearly every single release of Chrome, and people do use it.

I'm not talking Ubuntu or OS X-sized margins, but one or two rows of pixels.  Your mouse probably bounces back that much just coming to a stop.  Moving a negligible amount from the screen border to a large target is pretty much the ideal situation for Fitt's Law - you have a near-zero D and a relatively massive W, resulting a coefficient of 0 for b, and a is extremely low due to the mouse's nature and the fact that it's already in motion from approaching the tab.  This change would add nearly nothing to the actionable time.  The existing state of window manipulation either requires me to hit one of very few tiny areas on the titlebar, as shown in green in the attached image.  The red areas are those which are exposed, but don't allow you to grab the window.  The work-around you suggested really doesn't solve the problem, as you're suggesting that to avoid having to click a small target in the form of empty titlebar space, I instead click an equally small button and then move the mouse to the window's new location, click again, and finally do the dragging.  I honestly wouldn't be surprised if the restore/maximize button were deprecated soon on Windows due to the ability to drag windows around.

There's a potential middle-ground, but I'd have to mock it up to see whether it'd adequately address both of our concerns.  What if a click+drag on that single top row of pixels grabbed the window while only a click selected the tab.  A click+drag on any other spot on the tab would allow you to tear the tab off, as currently happens.  May be worth investigating.

@Jake:

See my attached image.  I just did a pixel-by-pixel check for the latest stable version of Chrome (24.0.1312.57) and a fully-updated version of Windows 8.  Red is undraggable-but-exposed, green is draggable.  By my findings, the actual draggable area is rather smaller, particularly along the border.  Compared to Firefox, there's a toggle in about:config which drops the tabs down a bit (admittedly, much further than necessary), opening up almost the entire top border to dragging, without sacrificing any significant amount in the ability to select a tab.  Fitt's Law will tell you that something along a border can be treated as a target of infinite depth, and expanding the target's width along the border skyrockets its ability to be hit.  Making such a change would boost the draggable area from ~5% of the border with a full tab bar to nearly 95% - a massive change - while only adding a hair of extra time to the task of changing tabs, and only in a specific circumstance at that.

I'm a serial multitasker, and coming with that is constantly rearranging, moving, and resizing windows on my screen (sometimes multiple).  Such rearranging can only really be done efficiently with a mouse, while I've found that the task of changing tabs is split more evenly between keyboard shortcuts.  When a program as core as a web-browser acts in such a way that it breaks my workflow every time for a common task, it's a deal-breaker for me regardless of how amazing everything else about it is.

Good luck, be nice, and have fun,

Benjin Dubishar

[Tom Cassiotis]

Windows 7 features around maximizing and handling maximizing windows is my number 1 UI enhancement.  I miss them when I use any other OS.

Only until this thread did I realize that I was adjusting for Chrome's diminished dragability of the title bar.  I always moved Chrome using the gap between the minimize button and new tab button.

Jamming the mouse to the top of the screen and doing "some operation" is incredibly useful as it "invalidates" Fitts' law.  One of the degrees of freedom is constrained (height/y axis) so you only need to be accurate on the x axis and all the targets there are plenty large.  The question is what is the "some operation" that will get this benefit.  

I use tab navigation an order of magnitude more than I do Windows 7 nifty window dragging and I drag windows around very often.  I would expect that to be the case than more common users (perhaps more so).  Additionally dragging off maximized only gets to be a problem when you have filled your title bar with tabs.

This is an either/or proposition and I would say that tab navigation is more important here.  Even when you consider consistency with other Windows application.

Interestingly for Side-by-Side (half maximized) and Vertical Maximized (when you resize the height to the screen edge) Chrome retains the non-maximized layout for the title bar (it has top-padding). Looking back on my Chrome usage I kept moving back to full maximize when Side-by-Side maximization would be normally preferable because of the loss of the quick mouse tab navigation.  I didn't realize this until this thread.

Ironically, because of this thread I would want to remove the padding when Chrome is in these two alternative Windows modes.

Tom

[Stuart Morgan]

2013/2/14 Benjin Dubishar <ben...@google.com>

On Thursday, February 14, 2013 12:54:42 PM UTC-8, Peter Kasting wrote:

This isn't really the right list for this; chromium-dev is a technical development list.

Sorry; I was recommended here by a Googler on Chrome.  What's the appropriate list for this kind of discussion? 

chromium-discuss

-Stuart