Created attachment 591968 [details] oVirt 3.1 webadmin Description of problem: On engine 3.1, there are too many tabs on the web interface. Unless you shrink the right side menu, a tab will cover up items on the second row. Version-Release number of selected component (if applicable): ovirt-engine 3.1 How reproducible: Depends with screen resolution Steps to Reproduce: 1. Open webadmin on a 1024x768 screen resolution 2. 3. Actual results: One tab is shown on the second row on top of the second row buttons Expected results: None of the secondary menu is covered up Additional info: See attachment
Hi, Could you specify please if this is still reproducible on the latest version? Also, on which browser did it happen?
I can confirm with 3.2.0.4 this is still an issue. I can confirm with IE9 (Win7), IE10 (Win8), IE10 Modern UI (Win8) and I'm working to test Firefox on Windows and Fedora 18 as well as other browsers. I'll post screenshots of each once I finish the testing.
http://s4.postimage.org/s0cf33gt9/FF1901_Ovirt32_Admin.jpg http://s4.postimage.org/q9te1lza5/FF1901_Ovirt32_User.jpg http://s4.postimage.org/chez5z8il/IE9_Ovirt32_Admin.jpg http://s4.postimage.org/4d6v18m3h/IE9_Ovirt32_User.jpg http://s8.postimage.org/9t3aeyyc5/IE10_Mod_UI_Ovirt32_Admin.jpg http://s8.postimage.org/wj2f7yhjp/IE10_Ovirt32_Admin.jpg http://s8.postimage.org/df93rm4ph/IE10_Ovirt32_User.jpg "FF1901" = Firefox 19.0.1 I'm pretty much seeing the same thing across all browers.
Err, I'm seeing the same thing on the admin side. The user side is all ok as far as I can see.
Hi, I've CCed Vojtech Szocs. He's been developing the UI plug-in framework, and he knows GWT inside out. Hopefully he can confirm and/or suggest a fix. Thanks, Dave.
hi. we are aware of this issue, however it will take some time to solve, as we need to decide on the design of the exact solution (we cannot just remove tabs from the tab-panel...), and it requires some thought. thanks.
Hi Einav, Does this mean that 1024x768 is unsupported for oVirt Engine right now? What is the minimum size where the engine behaves correctly? Thanks! Dave.
Einav, that's kinda what I figured. Dave, from what I see, the last button (refresh) finally snaps into place at ~1240px wide in IE9 and ~1248px in Chrome.
Hi guys, as Einav wrote, we need to decide on UI design that supports many tabs in the first place. I'll attach two screenshots to illustrate two design proposals: 1. using scroll buttons 2. using proportional tab widths Note that table action buttons (e.g. New Server) being mis-aligned due to insufficient content width is a whole different issue that should be tracked separately.
Created attachment 707082 [details] proposal1-scroll-buttons
Created attachment 707083 [details] proposal2-proportional-tab-widths
I prefer #1 - looks cleaner
(In reply to comment #12) > I prefer #1 - looks cleaner I agree on cleanliness but imo it would be really annoying to have to click on arrows to move between tabs. Imo, if using overlapping tabs then when focusing on a certain tab (on hover) it should be expanded as well as the one to the left and the one to the right while the rest gradually become narrower Other alternatives: 1. vertical view 2. dedicated page for tabs 3. multiple tab lines 4. Icons instead of tab names I would also consider reordering the tabs according to usage (How much of my time would I actually spend on Data Centers vs. how much on VMs / Disks?
Ayal: I'm no designer, but in general, it's not a good idea to re-order tabs based on popularity/usage - it can lead to confusion and frustration when a tab is not where it has always been because it jumped a threshold and ends up on the left of where it was before. It's better to order them by default based on how often we expect people to use them once, and then not change it at run-time. Another possibility is to show the tabs you can,; and have a drop-down for the overflowing tabs. Yet another possibility is to say "we only support screen sizes of 1280x720 (in 16:9) or 1280x960 (in 4:3) or bigger", and then don't fix it. Whether this is an option depends very much on how many people are still using browsers in 1024x768 screens. I know that GNOME only very recently abandoned 800x600 as a supported screen size (although several dialogs did not really work very well even before then).
(In reply to comment #14) > Ayal: I'm no designer, but in general, it's not a good idea to re-order tabs > based on popularity/usage - it can lead to confusion and frustration when a > tab is not where it has always been because it jumped a threshold and ends > up on the left of where it was before. It's better to order them by default > based on how often we expect people to use them once, and then not change it > at run-time. > > Another possibility is to show the tabs you can,; and have a drop-down for > the overflowing tabs. > > Yet another possibility is to say "we only support screen sizes of 1280x720 > (in 16:9) or 1280x960 (in 4:3) or bigger", and then don't fix it. Whether > this is an option depends very much on how many people are still using > browsers in 1024x768 screens. I know that GNOME only very recently abandoned > 800x600 as a supported screen size (although several dialogs did not really > work very well even before then). Reordering of tabs is indeed not recommended. The UI becomes inconsistent, and it can frustrate users to scan every time all the tabs to find the one they need. Left side pane is actually an alternative view of what the tabs offer. Why not make an easy collapse/expand of that part, so it will leave more room for the tabs area? Are there users working with both views at the same time? In addition, and this is of course a much larger scope than this bug - the tabs are representing very different objects, in different layers of hierarchy , not sure all of them should be there next to each other, so perhaps their number can be reduced. (should users be a tab in parallel to hosts and to disks?)
admins can focus on a specific part of the tree and see only the relevant main tabs to that entitiy. system view is meant to be all encompassing the current order of the tabs is supposed to be around the hierarchy of adding objects to the system and to a degree the hierarchy between them. personally, i never had an issue with the Hosts and VM tabs not being the first ones. there are various concepts discussed here for a larger scope of change. for the concrete one, i actually liked the suggestion by Ayal of using icons, though we should still avoid too many main tabs in general.
I was never a big fan of scroll buttons but this looks way better than proposal #2, the tabs look almost overlapping when their width is too small
From Ayal's suggestions, I like the idea of using icons instead of tab names. However, we should also cover the case when there are simply too many main tabs to fit the area, regardless of tab widths being used. We can't really avoid having too many main tabs, especially considering UI plugins, which can contribute such tabs on their own. Thanks to everyone for providing interesting suggestions, here's a summary of current proposals: (1) To ensure as many tabs fit the area as possible, retaining the horizontal-tab UI design: * [Ayal] icons instead of tab names * [Ayal] have selected tab wider and nearby tabs losing width proportionally (could be sensitive to mouse-over interaction) * have drop-down or similar switch for different tab categories, e.g. virtualization, UI plugins, etc. (2) To ensure hidden tabs that don't fit the area are still accessible: * [Ayal] multiple tab lines * [Dave] have drop-down for overflowing tabs * use scroll buttons for tabs
Forgot to mention one more suggestion for issue (1): let users toggle visibility of specific main tabs (similar to a feature where users would toggle visibility of specific columns in data tables).
Eldan had another suggestion - split the set of main tabs currently on system to several views. for example: - resources: dc, cluster, host, storage, networks - consumption: disks, vms, pools, templates, users, quotas - configure: instance types, other currently under 'configure'
> Eldan had another suggestion - split the set of main tabs currently on system to several views. Sounds good to me, but an important question is visual representation of such 'views', e.g. the ability to switch between different 'views' and access related main tabs. In comment #18 there's a proposal to have drop-down for different tab categories, this could apply to 'views' as well. To me, this sounds like a way to filter main tab panel based on some 'view' or category.
I have two ideas currently to add: Option 1) Swap the tabs to the area where the "search" bar is. That would allow the tab area to have more space. Visually though it would be a little awkward because the tabs would control only the right side of the screen. I still feel the search function is a little big. Option 2) Collapse the "Tree" area when there isn't enough room to view all of the tabs. If the user needs it and expands it, the tabs go into an alternate view (scroll to view more tabs, etc).
> Option 2) Collapse the "Tree" area when there isn't enough room to view all of the tabs. Maybe something like this http://jsfiddle.net/WaX6n/ - allow sliding left-hand panel (Tree/Bookmarks/Tags) to the left to save some space, detect low resolution and start with left-hand panel slided to the left by default.
for qa: need to test the following scenarios: - low resolutions (e.g. 1024x768) - non-maximized window size - left-pane width is significantly extended -> main-tabs view width is significantly narrowed down need to verify that: (1) when main tab panel doesn't have enough real-estate to be fully displayed: * left/right navigation arrows appear in the main tab panel and behave correctly. * tabs-navigation-drop-down-button appears in the main tab panel and behaves correctly [behavior should be similar to the behavior of Firefox browser when there are a lot of opened tabs in it] make sure to test interesting scenarios, which include a lot of main-tabs that are displayed: * 'System' left-pane-tree-node selected * a specific Data-Center left-pane-tree-node is selected * RHEV Reports is installed (i.e. Dashboard main tab is displayed) * RHEV ui-plugin(s) that are adding main tab(s) are installed. * etc. (2) when any sub-tab panel doesn't have enough real estate to be fully displayed: behavior should be similar to the one described in (1) above. Make sure to test a case of many sub-tabs using the ui-plugins mechanism. (3) when any action-button-panel (either in main tab or in sub-tab) doesn't have enough real estate to be fully displayed: an action-navigation-drop-down button appears and behaves correctly. Make sure to test interesting scenarios: Tabs with many built-in buttons (e.g. VMs main tab), tab with a lot of actions added via the ui plugins infrastructure, etc. ** (3) is relevant for the power user portal as well ** all other things (e.g. dialogs, etc.) were not treated in the context of this BZ and should not be tested. Please look for existing BZs or open new BZs for other not-enough-display-real-estate issues. thanks.
see also: http://www.ovirt.org/Features/Design/LowerResolutionSupport
oVirt 3.4.0 alpha has been released including the fix for this issue.
Responded to TCMS plan with some information in emails.
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released