5 ms·
This is a thread about CSS and HTML. We're talking strictly UI and presentation. Your argument is that data dependencies and other non-UI and non-presentational
by slver 5y ago
This is a thread about CSS and HTML. We're talking strictly UI and presentation. Your argument is that data dependencies and other non-UI and non-presentational aspects are not a tree. They're not. But all I said is that your UI is always a tree. And I see no examples pointing otherwise.
- dgb23 5y agoAs a pointer for further investigation: One of the big challenges of teaching coding to designers I face is the mental shift from thinking about UI as an open canvas with arbitrary geometric constraints to thinking of them as a tree structure. When implementing bespoke interfaces I very often have to do this translation in my head. You’re right that the common case is a tree, or can easily be translated to one. But it’s not the general case.
- slver 5y agoWell this is why I am asking about examples where it's not the case. And still looking forward to some.
- dgb23 5y agoYou want to draw two disjoint circles and a line connecting their centers. Now the geometric relation is a simple graph. But in HTML/CSS you likely have to use an invisible parent that these objects relate to and maybe a few other tricks. You’re not expressing this directly anymore, but kind of have to traverse around tree nodes so to say. It can even be worse if those objects are laid atop of others, and things are switching on the Z axis. You’re now breaking the structure or rather changing it constantly. The parent-child relationship often feels forced. Designers seem to think of UIs more of an open canvas, typically as a layered grid (a fine grid of single digit pixels) where the objects have arbitrary relations to eachother and the grid. The canvas itself is sometimes the only “parent”. Or even simpler: you have two objects in different containers, but with the same margin to appear aligned. What you’re trying to express is their alignment and not their relation to their “parent” which might be very well invisible.
- slver 5y ago> You want to draw two disjoint circles and a line connecting their centers. I wouldn't say two circles connected by a line is very useful in UI to be honest. Such relationships are more commonly seen in animation software, modeling software, engineering software and games, 2D or 3D, where such relationships are explicitly expressed by scripting or specialized binding systems (like inverse kinematics). The general metaphor for such software is not a tree, not a graph either, but rather a set, upon which set operate a set of systems (like physics and AI etc.). But all of those things sit, in my mind, distinctly apart from what UI is. And the distinction between UI and just "things on a computer" is that UI is entirely artificial and made for the purpose of conversing with the user, rather that representing or simulating existing phenomena, natural etc. So UI does NOT have to be arbitrary. But it HAS to be easy to comprehend. That is its purpose. The only place I've seen this used in UI I can recall is Reason (audio software), where you can flip your rack of modules, and connect inputs and outputs with wires. It's quite gimmicky and becomes a mess (just like real cable management does), so I think this also informs us how well arbitrary graphs look on screen. They don't help and become unintelligible at scale. While a clean hierarchy tends to stay clean, so it's useful in UI where we control our metaphors and optimize them for comprehensibility. > It can even be worse if those objects are laid atop of others, and things are switching on the Z axis. You’re now breaking the structure or rather changing it constantly. The parent-child relationship often feels forced. I'm sorry that's a bit abstract, can you provide an example again? You see, a list has a clear enumeration order, you can make the first or last item be "on top". A tree also has a clear traversal. A graph has no clear traversal order at all, so how would a graph help you at all figuring out z-index for your UI? If anything, having your UI as a graph would take away the common-sense approach to rendering order which allows you to NOT assign a z-index to literally every element. I've had to deal with such problems, and trust me, you don't want to have that problem. The tree is a friend. > Or even simpler: you have two objects in different containers, but with the same margin to appear aligned. What you’re trying to express is their alignment and not their relation to their “parent” which might be very well invisible. A visual example would help. The "parent" exists to provide a transform reference as much as anything else. So it's unclear why you wouldn't use a parent for the purpose it exists, only to eventually do the exact same thing.