Developer Ying to Designer Yang

Steffan Barry on the importance of bringing developers into the creative process early:

Developers. They’re logicians, mathematicians, forecasters and teachers all wrapped up in one kick-ass co-worker. They live, work and play on digital’s frontline, and are pivotal partners in the creative development process; partners that, if included early on, can greatly enhance your chances of creating and executing an idea that will be successful in the digital space.
If you’re a web/mobile/interactive designer and you don’t like or want to work with developers, you should find another profession. The same applies to developers.
Aside from those rare unicorns that can do everything, designers can’t do what developers do, and developers can’t do what designers do.
When we work together, it’s like Voltron forming. Amazing shit is possible.*
**I once saw a group of designers and developers form a blazing sword and slice another design agency office IN HALF. True story.*

Categories:

Development

Tags:

Webkit to the Rescue

I was a late-comer to Mountain Lion, for no reasons worth going into here. But the transition the last couple months has been rocky here and there. I’m not much of a fan of the half-baked in-between state Mountain Lion occupies between iOS and earlier OSX iterations like Snow Leopard. I’ve spent a lot of time tweaking things here and there to get them either back to the way I like them, or to activate features I think Apple missed. One of these is involves the web inspector for Safari 6.
I’m a web developer, and it’s crucial for my job that browsers have a way to inspect a web page, showing me the DOM tree, all elements and attributes, inheritance, etc. One of the most important things for me, since I focus on front-end UI, is how CSS is being called. Back in Safari 5, this was easy in the web inspector. When inspecting elements on a page, any styles applied to an html tag would show in a details window, along with styles inherited from parent elements. Also present would be the file name and line number where the style lived. It was easy to find the exact style that was affecting an element.
For whatever reason, in Safari 6, the web inspector was changed. It still shows which styles are being computed, but it doesn’t show where they came from. You have to click back through the DOM tree until you find the element with the associated style. This adds a lot of time to testing a webpage, especially if you’re diving into someone else’s work. See below:
safari6inspector_bl.jpg
In the above image, I selected a div that gets just about all of its styles from parent elements, but while I can tell which styles are being computed, I can’t tell where they are. For example, I know what font-family is being applied to the div, but where is it coming from? This has been a source of frustration for me ever since I updated to Mountain Lion and have tested pages in Safari. Thankfully, WebKit has come to the rescue.
The WebKit Open Source Project is still using a web inspector with CSS details similar to that found in Safari 5. See below:
webkitinspector_bl.jpg
This is an image of the web inspector in the latest build of WebKit. I have the exact same div selected as in the previous screenshot, only in this one, I can see which styles are being applied from parent elements, and where they live in their corresponding CSS files. This is going to make testing styles in Safari a lot easier for me.

Categories:

Development

Tags:

Design Dictatorship

“No magazine should be 500mb.”
I received that IM from Michael the other day. He was talking about the size of downloads for new issues in the iPad’s Newsstand app. He’s right. There is no good reason for magazine issues to be that large. Why are they that large, anyway? It’s because magazines have yet to adapt to new technology.
Magazine designers and editors are very finicky about layout. They spend an entire month getting everything perfect, especially type. Typography is something a normal reader doesn’t notice…consciously, anyway. But designers obsess over it. They spend more time getting the type to look right on a page than any other element. And that’s fine for the printed page. But things begin to break down in the tubes.
Type has never been something that displays well on computer screens. Rendering is affected by what device a user is on, what operating system, what browser they’re using, etc. A little effort by the developer can get the type quite close to the original design, say, 95%, but that last 5% drives designers nuts. They invest a lot of time and effort into getting the type to look perfect in the layout, and seeing the leading off, or the kerning absolutely destroyed by a browser is frustrating, to say the least. But, there is a solution.
Eschewing live text and making the text an image file preserves appearance, albeit at the expense of file size, search engine optimization, usability, and much of the ability to update content dynamically.
Enter magazines. Most magazines made the decision that preserving appearance is more important than utilizing all of the iPad’s functionality, so instead of pages loading text dynamically, a typical magazine page is one big png file. Add that up for the number of pages in a typical magazine, and that’s how we get to the 500mb figure.
Speaking from the perspective of a developer, preserving appearance is ideal, but the method magazines are using feels about as pointless as holding back the tides. Technology is here to stay. In the next decade, advances in text rendering will continue to be made, but the bunker mentality most magazines have as they wait is untenable.
I think it comes from a sort of cognitive dissonance that editors and designers have about type in the electronic world. For decades magazines controlled how their readers saw their content. But placing content on a device of any kind means the magazine has to cede some sovereignty to the device. Also, if they are planning to display content on multiple devices, the user’s decision making is relevant, in the form of the device they choose to use. Design used to be a dictatorship. A very ordered, unassailable one at that.
Magazines need to let go of the idea that they can dictate 100% of a reader’s experience. I know that, to them, that makes no sense. But refusing to embrace change does not make it go away. It just makes the inevitable transition harder.

Categories:

Development

Tags:

“HTML5 did not change that”

Looks like Group94 is relaunching their site next month:

Assume nothing, question everything. Group94 stands for highly tailored work. In an industry tending to standardization, offering more of the same, this appears to be an approach that works.
Developing in HTML5 nowadays did not change that…
Indeed every project starts from a clean slate, the goal is to make it fresh and innovative yet well thought out and usable, it must be fast and to the point and of a highest order from a technical point of view.
Can’t wait. I’ve been a fan of their work for years.

Categories:

Development

Tags: