There is a fine line between using things like color as a tool to shape a product, versus using them as an option to sell a product. I know which side Jobs was on.
Albert Hofmann (legendary chemist who synthesized LSD) and Shigeru Miyamoto (godfather of Nintendo who created Mario), both cite walking around and playing in the woods freely and unsupervised as a child being transformative experiences which (they believe) led to their later life accomplishments.
Software is made of a set of symbols unique to its particular function, and user interaction at its most primitive is no more than the relationship of those symbols to the ones present in the mind of the user.
The latest fads in user interaction design seem to ignore this perspective, and instead treat "UI" as another abstraction layer of unique symbols on top of software, then expecting all software to be designed top-down based off this "unified design language". This approach unfortunately ignores the user, providing further indirection away from the underlying software and it's function, herding the user into a church of the designer's own construction where they are now forced to worship interaction in the abstract as a prerequisite to using the software (or at least blindly perform whatever rituals it demands).
The aim of design unification is often a false path, born out of convenience for the designer, and it's pursuit shows a certain level of disrespect to both the user and other designers. Programming languages - arguably interaction design in its purest form - are a more interesting path towards better software (see Smalltalk, Swift playgrounds, and the work at VPRI).
Material is not what software is made of, but it is a pretty good sign of what marketing is made of these days.
And here we see the middle-brow dismissal in its natural habitat...
Of course it's marketing; they're doing a huge marketing push on this. Even writing "Material" makes me feel like I'm helping some marketing team somewhere.
But saying that this is made up out of whole cloth completely ignores the fact that not only does it engage with the existing design language of other mobile platforms, it also flows quite nicely from "holo" and cards from previous Android versions. Moreover, it's fairly loose as design guidelines go, providing recommendations but not forcing you into a particular unified design.
The designer in that article from yesterday got it quite right: this is post-rationalization, taking what already existed and trying to find the unifying aspects of what gave clarity and discarding what was confusing. That is not the same thing as a dictated UI.
Your response is generic and could be copy-pasted on any article claiming to be about common aspects of a design language. This is exactly why it's voted up (and why it fits "middle-brow" to the t), because if you actually brought up any actual specifics about the article or "Material" it would be immediately obvious that claims of ignoring a relationship with what the user knows or with how the software is actually written are overblown and theatrical.
I don't necessarily disagree with what you're saying, but 90 percent of the developers usually develop their apps themselves - and do so badly, not just in terms of aesthetics, which is immediately obvious, but also in terms of UX.
For those 90 percent of developers, a really solid set of tools and resources like this for any platform is a godsend - and not just for them, but for their users, too, who don't have to put up with poorly designed and ugly apps.
How I wish Linux distros had the same type of design tools that Google, Apple and Microsoft are giving to their developers. 98 percent of Linux programs are garbage, and it's what's kept me from Linux for a long time (among other things, but this was definitely one of the reasons). Canonical has done a little work to improve this, but it's not as good as it could be, and even their store still looks like a mix of modern store with a 90's app store.
As for the other 10 percent of developers, who really know what they're doing in terms of design, they tend to not follow the platform's design guidelines much, or at all anyway, if they really think they can design their app in a unique way that sets them apart, and that's also better for the user.
A long time ago, programming was the way to interface with the computer. So people looking at making programming more usable came up with visual languages, and that spun off into the whole academic HCI industry that we have today.
That being said, material design is a pure visual design language and says nothing about interaction design.
I consider visual design to be a part of interaction design, and taking one without the other is a failure to understand design (to the limited extent it can be understood at all). An example: a traffic light's visual design is fundamental to its interaction design.
Right, but visual and interaction design are different activities with different outputs. An interaction design language is more about patterns of flows while visual design language is about style and metaphor. Contort them at your own peril.
Style and metaphor are integral parts of interaction design. When a user clicks a button to dismiss a dialog, what should happen?
If the experience you're trying to create (in line with the brand) is more playful, then maybe the modal should bounce out of view. If it's a very serious corporate app that people are just using because they have to, then the modal should either quickly fade, or just immediately disappear. One would be inclined to call this "style".
What about when a user is asked to input a date and time? There are two visual metaphors that come to mind: a calendar and a clock. The interaction designer has a few choices here. Date + number picker, date + clock (cool metaphor for selecting a time, but a non-standard UI pattern that could confuse people). This is an interaction design problem, not a visual design problem.
Perhaps you're referring to style and metaphor as the color of buttons and the background texture of panels. That I would say generally falls more into the realm of visual design; however, colors of buttons convey different semantic information, which affects how people interact with your app.
I naturally see the visual language as an output and the interaction language as an input, both interfacing with the holistic design space that I am trying to explore across the design process. They are not two discrete activities, but two forms of participation in a singular activity, with a design of the thing as a single output. I have taken this approach to designing things for a long time now, with no great peril beyond philosophical curiosities such as this.
Could you please point out a platform that provides an interaction design language in addition to the standard visual design language? Interaction design is very application specific, and I'm not sure how much can be guided at the platform level.
edit: oh, maybe by "patterns of flows" you mean the user's flow through an application, as opposed to individual interactions? That's seems less often addressed, but it is still out there: [3]
Designers hate it when design guidelines are called marketing, usually said by those who have no clue about what design is and are compensating for their own ignorance.
Not, it's not always sufficient - given no points are shown, there may be no visible way to see that anyone agrees (or disagrees) with a point at all.
I do feel that 'this' on its own is a bit trite, and doesn't add much, but it doesn't add 'absolutely nothing' to the conversation - it's a bit of seasoning, like a dash of salt or pepper.
An unsettling feeling that Home Automation™ is not actually about making the home and its consumer electronics more integrated, easier to use, and providing more free time and control to the individual. Rather, it is about making things harder to use for the average consumer without machine or professional assistance, requiring more hardware bundles and software services to get the "total experience", and control and data slowly taken away from the individual. Of course, this play for command and control is for the innocent sake of predictable behavior that can be optimized (and the steady revenue and growth that implies).
Self optimizing systems' predilection to predictability is quite predictable (whether machine or human).
While I believe Nest and HomeKit will likely be successful due to these optimizations they can potentially bring, I consciously will take the less optimal route this time, and have fun DIY'ing my automation instead.
Haven't read the book yet (as I just heard of it from the post), but sounds interesting. I am also currently working on a piece of fiction with some similar themes, and was wondering if you could share some thoughts on how you manage references to real world entities and technologies in the story? What sort of balance did you find between history, science, and fiction?
I guess I would say that the story is the important thing, not the themes or real-world references or whatever. It's a novel, so above all, the story has to be compelling and the characters have to be believable and at least somewhat interesting.
With regard to real-world people, places and things, I was just aiming for verisimilitude, to make the setting (and the science and computer science) believable to people who knew the territory.
The author and the technology/finance circle jerk he feeds off are most definitely conspiring to put the reader in their bubble. The only thing bubble based software is eating is available capital, which could be used to research and develop more robust, long term solutions by advancing hardware and software together.
