Designer News
Where the design community meets.
Web User Interface Designer at UW Health Joined over 9 years ago
Couldn't agree more.
Focusing so much on the mark itself is missing the point — nothing is created without context. Criticizing a logo and ignoring its support structure is like criticizing a song because of its time signature ("Oh great, another 4/4. What happened to creativity?").
If you can own a shape — color, pattern, angle, whatever — your logo becomes about as important as a stamp. At that point, even spelling out your name can be unimportant.
A simple, memorable (if indistinct) mark is actually advantageous when these are your goals. It gives you flexibility to grow and build, where something highly specific can often paint you into a corner.
This launched a couple weeks ago, but nonetheless quite nice.
Love where all this is heading. Comet is really compelling so far.
One feature I've been dying for is CSS-style management in-app.
Even if it were abstracted into UI (like layer/object styles in photoshop and indesign) and only a subset of CSS ("style" rather than "positioning" — like color, font-size, line-height, background, etc), it'd be great.
Illustrator has a version of this in the "CSS properties" panel, but it conflicts with the paragraph/character styles and appearance panels. If I could manage all object/paragraph/character styles within a single panel that actually editable with CSS, I'd be a super happy camper.
Going further into crazy town, CSS selectors as an option (where layer/object names are classes/IDs) would, I think, upend the entire design comping process. Imagine the ability so do :last-child
selectors. One of the beauties of CSS (as well as its downfall) is its ability to change multiple things over endless permutations — which is one of the most difficult things to do within current UI design apps.
I realize that last portion isn't totally realistic and has plenty of wide-ranging implications, but I thought it was worth throwing out there.
I really appreciate all of your team's work, and especially for getting our input.
I realize you don't mean this too literally, but that is kind of a false equivalence. In real life, you have 3-dimensional depth that helps you manage those things.
Managing object "z-space" needs some kind of visualization other than "this thing overlaps this other thing." Particularly when you're in the experimentation phase of a project and moving objects from one place on the artboard to another.
Not saying layers is the BEST way to do this, but, given the parameters of the problem, they are efficient.
Even if you could do something similar to Indesign's management of anchored objects (alignment to/from the spine, etc), that would be a huge win.
Actually, you can: mix($your-black, $color, $percent);
Abstracting that further:
$your-black: #333;
@function shade($color, $percent){ @return mix($your-black, $color, $percent); }
color: shade(#800085, 10%);
Expanding on that article, I created a color variant function. This way you can define the base colors and let Sass create the light, dark, etc. keys itself.
Here's a gist: https://gist.github.com/Cleecanth/ef422b527ddcbaa1a62e
I think the big, game-changing difference is the concept of a fluid canvas. Even before responsive design, this was a massive difference. Much of the best graphic design is built around the marriage between the content and the canvas.
With web/interface design, you have to essentially throw the canvas out the window, and with it goes a whole lot of assumptions we've built up over the years (some dating back to Gutenberg).
It could be argued that the opposite is true and that the canvas is more important than ever. But, in either case, the canvas is no longer the security blanket it once was, and that completely changes everything.
Designer News
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Have feedback?
I've been using Scrollmagic and anime.js for a recent project and had some pretty great success. It takes a little extra work up front to integrate, but the combination of the two libraries is under 20kb (compared with the nearly 90kb of GSAP+Scrollmagic) and jank is nearly non existent.
Granted, this is only necessary if you want scroll-based animations and not just scroll-triggered ones.