kremalicious

I try to repeat that at least 2 times a day:

The problem with Photoshop is that what’s being created is actually a fiction. It somewhat resembles what the final product might look like, but it’s not real. Layout and typography decisions are made that often don’t translate accurately to HTML. We spend hours designing for a medium that’s interactive and responsive, but we start by producing mockups that are static and inflexible. If great design is not only aesthetics but also how it works, then it’s time to make development part of the creative process.

Go to source ∞

This has been said many times, but it bears repeating:

Files are abstraction layers around content that are necessary for interoperability. Without the notion of a File or other similar shared content abstraction, the ability to use different applications with the same information grinds to a halt, which hampers innovation and user experience.

A good example are all those note taking apps on iOS which usually only require plain text. When using Apple’s iCloud to sync their data, they lock your content into one app without any way to access this from another app. Compare that to apps using Dropbox for note syncing: I can throw as many apps I would like at my notes folder full of .txt files. The note app you’re using has some new quirks after the latest update? Just switch to another app. Apple’s iCloud syncing Notes.app having some new quirks after the latest update? Well, you and your content are doomed.

But the solution can’t be throwing a full file system at the user:

Now, I agree with Steve Jobs saying in 2005 that a full blow filesystem with folders and all the rest might not be necessary, but in every OS there needs to be at least some user-facing notion of a file, some system-wide agreed upon way to package content and send it between applications. Otherwise we’ll just end up with a few monolithic applications that do everything poorly.

Just applying the PC concept of a file system to post-PC devices, like Android and Dropbox did, makes only geeks happy but not the majority of users. While useful it’s still too abstract for most users. That’s why even Android kind of hides the file system, there’s no built in app to browse it directly. But at least Android has Intents, allowing users to send any data between different apps.

Apple already solved the problem of a file system being too abstract for users a long time ago, but without any app lock in. The Newton OS on MessagePads stored everything in object-oriented databases called soups. The “union soup” could be accessed by any app (“packages” to be exactly) on the system. Today, this is happening only rudimentarily on iOS, like when you start typing a recipient in Mail and it gets auto-completed from the Address Book data which obviously is only possible with Apple’s apps.

Soups took away the need of manual file management without cutting access to the content. iCloud needs to be the new soup.

Go to source ∞

Much has been written about the good and bad of skeuomorphism. Tom Hobbs wrote a great piece putting everything together.

Digitally re-creating real materials and analog objects very quickly becomes aesthetics for aesthetics sake. It’s hard to believe that all but a minute percentage of Apple’s user base has a tan-suede–bound calendar or book of any sort, or anything else that looks remotely similar. Unfortunately, these are the characteristics of skeuomorphism that a vast majority of UI designers employ when they use this approach (see Blackberry’s Playbook). Ultimately, it encourages designers to become less critical and less inventive, which is detrimental to evolving new and improved solutions.

He argues skeuomorphism hinders designers in creating something truly innovative. Also, some good arguments on why Microsoft’s Metro interface isn’t the answer:

Sure, these graphic elements don’t use “superfluous” drop shadows and renderings, but they don’t really use space any more efficiently than many skeuomorphic iPhone apps. It is highly debatable whether they need to be as graphically dominant or whether the aesthetic form is purely driven by function. Metro’s graphic elements are largely abstracted representations of their function, so from a modernist point of view, it is interesting to think of what else could be stripped away to enhance their function.

Go to source ∞

Chris Coyier on an accessible implementation for icon fonts:

Where are we at right now in terms of the best markup for using icon fonts? Let’s cover some options I think are currently the best. [...]

And our major goals here are:

1. As good of semantics as we can get
2. As little awkwardness for screen readers as possible

Spoiler: the key is to map the icons to the Private Use Area instead of “real” characters in the font files and injecting them with pseudo elements.

I’m using Font Awesome on this site which comes with icons mapped to PUA, so everything should be good for screen readers. Only concern to me are the quite ineffective CSS selectors like [class*=" icon-"] but this makes it nicely flexible.

Go to source ∞