Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One that's never occurred to me as a rule:

"When using type within an interface element, it either sits on top (dark 1px drop shadow) or is inset (white 1px drop shadow), it's never at the same surface as a button or widget."

Will have to pay more attention next time I'm doing this.



When he says 'interface element', do you take that to mean a button or what? In one sense, everything on the screen is an 'interface element' ...


I take it to mean any interface element you're making in Photoshop -- buttons, nav, etc.

Now that I think about it, I stick to CSS most of the time and try to keep images to a minimum (front-end optimization is a tough habit to kick), so I may forget this by the time the next occasion arises.


For newer browsers (ff3.5, new safari and webkit) there are css3 commands you can use to provide this kind of eye candy simply. You can add a drop shadow to text (-moz-text-shadow, -webkit-box-shadow, or generally text-shadow), Or to elements (-moz-box-shadow, -webkit-box-shadow or generally box-shadow). Or rounded corners (border-radius).

Given that these elements are only eye candy, I don't worry too much that they are invisible on IE and older browsers. Think of it as free candy.


Only eye candy? I would not underestimate the importance of an application's visual aesthetic. As the author demonstrates, even subtle details (like a 1px drop shadow) can breathe life into an interface.

We developers might dismiss 1px drop shadows an unimportant; after all, the "real" application is the code we write. But users make no such distinctions. To them, the interface is the application.


IE supports this kind of effect via the filter: CSS property. MSDN has tons of information on this. (I'm not saying this is a nice way to implement it, but it does at least work)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: