images
What the painting was not about
The past of his image upon me
Mere retinal art
The eye does not see
The Gosling Effect
Apparency
Half a century ago, Stern discussed this attribute of an artistic object and called it apparency. While art is not limited to this single end, he felt that one of its two basic functions was "to create images which by clarity and harmony of form fulfill the need for vividly comprehensible appearance." In his mind, this was an essential first step toward the expression of inner meaning.
As plain as day
The personal experience of most of us will testify to this persistence of an illusory image long after its inadequacy is conceptually realized. We stare into the jungle and see only the sunlight on the green leaves, but a warning noise tells us that an animal is hidden there. The observer then learns to interpret the scene by singling out "give-away" clues and by reweighting previous signals. The camouflaged animal may now be picked up by the reflection of its eyes. Finally by repeated experience the entire pattern of perception is changed, and the observer need no longer consciously search for give-aways, or add new data to an old framework. They have achieved an image which will operate successfully in the new situation, seeming natural and right. Quite suddenly the hidden animal appears among the leaves, "as plain as day."
The language of art
Everything points to the conclusion that the phrase 'the language of art' is more than a loose metaphor, that even to describe the visible world in images we need a developed system of schemata.
Words and Images
An Essay by René Magritte
Beyond Artboards
The Pursuit of Lossless Design-Development Handoffs.
Can't developers just see?
We designers love artboards. From rough UI sketches to high fidelity mockups, we see ourselves as visual artists expressing ideas on artboards that have a pre-defined width and height. To start a new project, we declare the size of the artboard in the first step.
What about responsive design? Not a problem! We diligently design on three artboards — one for mobile, one for tablet, and one for desktop — with content elegantly adapting, scaling, reflowing, reordering, and reprioritizing. We proudly hand off the artboards to developers while patting ourselves on the back: this is how responsive design should be done.
After weeks of arduous engineering, the product finally comes out. We find, to our great dismay, that some copy is hanging off the grid, the focal point of the hero image has been cropped out, the font sizes don’t even come close to the type ramp. What went wrong? Can’t the developers just see everything on all those artboards?
Nope.
We are the ones who paved the path
No matter how many screen sizes our artboards account for, some user’s browser will break loose from our prescription. With users resizing, rotating, and zooming the screen, new devices stretching, squashing, curving, and cutting (e.g. the speaker area in iPhone X) the screen, the sizes become infinite. Good luck making an artboard for each one of them.
Artboards are a lossy format. Using artboards in a handoff is a lossy process. When we pitch a finite number of plans against an infinite number of situations. We inevitably get in-betweens. Once there are in-betweens, there are unknowns. Once there are unknowns there is guesswork. Once there is guesswork, there are surprises. Engineers take the path of least resistance. We are ones who paved the path.
Until we get there
- As a designer, learn writing HTML, or better still, semantic HTML. If coding up the entire design is too hard, try coding up one component at a time, and not worrying about CSS. The HTML alone will prove invaluable for developers to understand the content structure. In addition, you are forced to optimize the information architecture as you work out the code from content.
- If coding by yourself is out of the question, pair up with the engineer who will receive the design. Work closely with him or her to prototype the design, validate responsive behaviors, and obtain feedback on the feasibility. Don’t call it an iteration until the design has seen played with in code.
- As a manager for large enterprise, co-locate your designers and developers, encourage interdisciplinary learning, understand that each minute spent on coding before the handoff translates to ten minutes saved from changing and fixing issues after the handoff.
- As a stakeholder in the handoff meeting, give the designer a thumbs-up when he or she demos live code running in browsers in place of mockups on artboards. That’s a design champion you are looking at.