- From: Ambrose Little <ambrogio@gmail.com>
- Date: Fri, 24 Jan 2014 16:50:40 -0500
- To: public-nextweb@w3.org
- Message-ID: <etPan.52e2e030.238e1f29.96d4@ambrose-mbp.local>
(Spinning off a new thread, to talk about the focus of efforts in extending the Web/my understanding of this group, rather than Brian’s specific question.) I’ll start with the following statement from the CSS aims thread, though I could select others from that thread that reflect the same focus/core assumptions (as far as I can tell). On January 24, 2014 at 3:21:03 PM, J. Russell Smyth (jrussell.smyth@gmail.com) wrote: I will give my answer and thoughts out of order. Should we? There is a strong reason, in my mind, to tend towards the ability to seperate the two - typically it is different skill sets, and thus different individuals, responsible for providing these two goals. I think it is a hasty generalization to make assumptions about who will be doing these activities. Certainly, you can say in such and such a context or in some organizations, but I’d hardly say typically. In fact, most people who dabble in the Web, from what I’ve seen, tend to do some combination of the three, or at least two (content and presentation), with some minimal behavioral modification, regardless of their role. This is true of Eva the Etsy/Ebayer, Sally, the Wordpress admin, David, the small biz Web master, to John the internal IT developer. There are many more of them than entirely specialized individuals. With such a heterogenous target population, it’s usually more helpful to focus on activities than distinct persons/roles. Further, and this is where this particular group gets interesting, it feels like some of us here are still taking a limited, historical, document/content-centric approach to Web technologies. I see this as a rather HUGE divide in the Web—the people who are making 90% content/informational Web sites and the people who are making Web-based apps. They have very different concerns by and large, and so much of the Web is still married to the content/document-centric view of things. The problem domain of creating desirable, mostly-static, content/document-centric informational Web sites, while challenging in itself, is tiny compared to the vast array of problem domains for applications. If the Web (in its design) stays married to or focused on its incipient idea of content/document-centricity, it won’t go very far (and in fact, I’d argue it doesn’t really need to change much/go further than it already has). The whole idea of an extensible Web, a Web that wants to meet the challenges of its ever increasing usage scenarios across ever increasingly disparate runtimes, implies it must significantly augment this relatively basic notion of content and presentation (semantics/meaning/structure & presentation). And to be fair, this has already been occurring and exploded in the last few years. Why are we still tethering ourselves to these basic concepts other than current necessity? I hope this group at least sees they need augmenting. In different oranizations, that seperation can be more or less, but many organizations that seperation is very strong, and each has their own responsibility in the job at hand, and not having a way to clearly seperate AND join these responsibilities, makes the job a constant compromise and requires a very high level of interaction and interplay between these two functions - designers requiring engineers (or content providers) to modify their semantic output to provide structures for purely presentational aspects. This is definitely a challenge in some organizations, for sure. Especially when you add in behavior/application frameworks that essentially make the basic document/content-centric SoC unworkable. How many “Web design” tools out there act as if the world is still made up of pure, static, singular HTML documents? Most of them—even the new cutting “Edge" ones… And that more than anything is what kludges up the designer-developer workflow. On the other end of the spectrum you have a technology like XAML and tools like VS and Blend. They actually tackled application-centric UI framework/workflow and the SoC thing directly. Head on. The problem? The presentation tools are still just too complex for most (current) visual designers to grapple with. Or at least they don’t want to deal with that complexity. You need special kinds/hybrids who are willing to learn Blend and beat XAML into submission. The same thing is on the Web side, except the tooling isn’t even as advanced, and it is built on a more fragile framework. Web designers have to become masters of the arcane interplay of HTML and CSS (and at least dabble in JavaScript), exacerbated by browser inconsistencies. We have a long way to go to get to where a person whose talents are primarily visual and aesthetic can effectively express them without sacrificing/compromising a lot on the technical side. That of course assumes this separation of tooling should even be a goal. MS has folded Blend back into their dev tools and shut down the Expression line. Why? Partly because their assumption that different people typically do presentation/styling vs. behavior was wrong. You could argue this is due to their history/core audience, which definitely factors in, but even on the Web, the idea of distinct individuals doing certain activities as typical breaks down very quickly, once you move out of certain contexts. And so what do we have? Relatively complex technologies striving to maintain this SoC for the benefit a small portion of its whole audience. And even for this small portion, the abstractions/separations typically fail/break down and require a good amount of muddying. Nobody wins. That’s not to say that nothing good comes from this SoC, only that it’s probably better to put the focus of efforts on real usage rather than the principle itself, and augment the SoC we already have with facilities (both in framework and tooling) that smooth the interactions between the concerns and take into consideration the aforesaid changed (not changing, but changed) fundamental usage of the Web from being document/content-centric to more general-purpose application-centric. The reality is that for applications, the separation of concerns (with regard to semantics/structure and presentation) is far less important. The number of times a real application needs to be fully reskinned is, in the full realm of applications, approaching zero. Its content is almost always already separate as “data” in some form unrelated to the UI structure. Its structure is more around interaction flows and, in the realm of business, business rules. More often, for apps, the important SoC is between base application behavior and modifiable interaction flows, the discrete presentation (and related input) of data, and the rules governing the system (and how those impact the UI). Further, from a UX/IxD perspective, it is unhealthy to try to separate these concerns, because they are experienced as a whole by people, and the more we try to enforce separation, the more we run the risk of the end experience feeling like, well, what it is—cobbled together. Even the specialization of individuals (when it does occur) works against this aspect. So this further makes it dubious as to whether or not tools should even try to reinforce such separation. Honestly, I don’t think we should be arguing about separation of content and style at this point/in this group, nor semantics from structure. That feels like a long dead horse, as far as the Web is concerned. And the focus should be on what comes next for the Web. How can we build upon, tweak, and improve the groundwork we have to facilitate rapid application development? What do we need in the framework? What do we need in the tools and how can the framework enable those? We don’t have to start from scratch. We can learn from the lessons of others, not just the Web, but other application frameworks and tools. A lot of this is already happening in the Web space, but I also see a lot of both “hey we’re the first guys here” as well as unhelpfully being beholden to the document/content-centric thinking the Web has come out of, with its focus on content and semantics, rather than people and activities/flows (interaction design). Also, we must keep looking at current trends in hacking the Web as it is today. For instance, the breaking away from “page”-based thinking from the visual design/content side (e.g., style tiles and content blocks). Of course, Web components. How can we look at the current popular application frameworks like Angular, Ember, Backbone, etc. and pick the good things from them to bake into the core Web? The problem is all of this is still just too hard. For everybody involved. Too costly. And I just don’t see that further worrying about SoC between HTML and CSS is not going to help us move things forward. -a
Received on Friday, 24 January 2014 21:51:09 UTC