More control of detached tabs

[mbrazil]

Add a context menu to the taskbar button and/or the page displayed in the tab window itself for detached tabs. The menu should include most of the items currently displayed in the context menu for the tab buttons and most of the items in the context menu that is displayed when you right-click on a web page. The following commands should also be included:

Close
Merge
Minimize
Maximize

Here's why I think the context menu is necessary. I frequently open http://www.wunderground.com/wundermap and detach its tab. I have Actual Window Manager set to control the size and position of the detached tab such that it is always on my secondary monitor and so the map itself uses the entire screen on that monitor (everything on the page outside the edges of the map is invisible because it's beyond the edges of the monitor). This also results in the titlebar, the control buttons, and the window borders being inaccessible. Since these window components can't be seen or reached, there is no way to move the window or change its size. There is no context menu at all for the detached tab's taskbar button, and no context menu is displayed when you right-click on the page in the detached tab. Left-clicking the taskbar button has no effect on the window (the button itself changes its appearance from normal to depressed and back, but the window itself is unaffected). I can close the detached tab by first clicking somewhere on the page and then pressing Ctrl+F4, but since the titlebar is invisible, there's no way to Merge the tab back into Avant.

[AbelAbel]

Why did you make the the detach tab so big? You can set it as big as your second screen and hide the sidebar on the right side,thus, you can still make the map full of your screen but with the title bar available.

[mbrazil]

Why did you make the the detach tab so big? You can set it as big as your second screen and hide the sidebar on the right side,thus, you can still make the map full of your screen but with the title bar available.

That wouldn't serve my purpose, and I don't want the title bar to be visible because that would make other things displayed on the page that the map is on visible, and those things take up space. I want the map to take up the entire screen. I already hide the sidebar.

In terms of the context menus, they should be available no matter what. Detached tabs should be as easily managed as regular tabs.

[Jasmine]

Though the edges are out of the second monitor, the tab button of the detached tab stays on the windows task bar, can't you control the detached tab via the context menu of the tab button on the task bar? It includes : always on top, merge,close,minimize,maximize,restore...

[mbrazil]

I've been experimenting with that, and it seems like there is some kind of interaction between the effects of Actual Window Manager and Avant. More often than not, there is no context menu displayed for the detached tab's taskbar button when I right-click it.

[hornakapopolis]

...tab button of the detached tab stays on the windows task bar, can't you control the detached tab via the context menu of the tab button on the task bar? It includes : always on top, merge,close,minimize,maximize,restore...

Am I misunderstanding? I don't have any of those options when right-clicking the detached tab's button on the task bar

In terms of the context menus, they should be available no matter what. Detached tabs should be as easily managed as regular tabs.

Personally, I'd disagree here. Should context menus be available when I'm intentionally hiding the part of the screen that hold them? How would that work? We'd have to have some way of accessing every context menu of every function of every open application even when the application isn't visible. Even if the commands Jasmine is talking about are supposed to be available for detached tabs in the Windows Taskbar, couldn't the argument be made that the commands there should be for the application and not a particular item within the application? If not, then why not include the context menu for the browsing window itself? I think that would make more sense than the tab/tab bar.

I don't see it as much here anymore now that I've been revisiting from time to time, but we used to chime in when we thought the time and additional code on some requests wouldn't be worth it. Personally, from the moment I read this I thought is was bit too specialized of a scenario. "This doesn't work when I do this one specific thing using the function of this second application."

Also, playing around with my detached tab, I can get the context when right-clicking the lowest pixel of the title bar. Below that, there's a pixel wide white area and then the gray border of the browsing window starts. If this other app that automatically extends windows beyond the scope of the screen doesn't have an option to specify the number of pixels, I think that would be a better request to them, have more uses in the future, and fit in more with the functionality of the app

[mbrazil]

Should context menus be available when I'm intentionally hiding the part of the screen that hold them? How would that work?

The context menu for the taskbar button is "held" by the taskbar button, which remains visible. The context menu for the tab window's content is "held" by the rendered page in the detached tab, which remains visible. I don't see your point.

We'd have to have some way of accessing every context menu of every function of every open application even when the application isn't visible.

We already have access to a context menu for every application even when the application isn't visible -- the taskbar button context menu. There are already many context menus in many applications, including Avant, for particular items within the application. A detached tab is a very special case, and adding or modifying a context menu to deal with it's peculiarities when part of it isn't visible wouldn't mean that you'd have to have context menus for other parts of the application that are sometimes not visible.

Even if the commands Jasmine is talking about are supposed to be available for detached tabs in the Windows Taskbar, couldn't the argument be made that the commands there should be for the application and not a particular item within the application? If not, then why not include the context menu for the browsing window itself? I think that would make more sense than the tab/tab bar.

