Community
Participate
Working Groups
Andree Proulx has come up with some palette UI look and feel changes. - different Palette header and icon - white content area instead of grey - slight gradient on drawers See attached screenshots.
Created attachment 36995 [details] Screenshots of suggested changes
I like the drawer header. Could you indicate which system color you have mapped that to? Also, GIF attachments are easier to analyze than word docs. A white background has always been supported in the palette when using templates, which can not be pressed. But, tools are toggle buttons which must display a pressed state, and this is not easy to acheive on top of "white", which is really just LIST_BACKGROUND and could be any color.
Created attachment 37739 [details] Mockup showing how hover and select will work Note: This is still a work in progress.
Created attachment 37740 [details] Color descriptions Note: Use the SWT Color Matrix.
I have many more mockup images in my inbox, but I'm not sure how to get them into bugzilla. Let me know if anyone needs them.
Created attachment 38964 [details] The latest blueprint This is the updated file that is with the previous mockups.
Thank you Jin for adding the blue print. The attached file in comment #6, concludes our design effort.
No plans to address this in GEF 3.x
I did not realize this bugzilla existed when I raised Bug 204631 . I will reopen this bug to at least indicate the work is planned for GEF 3.4 .
Do not implement a design based on a proposal from April 2004.
(In reply to comment #10) > Do not implement a design based on a proposal from April 2004. Andree is in the IBM media design center and will be revisiting her design.
*** Bug 204631 has been marked as a duplicate of this bug. ***
*** Bug 187266 has been marked as a duplicate of this bug. ***
Missed M5, so moving to M6
Created attachment 89312 [details] Updated blueprint.
Created attachment 89406 [details] Patch for palette UI enhancements. I am attaching a patch containing the changes in GEF required for the palette UI enhancements. The patch: - adds the concept of a palette toolbar which has been configured in the GEF Shapes Example - changes to palette title and minimized look - new colors/gradients for many palette items - new pinned/unpinned icons and selection feedback - new hover and selection feedback on palette items - change of layout of stack arrow especially with icon-only mode - new look for palette scroll buttons
Created attachment 89408 [details] zip file of icons I've also included the zip file of new/changed icons for testing purposes.
Randy: I was wondering if you would be interested in testing out in your application the new GEF Palette UI Enhancements that I have made under the direction of the UI team. The patch and icons are attached. If you would also like to do a code review, feel free to take a look at the code or I can explain any changes I have made.
Pratik or I will check this out, but not his week. But I do have some comments/questions about the updated blueprint: Does the patch implement the blue-prints exactly? If so, I'm wondering what a sub-drawer is. Are these the current Stacks? What do sub-drawers look like in Column layout instead of List layout? Feedback: The sub-drawer's triangle requires all entries to be indented, which seems like a waste of valuable space, especially if your palette doesn't even use sub-drawers. Having the pin icon displayed on closed drawers is meaningless to me. The fact that a drawer will not auto-collapse is only interesting when the drawer is expanded. What happens if I pin a closed drawer? Should it expand too?
Created attachment 89437 [details] blueprint of stack in icons-only mode Thanks, Randy. To answer your questions: Does the patch implement the blue-prints exactly? If so, I'm wondering what a sub-drawer is. Are these the current Stacks? What do sub-drawers look like in Column layout instead of List layout? --> The UI team calls stacks sub-drawers. One of the drawbacks of the current stacks is that if the user is repeatedly using tools off a stack it is tiresome to have to continually open the stack; therefore, we wanted to provide the ability to pin a stack open when being used heavily. I have not implemented this yet, this is the next step I will be doing. I have attached a blueprint of the stacks in Icons layout. I am assuming they may look similar in Column layout, but I don't think the UI team has done this blueprint yet. The sub-drawer's triangle requires all entries to be indented, which seems like a waste of valuable space, especially if your palette doesn't even use sub-drawers. --> I had the same comment, but the UI team said they like the indented look because it differentiates more between the drawers and what is inside them. Having the pin icon displayed on closed drawers is meaningless to me. The fact that a drawer will not auto-collapse is only interesting when the drawer is expanded. What happens if I pin a closed drawer? Should it expand too? --> The pin is only enabled if the drawer is expanded. I agree that the pin makes no sense when the drawer is closed. I will ask about that.
> --> The UI team calls stacks sub-drawers. One of the drawbacks of the current > stacks is that if the user is repeatedly using tools off a stack it is tiresome > to have to continually open the stack; therefore, we wanted to provide the > ability to pin a stack open when being used heavily. Right, this is a real problem. I even filed a related patent for this a few years back: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220070186183%22.PGNR.&OS=DN/20070186183&RS=DN/20070186183 But this solution creates a problem greater than or equal to the one being solved. Stacks are used because you have run out of space. If we start reserving space for a triangle that wasn't needed, now we're part of the problem, forcing clients to use stacks because we no longer layout efficiently. If the user want to repeatedly use tools in the same stack, they can already customize the palette and un-stack the entries. BTW, the term "Stacks" has been exposed in the UI and therefore existing documentation (downstream products), so I don't think the term could be changed very easily. > --> I had the same comment, but the UI team said they like the indented look > because it differentiates more between the drawers and what is inside them. The indentation may look better, but it is not worth the cost to loss of space.
Randy, how does the user unstack the entries when customizing the palette? It doesn't seem to be supported at the GEF level in the Customize Palette dialog (at least I can't seem to do it in the Shapes example).
The logic example *should* allow this (although it doesn't persist your changes across sessions). You simply move the entry up out of its stack and into the drawer.
Randy, thanks for your feedback. Here are some of our thoughts behind some of our design directions (in response to your comments): We added the pins to the closed state to allow a smooth transition (visually) from the open to closed state (so you don't have pins appearing and disappearing causing a blinking action).... however, I do see your point. Maybe what we could do is add a disabled pin when the drawer is closed (indicating that the pin can not be suppressed), which will turn into an enabled state when the drawer is open... which will address both of our concerns. Otherwise, I'm not against removing them altogether, as it really has no functional purpose. As for the allotted twistie/triangle space on the left side... I still believe it is important to have the items line up (like in a tree view) and not zigzag, so the user can quickly and easily scroll down with their eyes and easily make an association as to what drawer level they are in. Second, we will need to keep the twistie on the left, so that the top level item can have a pin on the right side. I understand your concern about space, but this indent only appears in the list view, where each item is assigned a horizontal cell, (so no other items need to be squeezed in beside it) and reducing the width won't allow more items to be displayed. Yes, it may allow the user to have a little more of the drawer text showing - but I believe adds less value than easy navigation. If the user is concerned with space, they will likely switch to icon only or column view where each item has a twistie on the right side that doesn't take up too much space. As for the stacked items, I understand what you are saying, and this is something we should eventually address. This item will require some further design and implementation investment. Maybe we can pursue this a little further in one of the future cycles, as we are really limited for time this cycle. Maybe you could document this for us by filing an RFE so we can try to address it in the future? Thanks again for your comments.
You have faithfully implemented the blueprint, great work! Here is my comments on the patch: When you have hidden the palette in the editor and hover over the bar, the palette expands for you to quick select tools. The palette header is missing in this mode. In the logic example, close both drawers. Now click on the drawer to open both again. it is stuck and I could not open both drawers. If you pin you can open both, but this is a regression. In terms of the code itself. Suggestion for the colours: I would rename PaletteUtil to PaletteColorUtil. The changes made to ColorConstants in draw2d need to be moved to PaletteColorUtil (thus removing any draw2d changes from the feature). I would move all the colour definitions to PaletteColorUtil. Note that the palette could reference the colours in PaletteColorUtil and not ColorConstants as well, but you would have to add more colours to PaletteColorUtil (I think). LEFT_ARROW and RIGHT_ARROW need to go in InternalImages and not FlyoutPaletteComposite. Otherwise I could not see any other issues in the code.
Hi Cale, I have to agree with Randy that pins on closed drawers do not make any sense, although I think you agreed to remove them. The slider is one pixel wide. I found it difficult to get my mouse to stick so I could resize the with of the palette. All other sliders in Eclipse are at least three pixels, we need to do the same (i.e. put the slider width back to its original size).
> We added the pins to the closed state to allow a smooth transition (visually) > from the open to closed state (so you don't have pins appearing and > disappearing causing a blinking action).... however, I do see your point. Don't the Xs blink all over the place in eclipse already? e.g., when activating a view/editor or mousing over its tab. The Xs were hidden because they created too much noise, just like the pins would here. > As for the allotted twistie/triangle space on the left side... I still believe > it is important to have the items line up (like in a tree view) and not zigzag, In the current palette, everything lines up because nothing is indented. No one has suggested only indenting stacks. The problem with using a tree view is that the majority of clients want a list or a grid. > so the user can quickly and easily scroll down with their eyes and easily make > an association as to what drawer level they are in. Neither the headers nor the tools are indented. Tools in a sub-drawer have the same indentation as items outside the sub-drawer. The sub-drawer's background spans the entire width of the palette, just like the drawer it's in > keep the twistie on the left, so that the top level item can have a pin on the > right side. I understand your concern about space, but this indent only > appears in the list view, The last blueprint shows the twistie also on the right side of icons in icons-only (and I'm assuming column) modes. Currently the decoration is an overlay on top the icon, just like in PhotoShop. > If the user is concerned with space, they will likely switch to > icon only or column view where each item has a twistie on the right side Actually, *none* of my items would have a twistie on the right side because I don't have any stacks on my palette. Now, I would have this dead space on the right side of every button, consuming space and making the icons appear off-center. If the palette ships like this you'll see GEF clients rolling their own palette replacements.
Created attachment 90466 [details] Updated patch. Additional changes made with this patch: - PaletteColorUtil changes as Anthony suggested. - Removed DropShadowBorder figure in SliderPaletteEditPart. The addition of the wrapper figure causes the issue where two drawers cannot be expanded at the same time. I do not know of a simple way to show the drop shadow border below the last closed drawer without and because it will so rarely be shown, I am suggesting we omit this shadow border. - Fixed painting of gradient on hover help on drawer toggle figure when the text is truncated to match that on the drawer toggle figure. - Removed pins from closed drawers. - Changed the palette slider width to 3 pixels when the palette is expanded and updated the colors. - Added a few more lines to the palette sash to make it look more like the mock-up when the palette is collapsed. - Fixed issue in FlyoutPaletteComposite where palette title was disappearing when minimizing the palette. Actually, this was the behavior before, but since the palette title was appearing on the sash it was ok. Adjusted the button size in the sash to match the button size when the palette is expanded.
Committed the first patch to HEAD. We will want to resolve this Bugzilla as fixed and then raise a second Bugzilla for the next patch. This way we can correctly record the contributions in to IP log.
(In reply to comment #29) > We will want to resolve this Bugzilla as fixed and then raise a second Bugzilla > for the next patch. I think the build tools also want the Bugzillas in RESOLVED state.
I created Bug 220381 to address the new look for the stacks.
Is there a plan to distinguish templates from tools?
I created Bug 220563 to handle updating the UI for PaletteTemplateEntries. I missed this.
(In reply to comment #32) > Is there a plan to distinguish templates from tools? Is there an example that exposes templates? Maybe in a product somewhere?
I had a discussion with Pratik about the use of templates. They are not exposed in the GEF examples, but can easily be added by creating a PaletteTemplateEntry instead of a CombinedTemplateCreationEntry. They are entries on the palette just like tools, but you can't click and drop them, only only drag and drop them to the diagram.
The JSP Snippets view in the Web Tooling part of RAD uses templates because, I think, the "push button" or "active tool" scenario didn't make sense for them.
Okay, I had the chance to play with and test the new palette a little bit today (using the 0311 build). Here's my feedback: First, a few regressions and bugs I noticed: 1) Can't drag the palette while it's in flyout mode anymore 2) The palette flickers when it opens. It seems like it's laying out twice. First everything gets laid out and then the palette header is added at the top causing everything to move down. 3) Mouse-wheel scrolling doesn't work in drawers anymore. 4) The pin open action next to the drawer's name says "Pin Open" even when the drawer is already pinned open. Now that it is not a toggle button, it should say "unpin" or something like that. 5) The scrollbar seems to change color when I click on it to scroll. 6) The focus rectangle and selection rectangle are not consistent in the list layout mode. Click a palette entry in the list layout mode, and then hit the down arrow key and then the up arrow key again to see the problem. The focus rectangle is around the whole thing, whereas the selection rectangle does not stretch out all the way. I think it should stretch out all the way just like the focus rectangle. 7) There's no more feedback when resizing the palette via the keyboard. Is that what Eclipse does as well? A few usability concerns: 1) I did not realize that the palette entries were not going to be push buttons anymore. This is a huge change, and I think a usability concern since the current flat selection does not indicate a tool being loaded or active. Is there a reason for this change? And how are tools different from templates now (I haven't yet tested out the new UI for templates)? This change definitely gets a -1 from me. 2) Having the stack drop-down on the left while in list layout is not consistent with the other layout modes. And it's counter-intuitive when compared to any combo/drop-down. Since we don't have stack expansion, we should move the drop-down to the right. This would empty up the space on the left, and I think we should decrease the amount of indent (or completely remove it). The original intention was to distinguish the entries from the drawer, but with their different backgrounds now, they're sufficiently distinct already. Andree's screenshot looks good with a few stacks in a drawer, but if you have no stacks, it doesn't look all that good. So, even if we can't remove the indent (which would obviously be the case if we decided to support stack expansion), we should probably decrease it. 3) The scrollbars don't seem tall or wide enough.Is there a reason to not make them stretch out all the way? In the older palette, we also used to gray out what was underneath the scrollbar, which is not being done anymore. That makes it hard to see. Try it in the logic example in the details mode. Also, where are these scrollbar (and selection) colors coming from? They seem random. Andree, I'd appreciate if you can answer any of my usability concerns. I think we should also get the community's feedback about this new palette. Anthony, do you want to send a post out on the gef mailing list (with some screenshots perhaps) and ask people to provide feedback on this bug report? I can do it, but I thought you'd be the right person to solicit feedback.
In reply to comment #37 - usability concerns Thanks for your feedback Pratik, Here is some of the rationale behind those decisions... 1) Push buttons - Instead of the push buttons we have introduced the orange/blue hover and select treatment. When the user is hovering over an item, visual feedback is presented in the orange (instead of the raised button visual) and upon selection (and when active), the item switches to blue (instead of the suppressed button). So, although the new selection has been modernized visually, they still provide consistent visual feedback as to their state. 2) Left side dropdown vs right side - We have added the drop down to the left side to accommodate the pin feature on the right hand side in the opened drawer. This allows the top-most palette item to live in the header area to conserve space vertically. This left hand drop down is consistent with new features found within new products like Jazz. 3) Scroll size and treatment - We have decreased the overall size of the scroll and have proposed the transparency to allow the user to see more of the next palette item and the related visual or icon. As well, the current scroll is quite large based on its action, so we have made the attempt to reduce the overall footprint to conserve space within the view. As for the text below the scroll, it should in fact be grayed out and the scroll area should turn solid orange or blue upon hover or selection as per the specs – I will follow up with Cherie on that item.
Thanks for testing this out Pratik. With regards to the regressions you noticed... 1) Can't drag the palette while it's in flyout mode anymore --> I never tested this. Hmmm, looks like the previous behavior was to support dragging of the palette when hovering over the vertical title bar and resizing of the palette when hovering over the blank area. Now, we no longer have the title bar just the blank area. Any ideas how I should distinguish between moving and resizing? 2) The palette flickers when it opens. It seems like it's laying out twice. First everything gets laid out and then the palette header is added at the top causing everything to move down. --> I don't notice this with the GEF Logic Example. Were you using one of the examples? I just notice that the palette's "hide palette" arrow on the right of the header is delayed slightly in getting painted, but this behavior existed before. 3) Mouse-wheel scrolling doesn't work in drawers anymore. --> Is there a trick to get this to work? I can't seem to use the mouse-wheel to scroll with the old code either. 4) The pin open action next to the drawer's name says "Pin Open" even when the drawer is already pinned open. Now that it is not a toggle button, it should say "unpin" or something like that. --> I will change this. 5) The scrollbar seems to change color when I click on it to scroll. --> Do you mean it changes from orange to blue? It was supposed to. It's the 'pressed down' effect I guess. 6) The focus rectangle and selection rectangle are not consistent in the list layout mode. Click a palette entry in the list layout mode, and then hit the down arrow key and then the up arrow key again to see the problem. The focus rectangle is around the whole thing, whereas the selection rectangle does not stretch out all the way. I think it should stretch out all the way just like the focus rectangle. --> Good point. I will make the focus rectangle match the selection rectangle. The UI team did not want the selection rectangle to stretch out th whole way. 7) There's no more feedback when resizing the palette via the keyboard. Is that what Eclipse does as well? --> What keystrokes do I use to resize the palette via the keyboard? With regards to your UI concerns... 1) The blue color is meant to be used when the tool is active. I do notice one scenario in GMF diagrams when I press the enter key when using the keyboard to traverse the palette that the selection feedback on the tool does not show blue. I will look into this scenario. Maybe I am missing some scenarios where a tool is being loaded or active. What case are you talking about in particular? 3) I will grey out the text below the scroll buttons.
Pratik, Can you raise a new bugzilla to track these bugs? Thanks.
(In reply to comment #38) > 1) Push buttons - Instead of the push buttons we have introduced the > orange/blue hover and select treatment. When the user is hovering over an item, > visual feedback is presented in the orange (instead of the raised button > visual) and upon selection (and when active), the item switches to blue > (instead of the suppressed button). So, although the new selection has been > modernized visually, they still provide consistent visual feedback as to their > state. Modernizing it is fine, but changing it from a toggle button look to just selection is different. It looks more like an item in a list right now (like in Windows Explorer). And most people don't think that clicking somewhere would cause the selected item to be dropped there. > 2) Left side dropdown vs right side - We have added the drop down to the left > side to accommodate the pin feature on the right hand side in the opened > drawer. This allows the top-most palette item to live in the header area to > conserve space vertically. This left hand drop down is consistent with new > features found within new products like Jazz. My comment was more regarding the implementation than the design. In the design, it's more like a tree and hence I agree that expansion triangle should be on the left. In the implementation, there's no stack expansion: it's still a combo box but with the dropdown arrow on the left instead of the right. Stack expansion should be separate from this work item (which is simply about palette look refresh) because it's a new feature. And I suspect it's quite a big change as well. The two blueprints in comments 15 and 20 still leave a lot of questions unanswered, so adding this feature might not be feasible at this point. Anthony, are you planning to implement this feature this milestone?
(In reply to comment #39) > 1) Can't drag the palette while it's in flyout mode anymore > --> I never tested this. Hmmm, looks like the previous behavior was to support > dragging of the palette when hovering over the vertical title bar and resizing > of the palette when hovering over the blank area. Now, we no longer have the > title bar just the blank area. Any ideas how I should distinguish between > moving and resizing? Well, in the flyout mode, the user can still see the horizontal palette header when the palette comes up and he's still able to dock from there. So, maybe this is not that big a deal. He just can't dock it while it's in the collapsed flyout mode. If you want to support that, you can add a vertical palette label again. That also might not be bad because I think the current collapsed flyout palette is a little difficult to find. It camouflages into its environment a little too well. ;-) Maybe Cale or Andree might have some ideas here. > > 2) The palette flickers when it opens. It seems like it's laying out twice. > First everything gets laid out and then the palette header is added at the top > causing everything to move down. > --> I don't notice this with the GEF Logic Example. Were you using one of the > examples? I just notice that the palette's "hide palette" arrow on the right > of the header is delayed slightly in getting painted, but this behavior existed > before. Yup, I was using the GEF Logic example. If you can't reproduce, just ping me on Sametime, and I'll demo it for you. > > 3) Mouse-wheel scrolling doesn't work in drawers anymore. > --> Is there a trick to get this to work? I can't seem to use the mouse-wheel > to scroll with the old code either. I can scroll with my ThinkPad trackpoint in 3.3, but not in the new palette. I am surprised you can't. Again, I can demo this if you ping me. > 5) The scrollbar seems to change color when I click on it to scroll. > --> Do you mean it changes from orange to blue? It was supposed to. It's the > 'pressed down' effect I guess. Okay, maybe it needs to be rethought then? The scrollbar is blue by default. When I go over it, it becomes orange. I click on it, it becomes blue and scrolls. When scrolling is done, it becomes orange again (since my mouse is still over it). And then when I move my mouse to go select an entry it becomes blue again. > > 6) The focus rectangle and selection rectangle are not consistent in the list > layout mode. Click a palette entry in the list layout mode, and then hit the > down arrow key and then the up arrow key again to see the problem. The focus > rectangle is around the whole thing, whereas the selection rectangle does not > stretch out all the way. I think it should stretch out all the way just like > the focus rectangle. > --> Good point. I will make the focus rectangle match the selection rectangle. > The UI team did not want the selection rectangle to stretch out th whole way. Another reason that I think this looks more like a selection in a list rather than a push button. > > 7) There's no more feedback when resizing the palette via the keyboard. Is > that what Eclipse does as well? > --> What keystrokes do I use to resize the palette via the keyboard? Use the palette header's context menu.
(In reply to comment #40) > Pratik, > Can you raise a new bugzilla to track these bugs? Thanks. Bug 223712 created.
> 1) Push buttons - Instead of the push buttons we have introduced the > orange/blue hover and select treatment. When the user is hovering over an item, > visual feedback is presented in the orange (instead of the raised button > visual) and upon selection (and when active), the item switches to blue > (instead of the suppressed button). So, although the new selection has been > modernized visually, they still provide consistent visual feedback as to their > state. The use of a solid orange background for hover, or solid blue to indicate "toggled", doesn't seem consistent with anything else I can think of in eclipse, or even the windows or OS X operating systems for that matter.
Pratik, to answer your question, I am planning to deliver the new look for the pinnable stacks by next Monday.
Hmm, okay, a few questions about palette stacks then: 1) How do you pick something else in the stack? Does the user have to expand the stack and pick the new tool and that would close the stack again automatically? If not, opening a stack is going to cause the palette to layout again? 2) How does this work in all the different layouts? In the blueprint in comment 20, is the dropdown covering up other palette entries? What happens when the user pins that and another stack on the same row open at the same time?
1) Yes. 2) The expanded stack pushes down the other entries in the palette. In icons and columns layout mode only one stack can be opened at a time. We tried to come up with another design that would allow two palette stacks to be opened in the same row, but decided to go with this approach instead. I can send you a patch with my code so far if you want to try it out. I'm just fixing some remaining bugs.
I'll just wait until next week to play with it. And we should probably wait until those changes are in before we request feedback from the community.
Comment on attachment 89406 [details] Patch for palette UI enhancements. This patch does not seem to have been applied, thus marking as obsolete.
