Community
Participate
Working Groups
In the "Feature Plug-in" dialog "Show signing info" does not show the signing info unless dialog is manually resized. To enable high contrast mode: - Open Control pannel - Open Accessibility Options - On the "Display" tab select "Use High Contrast" checkbox
will check to see if this is a regression. I'm surprised that this would happen in high contrast and not in other modes. Reassigning to platform UI.
Oleg, this bug says 3.4.2 but I'm assuming you are referring to more current builds?
Yes, found in 3.5M6.
At first I thought this bug meant the button was non-responsive, but now I understand. The initial size of the dialog is quite small for the larger fonts, so the table itself is cropped and there's no way to scroll it. When the size is this small (smaller than the table in the page), then if you push the signing button, the signing tray is also cropped. In 3.4.x, the initial size of the dialog was more appropriate, and also the size of the shell grew to accomodate the tray. If maximized, the non-tray portions were made smaller to fit the tray. Main problem: - the InstallationDialog hard-codes a default size in pixels, it should use something font-based to prevent this problem. Secondary problem: - the signing tray should either make the shell larger or resize the non-signing part. This problem was introduced because the plug-in details is now hosted inside a page, not a dialog, so the standard TrayDialog mechanism is not used to manage the signing info. In my opinion, this is not critical because the dialog can be resized, and once resized, the default size is remembered, and the user will not see the problem again. Removing milestone, but cc:ing Kevin on a gut check that this is not a "must fix" for 3.5.
(In reply to comment #4) > - the InstallationDialog hard-codes a default size in pixels, it should use > something font-based to prevent this problem. Yes dialog units are always preferred. > In my opinion, this is not critical because the dialog can be resized, and once > resized, the default size is remembered, and the user will not see the problem > again. Since there's an alternate solution then strictly speaking we'd pass accessibility. However, it'd be a poor usability situation for the sight impaired. Thus agree not a "must fix" although quite desirable.
I just realized while looking at bug 269210 why this occurs. Though different symptoms, the root cause is the same for both bugs. I'm going to make a temporary "initial dialog size" fix for 3.5 in the other bug, and will focus/rename this bug on the long term problem. When a dialog is being resized, the "dialog area" will be resized as the shell gets smaller. At some point, then, the tab folder is made small enough that the tab folder arrows kick in. So far, so good. But there's a catch. The dialog area is only made smaller as the shell resizes *until* the button bar minimum size is reached. At this point, the entire dialog contents is simply cropped. The dialog area is no longer made smaller. You'll see buttons starting to get cropped and at this point the tab folder simply gets cropped rather than resizing smaller and smaller. So in dialogs where the button bar is rather lengthy, the width at which the "don't bother resizing the dialog area anymore" width happens much sooner. Once you are in this zone, you end up cropping the tab scrolling buttons, the signing info tray, etc., rather than trying to fit it in. So I will fix the initial size in bug 269210 so that it doesn't open up this way, but I think in the long run we need to consider whether these big rows of buttons at the bottom are going to work. Since any page could contribute any number of buttons, it would be easy to get a button bar that was so large that you would never be able to scroll the tabs. One could also consider this a defect in the dialog layout, but I think we would have to reparent/nest the button bar in order to fix this at the dialog level, and I don't see that happening....
assigning milestone for investigation in 3.6
I think there is also a need to distinguish between commonly used actions and the lesser important ones. For example, on the p2 installation history page, we've just added a "Delete" and "Compare" button. One could argue that these actions are secondary to "Revert" and belong in a more hidden place. (In particular the delete button. It's really only there to manage disk space and shouldn't be a first class action). Perhaps we could consider introducing a mechanism for pages to contribute to a context menu (or the page could do this itself, as the p2 pages do with "Copy."). However I'm concerned about the accessibility of this feature. Carolyn, do you know if it's considered non-accessible to contribute an action so that it is *only* available in a context menu? Are there patterns by which screen reader users go looking for context menus? Since we don't have a menu bar in this dialog (and I don't think we should have one), I'm wondering what our choices are here. Kevin, any thoughts?
(In reply to comment #9) > I think there is also a need to distinguish between commonly used actions and > the lesser important ones. > > For example, on the p2 installation history page, we've just added a "Delete" > and "Compare" button. One could argue that these actions are secondary to > "Revert" and belong in a more hidden place. (In particular the delete button. > It's really only there to manage disk space and shouldn't be a first class > action). [OK a bit meandering, sorry] I agree. Buttons are best for common actions. We have a scaling, usability, and design problem if every action must have a button, for the reasons you stated above. Case in point, I find the "Columns" buttons annoying, since it takes up lots of space yet is rarely used. It's like "Click on Columns! Click on Columns" "Why?" "Oh, no real reason". That said, I'm not sure people think to check the popup for controls in a dialog. And in the dialog in question, some pages have popups, some do not (e.g. Features list doesn't), which maybe un-trains you from looking for them. Same for wizards (generally text fields get one but nobody else). Thus there's a problem with discoverability. A good practice is that everything in a popup should be in a menu bar menu, since these can be scanned quite easily, versus popping up the menu for every control in the hopes there's something more you can do. We don't have menu bars in dialogs. Not sure what to advise here. I agree that buttons don't scale. I thought of a dropdown combo of actions, but that just seems an odd design. So... I guess context menu for infrequent is the right choice. As a data point, in looking at Excel 2007, although there aren't a lot of dialogs, those I can find do seem to have context menus in the controls you'd expect, and actually most everything in the UI has a context menu. I think we're I'm heading is: the way to solve the discoverability problem is to ensure that every dialog control which sensibly should have a context menu (text, lists, tables, but not buttons, drop down buttons) does, even if the menu item is trivial like "copy" (which it turns out is almost always useful anyway!). Then you know to check. Aside: if we really wanted to be consistent with the workbench window, the "Columns" item would be in a little down facing triangle menu, since it's an action on the table control itself, not on the domain objects within the table. > Perhaps we could consider introducing a mechanism for pages to contribute to a > context menu (or the page could do this itself, as the p2 pages do with > "Copy."). However I'm concerned about the accessibility of this feature. > > Carolyn, do you know if it's considered non-accessible to contribute an action > so that it is *only* available in a context menu? Are there patterns by which > screen reader users go looking for context menus? Since we don't have a menu > bar in this dialog (and I don't think we should have one), I'm wondering what > our choices are here. AFAIK it's not an accessibility problem from a motor skills point of view since the popup can be triggered without a mouse, but Carolyn can answer wrt. screen readers.
Well, believe it or not, even after all these years the Mac doesn't have a way to pop up a context menu using the keyboard. *Unless* the screen reader is running... AND the application writes code to detect some key sequence, pop up a menu, and tell the screen reader that the menu is popped up. I began writing this code and didn't finish (probably because other things came up with higher priority). See bug 219305 for details. Anyhow, I am guessing that there's probably a Mac usability guide out there somewhere that says not to put actions only on context menus. It's also on Wikipedia (and if it's on Wikipedia, it must be true <grin>): http://en.wikipedia.org/wiki/Context_menu#Usability Anyhow, not to say "Don't do it", only that you are correct to hesitate. If it's the only way that makes sense, you can nag me to get that Mac work-around going. ;)
(In reply to comment #10) >Case in point, I find the "Columns" buttons annoying, since it > takes up lots of space yet is rarely used. It's like "Click on Columns! Click > on Columns" "Why?" "Oh, no real reason". This one is covered in bug 229086, which I'd like to address while doing this work. Columns is a particular tricky one, because it is only there to handle the accessibility case, since the columns can be resized by dragging the column headers. So we need something that doesn't distract from mainstream scenarios but can be found by users who cannot manipulate the column headers. > Not sure what to advise here. I agree that buttons don't scale. I thought of > a dropdown combo of actions, but that just seems an odd design. So... I guess > context menu for infrequent is the right choice. I've just added "Compare" for two installation configurations in the installation history. It is currently in a button, but as an Eclipse SDK user I naturally think to select two things and popup the menu to compare them. So I think it will come naturally for some actions. > I think we're I'm heading is: the way to solve the discoverability problem is > to ensure that every dialog control which sensibly should have a context menu > (text, lists, tables, but not buttons, drop down buttons) does, even if the > menu item is trivial like "copy" (which it turns out is almost always useful > anyway!). Then you know to check. Bug 266186 addresses adding copy support to all installation pages, and the approach currently used in the code (which is in p2 right now) is to add a context menu (and of course you get the key binding). So perhaps solving several of these bugs at once will make a better story. - we'd always have copy and select all in a context menu for all lists, tables - we could have a separator for pages to add the less common actions - we push for the Mac fix so that it's always accessible I'm going to go read the accessibility guidelines and look at some more apps first...
This may interest you: http://accessibility.freestandards.org/a11yspecs/ia2/docs/html/interface_i_accessible_action.html Read the detailed description. We are currently looking into supporting some of the IAccessible2 interfaces (of which IAccessibleAction is one). No promises yet whether all of this will be supported, but I am noting that you might be interested in providing the data at some point. <g>
Removing the milestone on this bug. I'd like this bug to remain focused on the "do we want some alternate layout for buttons or another way to contribute actions to an installation page?" I don't see that we'll change the way buttons are layed out in the 3.6 timeframe. I'm putting a dependency on bug 266186 only because I think that once we were to surface copy in a consistent way, with a discoverable aspect (context menu?) that might shed light on guidelines about what installation page actions should be in the menu, and which should remain buttons.
*** Bug 308657 has been marked as a duplicate of this bug. ***
Updating the title to correspond to the more general description of the problem, see comment 6.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