As I said above, a detached tab is a very special and very different thing from a component entirely within an application. Once a tab is detached, it is treated pretty much as if it were a separate application. It gets its own taskbar button, it can be moved separately and independently from the Avant window, and it can be resized to be larger than the Avant window and completely cover the Avant window.

If you'll re-read my original post, you'll see I did suggest including the commands in question in the context menu for the browsing window itself ("Add a context menu to the taskbar button and/or the page displayed in the tab window itself for detached tabs").

While I have requested enhancements to the tab-bar context menus in the past, I didn't mention the tab bar at all in this request. However, I do believe that enhancing the tab-bar buttons' context menus for various purposes would add a great deal of value and flexibility to Avant. It's an area that I think has been overlooked, much to the detriment of the application.

Apparently, the context menu for the taskbar button already exists according to Jasmine's comment. When I wrote the request, right-clicking the taskbar button had no effect, so I assumed there was no context menu. Since then, I can sometimes get a context menu for the detached tab's taskbar button. I've experimented and found that Actual Window Manager has nothing to do with whether or not the context menu is or isn't displayed. It's sometimes available and sometimes not even with Actual Window Manager not running.

from the moment I read this I thought is was bit too specialized of a scenario. "This doesn't work when I do this one specific thing using the function of this second application."

Sizing and placing the window as I do with Actual Window Manager can be done using only the functions available in Windows. Actual Window Manager just automates it, so it doesn't really enter into the scenario. Also, the Wundermap is just an example. I do the same thing with several other sites and with applications other than Avant.

Keep in mind that, just because someone describes a specific scenario in which there's a perceived shortcoming in the application (Avant) that you haven't experienced, or you don't see where you'd ever find yourself in a similar situation doesn't mean that other users won't need the requested improvements in the same scenario, related scenarios, or other scenarios altogether. For some people, lack of access to the commands in question for detached tabs could be the deciding factor in choosing Avant or finding another browser.

Also, playing around with my detached tab, I can get the context when right-clicking the lowest pixel of the title bar. Below that, there's a pixel wide white area and then the gray border of the browsing window starts.

See my reply to AbelAbel earlier in this thread. Because there are other items that are part of the web page above the map itself, it would not serve my purpose to bring the tab window down so that the any portion of the title bar or the pixel-wide white area you say is immediately below it would be visible, in that this would also cause these extraneous portions of the web page to be visible, and these take up almost a quarter of the window vertically.

If this other app that automatically extends windows beyond the scope of the screen doesn't have an option to specify the number of pixels, I think that would be a better request to them, have more uses in the future, and fit in more with the functionality of the app

You really should take a look at Actual Window Manager (http://www.actualtools.com/windowmanager/). It can do many things other than reposition and resize windows, and it already allows me to specify the pixel offset inside or outside each edge of the screen. That's how I'm automatically positioning the window where I have it.

All that said, the existence of the context menu for detached tabs negates the necessity of my request. Now, all that's necessary is to find out why the context menu appears sometimes and not others and to fix the problem. I'll post a new thread in Bug Reports.

[mbrazil]

Though the edges are out of the second monitor, the tab button of the detached tab stays on the windows task bar, can't you control the detached tab via the context menu of the tab button on the task bar? It includes : always on top, merge,close,minimize,maximize,restore...

The context menu for the detached tab's taskbar button does not appear reliably. Prior to when I posted my request, the context menu never appeared. Since then, it sometimes appears but often does not. hornakapopolis also mentioned that the merge, close, minimize, maximize, and restore commands are not included in the context menu he sees for the taskbar button. Apparently, there are problems with the code for the taskbar button context menus. I have started a new thread in Bug Reports regarding this.

[Jasmine]

It will be fixed in next version.

[hornakapopolis]

Keep in mind that, just because someone describes a specific scenario in which there's a perceived shortcoming in the application (Avant) that you haven't experienced, or you don't see where you'd ever find yourself in a similar situation doesn't mean that other users won't need the requested improvements in the same scenario, related scenarios, or other scenarios altogether.

Ya know, I created, organized, and maintained the list of about 700 requests we had here for a few years, so it's not that I'm not open to new functionality that I wouldn't make use of. But in a way, you're making my point. Why should the function you'd want included be the ones included if we're moving things outside the typical design of "application functionality" on this taskbar button? Why not Options, the page context menu, File menu, etc.? When you start designing for the "Because I wanna..." mentality (and that's not intended as harsh as it may look written), the logic of design moves from location and placement to a single person's (or small subset's) individual case.

Also, playing around with my detached tab, I can get the context when right-clicking the lowest pixel of the title bar. Below that, there's a pixel wide white area and then the gray border of the browsing window starts.

See my reply to AbelAbel earlier in this thread. Because there are other items that are part of the web page above the map itself, it would not serve my purpose to bring the tab window down so that the any portion of the title bar or the pixel-wide white area you say is immediately below it would be visible, in that this would also cause these extraneous portions of the web page to be visible, and these take up almost a quarter of the window vertically.

And this is where I'm saying the "specialized scenario" is really coming into play. One pixel? You can't spare one pixel in height? Also, what does all of this setup with Actual Window Manager do that full screen doesn't?

As always I'm a bit worried about tone, so to be clear, all of this should be read as coming from someone that just can't figure out what's going on. Especially the "one pixel" thing. My only thought is that I must not be picturing what it is you're doing correctly. I'm seeing things on this page like "Local," "Region," & "Continent" on the left and a "Map" drop-down on the right, but even they are 5 pixels from the top of the screen.

I don't want to hi-jack this thread, though, with my endless questions, because this is all curiosity, not a request for justification. My initial reply was for exactly what I said it was, but now I'm just trying to better understand what you're talking about.

[mbrazil]

Why should the function you'd want included be the ones included if we're moving things outside the typical design of "application functionality" on this taskbar button? Why not Options, the page context menu, File menu, etc.? When you start designing for the "Because I wanna..." mentality (and that's not intended as harsh as it may look written), the logic of design moves from location and placement to a single person's (or small subset's) individual case.

First, we wouldn't be "moving things outside the typical design of "application functionality." I use several apps that have custom options in their taskbar-button context menus, and I'm sure there are many more. Apparently, Anderson doesn't think that custom options in the taskbar-button context menu are outside typical design, as it turns out the commands I was asking for are already in the taskbar-button context menu. There's a bug (confirmed by xiaobing) that's causing the taskbar-button context menu not to appear at times. Since I'd never seen this context menu, I assumed it did not exist.

As far as "Options, the page context menu, File menu, etc." I did mention in my request that one of the places I thought would be appropriate for these commands would be the page context menu. The File menu would work too, but it's less intuitive, and if you're going to use the mouse, less convenient to get to. As far as Options, are you referring to the Avant Browser Options? That would require several additional mouse clicks and be even less intuitive if all you want to do is merge the detached tab back.

Actually, it's my opinion that many more commands should be duplicated, or in some cases moved to, the context menus for the tab buttons. It's the most logical and intuitive place for them, especially when you consider that some mainstream apps, like Microsoft Office, have done away with the menu bar completely. Any common action you would want to take while working in a tab should be available in both the page and tab-button context menus. The menu bar itself should be reserved for commands that affect the app overall, not specific tabs.

I really don't care about "the typical design of "application functionality" and apparently, there are many developers who don't either based on lots of apps that have been released or redesigned in the last few years. What should be important in interface design is organization, convenience, intuitiveness, and usability. Commands/options should be where they are most likely to be needed and most logical to find. Certain commands/options need to be duplicated in more than one menu, but most of them should only appear in context menus that are reached from within the tab you're working in or its tab button, or in the case of a detached tab, the taskbar button. Putting them elsewhere just makes the app harder and more frustrating to use.

Try putting the background I provided when I made my request out of your mind and think about the concept of putting the tab commands in intuitive context menus. The concept isn't something that relates only to one user. Any and almost every user would benefit from having these menu options where they're quicker and easier to get to and where an inexperienced user would be most likely to expect them to be. Hunting around for the option you need and finding it (if you're lucky) in a place where you didn't think to look first, makes apps extremely frustrating and hard to get used to.

One pixel? You can't spare one pixel in height? Also, what does all of this setup with Actual Window Manager do that full screen doesn't?

Forget about Actual Window Manger for the moment. It's not necessary to use Actual Window Manger to get the window size and position I'm using with this web page. It just automates it. The only reasons I mentioned it in the request are to describe the actual scenario and because Jasmine and Xiaobing are already familiar with Actual Window Manager from other discussions we've had.

I've said this twice already in this thread, but here goes the third time (in different words). The top edge of the weather map on the page in question isn't one pixel below the titlebar -- it's 250 pixels below the title bar. I'm displaying the weather map on a 19-inch monitor running at 1280 x 1024, so readjusting the window size so that one pixel of the titlebar is showing reduces the vertical size of the map by approximately 20%. Stated another way, the stuff above the weather map wastes 2-3/4 inches of the 12 inch height of the monitor. My goal is to have the weather map (not anything else on the page) fill the entire screen on this monitor. I can and do have this working, but doing it makes it inconvenient to merge the tab back or close it, because I can't get to the titlebar, the context menu for the detached tab's taskbar button frequently isn't accessible, and the context menu for the page itself doesn't include the merge command.

As always I'm a bit worried about tone, so to be clear, all of this should be read as coming from someone that just can't figure out what's going on.

I worry about tone too, so please don't take this the wrong way. If you'd gone back to my original post in this thread and reread it thoroughly and carefully, I think many of your questions would have been answered early on.

Especially the "one pixel" thing. My only thought is that I must not be picturing what it is you're doing correctly. I'm seeing things on this page like "Local," "Region," & "Continent" on the left and a "Map" drop-down on the right, but even they are 5 pixels from the top of the screen.

Time for some screenshots:

This is how the map looks when I've got the tab window sized and positioned the way I want it.

This is how the page looks when maximized.

This shows the stuff below the titlebar and above the map that requires me to place the window with its upper portion off the screen.

Note that the toolbars at the top and right edges of the window are custom toolbars that I've created using Firefox and Firefox extensions.

[hornakapopolis]

Is that custom toolbar on the right active in Avant?

Apparently, Anderson doesn't think that custom options in the taskbar-button context menu are outside typical design, as it turns out the commands I was asking for are already in the taskbar-button context menu.

No, you said, "The menu should include most of the items currently displayed in the context menu for the tab buttons..." (and page context menu) and you also happened to include the ones that are/should be there. (As I'm not getting them either on detached tabs.)

I don't bring up those other menus as examples to say they should be placed there, I'm saying what makes "Options" less important than "Save Current page as Image." Really nothing.

I've said this twice already in this thread, but here goes the third time (in different words). The top edge of the weather map on the page in question isn't one pixel below the titlebar -- it's 250 pixels below the title bar. I'm displaying the weather map on a 19-inch monitor running at 1280 x 1024, so readjusting the window size so that one pixel of the titlebar is showing reduces the vertical size of the map by approximately 20%.

Am I wrong, or is what the major problem is here is this:

The map is in a frame and that "Wundermap screen toolbar" is scripted to stop at the top of the page. At my resolution, the screen scrolls down about 3 more pixels after that "faux toolbar" reaches the top of the screen and the shift is barely noticable. I'll admit that you kept talking about the stuff above the map, but I'm still missing where you mentioned that a portion of it didn't scroll. That's why I kept getting confused... I didn't understand how you could fit something on the screen by adjusting and moving the window, but full screen (not "maximize," by the way), wouldn't do the same thing.

But, am I wrong? If that "toolbar" (I hate calling it that, but I'm not sure what else to call it) scrolled past the top of the window, then it could scroll above the titlebar, the bottom single pixel of the titlebar could be moved within the viewing window, and the menu could be accessed. It seems as if I'm misunderstanding, though, because you say you've said everything before, so it would seem that this non-scrolling portion of the page isn't a factor.

[mbrazil]

Is that custom toolbar on the right active in Avant?

It is as long as I use the Firefox engine, which is my default. It would be great if I could add a Merge button to that toolbar, but there's no way to do that unless Anderson makes that function available or someone writes a custom extension for that purpose. Those screenshots are of the Avant detached tab, so what you see is what I've got in Avant.

I also wouldn't mind if the Firefox-generated toolbars weren't displayed in detached tabs, but the way things are, you either have them for all tabs or no tabs, and it's too much trouble to turn them off and on all the time. The Firefox toolbar at the top of the tab window is part of the reason for moving the detached tab window up, since it also takes up space that would be better used to display more of the map.

No, you said, "The menu should include most of the items currently displayed in the context menu for the tab buttons..." (and page context menu) and you also happened to include the ones that are/should be there. (As I'm not getting them either on detached tabs.)

In my request, I said, "Add a context menu to the taskbar button and/or the page displayed in the tab window itself for detached tabs." Currently, there is no context menu displayed for either the taskbar button or the tab page itself when you right-click anywhere within the map portion of the page. Apparently, these context menus should already be there, but there's a bug preventing them from being displayed, and the Merge, Close, Minimize, and Maximize commands aren't included in the page context menu that is displayed when you right-click on a portion of the page other than the map area.

I don't bring up those other menus as examples to say they should be placed there, I'm saying what makes "Options" less important than "Save Current page as Image." Really nothing.

Now I'm confused. Who said anything about "Options" being less important than "Save Current page as Image" or any other command. We're not talking about importance, at least I'm not. What I'm saying is that when you're actually browsing, commands like Options, Default Rendering Engine, and the like aren't needed anywhere near as often as are commands like Find on This Page..., Translate, Merge, etc. It's not about importance. It's about convenience, organization, intuitiveness, and overall ease of use.

Am I wrong, or is what the major problem is here is this:

AvantScreenshotwundermap.jpg

You're not right or wrong about the "Wundermap screen toolbar" preventing me from having the map take up the entire screen. That would only be the case if I thought the best solution would be to have one pixel of the titlebar showing, and while that might work ok, it's not possible due to the way the page is coded, and it would be a workaround, not a problem solution. What you're wrong about is what the root problem is. It's not that a portion of the page won't scroll, it is that the taskbar-button context menu does not appear and the context menu for the tab page doesn't appear when you right-click on the map. If those context menus are available and the Merge command (primarily) is added to the page's context menu, all the other issues are extraneous.

I'll admit that you kept talking about the stuff above the map, but I'm still missing where you mentioned that a portion of it didn't scroll. That's why I kept getting confused... I didn't understand how you could fit something on the screen by adjusting and moving the window, but full screen (not "maximize," by the way), wouldn't do the same thing.

But, am I wrong? If that "toolbar" (I hate calling it that, but I'm not sure what else to call it) scrolled past the top of the window, then it could scroll above the titlebar, the bottom single pixel of the titlebar could be moved within the viewing window, and the menu could be accessed. It seems as if I'm misunderstanding, though, because you say you've said everything before, so it would seem that this non-scrolling portion of the page isn't a factor.

No, I didn't mention anything about it not scrolling, because I thought that was obvious if you viewed the page I included the link for, and I didn't think anybody could get confused by it. If it could be scrolled out of the window, I probably wouldn't have moved the titlebar completely off-screen in the first place, but the problem with the context menus would still exist. I didn't mention the scrolling issue in my request, because it seemed like an excess amount of unnecessary detail that would just confuse the issue. Maybe it would have been better if I hadn't mentioned the specifics at all and just asked for the context menus and menu commands. You're focusing on the specifics of my example rather than the generic problem as it exists.

Since my desktop is extended from my primary monitor onto my secondary monitor, choosing full-screen causes the detached tab's window contents to use all the available space on both monitors completely, which is an even worse situation.

The only problem is that I can't get to the Merge and Close commands, and that will be resolved when the problem with the taskbar-button context menu is fixed. I know I can close the tab window with a keyboard command, but there's no keyboard command for Merge, and when I'm browsing, I tend to use my trackball much more than the keyboard. Believe it or not, I've been using computers for about 50 years (my first job was with IBM), so I'm a long-time keyboard user and can touch type quite well. However, since I switched from a mouse to a trackball about 12 years ago, I find I actually prefer the trackball to the keyboard for a lot of things other than entering and working with text. I've also got a big old cat that loves to lie on my lap when I'm in my office, and since I use a trackball rather than a mouse, I can move my chair back from the keyboard to give him room and still control the browser for most things with the trackball.

As far as my reason for moving the window up as far as it is in the first screenshot, I don't want anything showing above the map. I could live with a single pixel of the titlebar, but to get it, I'd have to bring the window down like it is in the second screenshot. Yes, I could position the window so one pixel of the titlebar is visible, and if that's all the vertical area I'd lose, it would be fine, but that's impossible because, as you say, the remaining portion of the web page cannot be scrolled out of the window.

This brings up another issue. Some people seem to assume that the page developer should be in charge and the user shouldn't have full control of how a page is displayed. I think the opposite is true and that the user should have full control of how he/she views the contents of a page. I also believe that maximum user control and flexibility are important and necessary in a web browser. That's why I use Avant -- it gives me more control than any other browser I've found. Adding features, making commands and settings more easily and more intuitively available, and providing the user with all the tools necessary to achieve full control of his/her browsing experience fit right in with the basic concept of Avant. Confining Avant to conventional user-interface norms is the opposite of Avant's basic philosophy.

[mbrazil]

Something else I meant to mention in my last paragraph:

There is a very good analogy between users having full control of how a page is viewed and TV viewing. I'm sure the TV programmers and network management would much rather that mute buttons didn't exist on remotes and that there would be no way to record a show and then fast-forward through the commercials. The bottom line on this is that the customer (user) is always right. If you force users to view advertising or anything else they don't want to see or hear, they'll either find a way to get around it or stop viewing your page. Web developers and IT folks who think they should be in control and users should not are fighting a steep uphill battle and can never win. Power to the people.

There are, of course, exceptions to this. In a corporate or other institutional setting, it is sometimes necessary to deny some users access to certain settings and certain content, for reasons of stability, support costs, and security. However, for home users and some users in institutional settings, users should have complete control.