You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by ahgittin <gi...@git.apache.org> on 2018/11/08 12:42:34 UTC
[GitHub] brooklyn-ui pull request #99: make palette icons have a light border not a s...
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-ui/pull/99
make palette icons have a light border not a shadow
gives it a nicer flat look
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/brooklyn-ui palette-border
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/brooklyn-ui/pull/99.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #99
----
commit 150b0cb3849a515537edfe67756fe13467b31164
Author: Alex Heneveld <al...@...>
Date: 2018-11-08T12:41:46Z
make palette icons have a light border not a shadow
gives it a nicer flat look
----
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by tbouron <gi...@git.apache.org>.
Github user tbouron commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
Sounds good. Thank you @ahgittin, I'm happy with that
Merging now
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by tbouron <gi...@git.apache.org>.
Github user tbouron commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
You are right, elevation doesn't necessarily means draggable. What I meant is that MD is based on our physical world, for instance:
- the canvas is a sheet of paper
- the side panel are smaller sheets of papers on top of that
- each items on the palette could be either directly drawn on the side panel paper or added as small squares of paper. In this case, we want to drag items onto the canvas, therefore taking items and dragging them onto another container. It then should be laid out as small square of paper.
MD defines "each layer as a separate piece or UI". These layers are represented by the concept of elevation, that is why I'm saying should keep the box shadow.
I get that you have a strong preference to change the styling to a border but as you said, that is subjective compare to (I hope) the explanation I gave above and the consistency that a design system such as MD brings to the table.
---
[GitHub] brooklyn-ui pull request #99: make palette icons have a light border not a s...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/brooklyn-ui/pull/99
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
this isn't the panel, it is the palette icon rectangles which have the shadow. IMO MD could argue the case here either way, they are the normal primary actions thus aren't elevated, or they are float because they are draggable in which case they are elevated. my design sense prefers the former (and so i make this PR) because the value of the shadow is to draw attention to something, but where we have lots of things if they all have the shadow (as in this palette) it voids that benefit. also it looks a bit nicer to my eye.
compare the old:
<img width="1479" alt="shot1" src="https://user-images.githubusercontent.com/496540/48403620-38a65b00-e726-11e8-90a3-bf36943ac683.png">
with the new:
<img width="1523" alt="shot2" src="https://user-images.githubusercontent.com/496540/48403694-5c69a100-e726-11e8-8b26-1d3f55cf1af4.png">
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
I get that Thomas, but the squares of paper when resting on the table don't cast a shadow, at least not until you pick it up. This is how the new Google Mail does it with the list of emails -- they get the shadow when you hover as though that's when you are dragging it.
How about a compromise with a subtle shadow when resting (PR updated):
<img width="1432" alt="screenshot 2018-11-21 at 10 28 11" src="https://user-images.githubusercontent.com/496540/48835506-307a9b00-ed78-11e8-8389-b942e2fdb98a.png">
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by tbouron <gi...@git.apache.org>.
Github user tbouron commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
The box shadow is there to indicate a notion of hierarchy. The side panels come on top of the canvas, not beside it, i.e. they don't push the canvas to left or right.
Material design says that in this particular case, the panel should be "elevated", same as a piece of paper on top of another one. This creates a shadow, reflected by the box shadow there currently is.
Brooklyn UI was created with material design in mind. It is poorly executed in a lot of places but still. I think it make sense to keep this notion of hierarchy as it fit with what it's doing
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by tbouron <gi...@git.apache.org>.
Github user tbouron commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
@ahgittin Ah I didn't realise you were talking about the rectangles!
I get your point and it is valid. Or rather it was valid until https://github.com/apache/brooklyn-ui/pull/96. Items are now added to the canvas only via drag & drop. This is the primary action, displaying the popover on click is a secondary action for convenience.
As such, we should keep the rectangles elevated to convey that they are a draggable items
---
[GitHub] brooklyn-ui issue #99: make palette icons have a light border not a shadow
Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-ui/pull/99
good point although #96 also allows clicking then you get an "add" button. also there are things in MD which are draggable but not elevated; elevation implies more than draggabililty but some importance to the thing being elevated which isn't wanted here. so the elevation makes it busier which negates the cognitive hint that it is something you should drag, the thin line is easier on the eye and easier to work with. but it is a subjective aesthetic decision -- which do you prefer (1) visually, and (2) according to the dogma of MD?
for me, (1) is strong pref for thin line; (2) is on the fence, so thin line wins.
---