Is there a clear separation of function from visual design in the Microsoft 'Metro' UI?

Question

There have been many design projects that are using the Microsoft UI design style/pattern to build web applications and mobile apps. Many current software development teams are using Agile methodologies that require iterative and rapid design and development. One of the advantage and disadvantage I see is that this design style seems to couple the visual design with the functional aspect of the UI, which means that there is no clear separation that you would expect in a traditional Model/View/Controller or Model+View/Controller paradigm. Design elements fall into multiple categories and therefore it is difficult to define or describe exactly what the elements are. It seems like a functional specification would be more suitable.

Is there some solid evidence or accepted usage that help clarify whether there is a good separation of function from visual design?

Answer 1

Separation of presentation (visual design) and content (function) is always there even though it’s harder to see on Windows 8 design (formerly known as Metro UI). Just because there are similarities between mock-up/sketches and the final visual design doesn’t mean it’s gone. It’s just harder to recognize. In addition, from my knowledge, it’s much harder to make a good Windows 8 style than an iOS 6 icon.

Answer 2

I don't think this is an issue specific to Windows 8 at all, but rather simply an issue that has slowly but surely over time made itself more apparent.

Back in 1984, we have an extremely limited set of GUI elements. They could be styled in many ways, but essentially all retained the same functionality and interactions.

FWD 3 decades and now we have almost carte blanche to come up with entire new GUI paradigms for each and every project we work on--not that we should do that, but the technology now allows us that freedom (for better and worse).

In my (limited) experience with MVC, it's often 'sold' as a means of 'skinning' a solution. As long as you keep with that concept--meaning the interaction of the element won't change...merely the color and fonts, you're OK.

But as you are likely realizing, there may be 3 different interactions that can be used in a particular case and all 3 are much more than merely different skins...but completely different components--and may even connect to the back end in very different ways.

In the realm of UX, the main point of separation between form and function tends to traditionally be the wireframes vs. the prototype. However, it's an incredibly blurry line and isn't one you can depend on.

In the realm of Agile, I'd say the main point of separate between form and function would be the user story vs. the solution (ie, everything else).

Bottom line, I suppose, is that we are now in an era where form and function go hand-in-hand and need to be addressed simultaneously--especially in the Agile workflow.

When it's absolutely needed, however, I think concepts such as json, services, restless services, and the like are perhaps the direction to head in...where there is a clean break between the exchange of data and the presentation/manipulation of said data in the presentation layer.

In my experience, that works--in theory--not always in reality. No matter how hard you try, there's always a deeper connection between the layers than we often want there to be.