Workflow vs interface vs implementation
Dec. 21st, 2019 07:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sniffnoyWhat I'm about to say here is all fairly obvious, but one thing I've learned is that things I think of as obvious are often not obvious to everyone -- in this case I know it wasn't -- so I figured I should write this down somewhere. Actually I thought I already *had* posted this on the internet somewhere (maybe even here?), but I can't seem to find it, so, oh well.
(I was going to post this to Less Wrong, but this seems maybe a little too basic even with the lower standards there now. :P )
It's commonly appreciated that when explaining how to use something, there's a distinction between the high-level usage instructions and the low-level details. But what I've noticed is that different people draw the line a bit differently, and this leads to some confusion. A more useful, less ambiguous distinction, I find, is to break things into three levels, which I'm calling "implementation", "interface", and "workflow".
Implementation is what it sounds like -- how the thing works under the hood, ignoring all abstractions you might use to paper it over. You normally shouldn't have to worry about this unless something breaks, or you want to modify it, or maybe you just want to learn how it works so you can do something new, or whatever. It's what's below the abstraction.
Interface is what the thing does and not how it does it; this is necessarily an abstraction and won't always work, but it's at least what the thing is supposed to do in every case.
Workflow is how you normally use the thing -- not everything it does, just how it will respond when you do the things you normally do with it, not how it's going to respond in weird edge cases.
Note that these distinctions will only really work for artificial things -- something like, say, cooking, doesn't have a clean separation between implementation and interface -- but they can still be a useful separation to draw even when that separation may not match the territory cleanly.
OK, all this is fairly obvious. Why then do I bother pointing this out? Because apparently not everyone finds it so obvious! I can think of multiple conversations I've had where (in effect) I was given workflow information, found it insufficient, asked about the interface, and was asked, why do you need to know about such internals? Except, I wasn't asking about internals (implementation), I was asking about interface. The person I was talking to just didn't seem to have a concept of a complete interface, as distinct from the implementation on the other hand, but as distinct from a mere workflow on the other hand.
Anyway yeah. Pretty simple, and already presumably widely appreciated, but just thought I'd get that written down to be sure...
(although seriously if anyone can find where I wrote about this before, please link me and maybe I can delete this :P )
-Harry
(I was going to post this to Less Wrong, but this seems maybe a little too basic even with the lower standards there now. :P )
It's commonly appreciated that when explaining how to use something, there's a distinction between the high-level usage instructions and the low-level details. But what I've noticed is that different people draw the line a bit differently, and this leads to some confusion. A more useful, less ambiguous distinction, I find, is to break things into three levels, which I'm calling "implementation", "interface", and "workflow".
Implementation is what it sounds like -- how the thing works under the hood, ignoring all abstractions you might use to paper it over. You normally shouldn't have to worry about this unless something breaks, or you want to modify it, or maybe you just want to learn how it works so you can do something new, or whatever. It's what's below the abstraction.
Interface is what the thing does and not how it does it; this is necessarily an abstraction and won't always work, but it's at least what the thing is supposed to do in every case.
Workflow is how you normally use the thing -- not everything it does, just how it will respond when you do the things you normally do with it, not how it's going to respond in weird edge cases.
Note that these distinctions will only really work for artificial things -- something like, say, cooking, doesn't have a clean separation between implementation and interface -- but they can still be a useful separation to draw even when that separation may not match the territory cleanly.
OK, all this is fairly obvious. Why then do I bother pointing this out? Because apparently not everyone finds it so obvious! I can think of multiple conversations I've had where (in effect) I was given workflow information, found it insufficient, asked about the interface, and was asked, why do you need to know about such internals? Except, I wasn't asking about internals (implementation), I was asking about interface. The person I was talking to just didn't seem to have a concept of a complete interface, as distinct from the implementation on the other hand, but as distinct from a mere workflow on the other hand.
Anyway yeah. Pretty simple, and already presumably widely appreciated, but just thought I'd get that written down to be sure...
(although seriously if anyone can find where I wrote about this before, please link me and maybe I can delete this :P )
-Harry
no subject
Date: 2019-12-24 08:13 pm (UTC)I'd like to point out that this is not obvious to me. I have never seen anyone making the distinction of implementation, interface and workflow explicit, and it's actually pretty helpful that you spelled it out like that. Things can be both simple and not obvious at the same time!
no subject
Date: 2019-12-25 05:09 am (UTC)Yes this is why I say I'm trying to make a point of writing down things I find "obvious" a bit more often... it's something that I've typically kind of neglected, despite quite a bit of evidence that it's not all obvious to everyone else and I really should. Anyway glad you found it helpful. :)