10 ms·

Blurring the Line Between User and Programmer

106 points by stevekrouse 7y ago

OJFord 7y ago
Tool itself is at https://coda.io https://coda.io, seems similar to but more powerful than Notion, (https://notion.so https://notion.so) which I have used, with pricing to match. Tangentially, it's good of Panic to link to the above at https://www.panic.com/coda/ https://www.panic.com/coda/ - or perhaps they were just getting fed up with dealing with people in the wrong place!
- trevyn 7y ago
  Coda bought the name from Panic.
- AlphaWeaver 7y ago
  I'm a little bit obsessed with keeping up with solutions in this space, and I've been watching both Coda and Notion for a while. Coda actually just released their v2.0 a few days ago which has brought some much needed bugfixes and stability improvements. I've had some time to discuss larger strategy with their team, and I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability. I definitely like their product, and am following them going forward. If you're at all interested in this space, you should check out Coda just for the sake of seeing where we are (as a field) in solving this problem.
  - OJFord 7y ago
    > I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability. That's exactly it, I was saying to a colleague earlier that I wish* there were an open-source self-hostable option, but the closest I've found - Trilium Notes - is way further over to 'capability' than 'easy to use / discoverability', to use your spectrum. (I was a bit harsher, describing it as a spectrum from good UX to programmable.) *(mainly because exports aren't that useful - Notion exports some but not all data, and then you've got to sanitise (or get lucky) the CSVs it does export for the new tool)
ohduran 7y ago
Imagine we build the ideal programming language that both technical and non-technical humans alike can understand. What does it look like? I'm thinking about Excel spreadsheets. Let me elaborate: a non-technical guy creates a monstrosity: one of those spreadsheets that "works", and tasks the programmer with maintaining it. At every level, the non-technical understands what's going on, because he is familiar with most formulas (that's the beauty of Excel IMO). He just wants the programmer to focus on making sure that everything works "just fine". Forget for a moment about what "just fine" means. Let's say they can go back and forth until they can convey what they mean to each other. My point is that the very first sentence of the post is not correct. > “The world’s been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one. It feels kind of broken,” A non-technical person CAN indeed make software... he just can't make maintainable software, and eventually his incompetence backfires. If I'm correct, then Corda and other tools aimed at "making the laymen build software" are solving the wrong problem. The spreadsheet, and before that a piece of paper, just solved that problem. What the laymen need are the mental tools that a programmer uses to "speak" about software, in the sense that what a human can see on the screen isn't the whole picture of what technical people mean by "software". Hope I made myself understood. Can anyone assist? Am I wrong?
- ohduran 7y ago
  One possible explanation for why non-technical people "can't" build software is simply that they don't want to learn how to do it. But that isn't the problem that Corda is trying to solve, I gather. The client avatar for Corda is, I reckon, the guy who wants to "hit the ground running" and become able to speak "software" to a programmer.
- PeterBarrett 7y ago
  It would depend on the scope of what people are trying to achieve, at a certain point of complexity you pass from being a "non programmer" to being a programmer due to all of the inferred learning you get from experience. I know a handful of non programers who can automates tasks in their everyday workflow but as you say they're not maintainable pieces of software or particularly transferable, they are custom tools they create for their own flow.
tempodox 7y ago
According to my own distinction, Blurring the Line Between User and Programmer is unpossible: A user is someone who asks why a software is not working (and even in the 21st century this is still far more common than it should be). A programmer is someone who asks why and how a software is working. Eventually this also includes failure modes, so the user's question above will not stay unanswered forever.
- mcherm 7y ago
  > Blurring the Line Between User and Programmer is unpossible And why on earth do you believe that this difference in mindset cannot be taught?
  - scroot 7y ago
    This is (sort of) one of the sticking points people like Kay and especially Papert made. Because all computing is interactive, it is always an ongoing part of a more general "learning process." There are many types of learners and ways that they can internalize otherwise complex systems/concepts. It is the job of the computing environment to be flexible enough to take advantage of each person's particular method for learning how to properly (and powerfully) manipulate it. Lots of talk about spreadsheets in here, and rightly so. See also Hypercard. These systems are (were) incredibly popular, and regular people were able to do things with them that they could not in other media. It's largely because the systems they represented were well designed -- not because people had some particular competency in "abstract thought" or "systems thinking." We are all human and, for the most part, we all do that stuff one way or another.
  - Supermancho 7y ago
    It is near impossible to teach a mindset that is not desired.
chewxy 7y ago
Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.There are many programs, each does a different thing, you program your final product by composing programs. Users of the final product are the programmers. I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven't finished it. Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want! Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it. You may think the solution is to get people to publish accessible APIs. I think that's a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products. I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
- scroot 7y ago
  > Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it. It's the right attitude to take, but let's try to provide some definitions. What does it mean "to program"? Certainly we have contemporary ideas of what it all involves. But at the end of the day it's hard to come up with a more encompassing definition than "telling a computer what to do (and possibly what to do later)." This means that by merely "using" a computer (ie through a GUI or whatever -- manipulating it somehow) one is, by this definition, doing some kind of programming. With that definition in mind, we now see that the systems we have provided users are completely hamstrung. We have given them limited environments and languages (languages here being mostly of a visual/UI variety) to work with. What's worse is that we have goo examples from even recent history about how alternatives can work: Visicalc, Hypercard, Smalltalk, etc. Insofar as these conversations rely on discussing "programming languages" -- a loaded term, and only part of the picture really -- rather than whole "computing environments," then we tread further down a losing path for everyone.
zupa-hu 7y ago
Not directly related, but The Whole Code Catalog seems to be a really interesting collection.
- zupa-hu 7y ago
  To avoid confusion, it's from the same author: https://futureofcoding.org/catalog/ https://futureofcoding.org/catalog/
WickedFlick 7y ago
I'm not terribly excited with the idea of making spreadsheet style programs easier, but I suppose it can't hurt, either. Personally, I think programming languages becoming closer to spoken languages would be more useful. I first learned of that concept from this Reddit thread: https://www.reddit.com/r/linux/comments/da718w/i_think_the_foss_movement_should_want_to_maximize/ https://www.reddit.com/r/linux/comments/da718w/i_think_the_f... There, the author of the thread talks about the benefits of Inform 7, a programming language specifically designed for creating interactive fiction games. It's an incredibly impressive bit of work, and is the most promising path toward getting regular folk into programming. I also came across this interesting article from Wolfram: https://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/ https://blog.wolfram.com/2010/11/16/programming-with-natural... which goes into natural-language programming and how they will (hopefully) become dominant in the future.
- pintxo 7y ago
  Do you have an idea on how to solve the fuzziness and ambiguity problems in spoken language? This IMHO is the largest problem with spoken language, no parentheses, lots of synonyms/homonyms etc.
- mpweiher 7y ago
  > programming languages becoming closer to spoken languages One word: AppleScript
jbattle 7y ago
We've all seen incredible things built in spreadsheets. Spreadsheets are plenty powerful. I haven't met a clever+motivated person yet that couldn't build something incredible in a spreadsheet. What I think is missing is a way to help the author (and other team members) make sense of the artifact as it gets more complex. Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs. With spreadsheets for example, you are basically forced to find a cell that seems to have data you like. Then you have to back-track formula references + check for macros/scripts and hope that no references have broken. I humbly submit this is a problem that a team like the Coda team should be solving.
- infogulch 7y ago
  Excel needs exactly one thing to blow open the doors on productive programming: a new "function" data type. Since it's just a data type, you put it in a cell just like any other data type. Have some way to call it, like `A1(arg1, arg2)` or something. Now you can leverage the full capabilities of Excel to manage it, name it (named ranges), etc just like other data. A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.
  - ahane 7y ago
    sounds like a great idea
  - jagged-chisel 7y ago
    Sounds like you want to move VBA into the cell. I issue no opinion on doing that, just offering an observation.
    - infogulch 7y ago
      Actually you make a great point (thank you!), but honestly I wouldn't want it to have anything to do with VBA. For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.
mfer 7y ago
This reminds me a lot of Word. You can embed a spreadsheet and you can add code to the document (I even remember using VBScript back in the day). What's old is new again?
datavirtue 7y ago
Uh. No.
mmphosis 7y ago
I like going the other way where as a "Programmer" I don't need to program so many things. Most "things" can be declared: text, html, lists, trees, tables, databases, ... For example in XFCE, I can add an "Applications Menu" to the menubar (panel) and use a custom menu file with a list (or tree) of programs to run. The icons, labels and how to run the programs are declared in .desktop files -- no "programming" required.
Discombulator 7y ago
I have not looked into Coda yet, but have a few observations on the user / programmer divide. To me, spreadsheets are just another programming paradigm. I have seen business users build impressive things using Excel (excluding here VBA). I'd even say that in terms of raw productivity (i.e., just in terms of business problems solved over time, without any consideration for maintainability etc), the spreadsheet paradigm is vastly superior to the regular textual programming paradigm – as long as the problem is simple enough. And most of normal business is dead simple. As soon as the process or problem hits a certain complexity, the Excel solution becomes painful to use, understand and change. I believe this is in part specifically fault of the tool - while Microsoft has been doing a great job in terms of power user features (Power Query, PowerPivot), they have apparently not been willing to extend the spreadsheet paradigm itself to meet the requirements we demand from business software, which is a pity and missed opportunity. Secondly, what I have also observed is that most users, even users building complex workbooks, are not willing to make the jump to textual programming (e.g., VBA). I think programming in general requires a high level of frustration tolerance that most people are not willing to bring up except when they really have to (e.g., to use Excel, which is basically unavoidable in 99% of businesses). To summarize, there is still room to come up with a system that makes building simple things as simple as Excel, while being flexible enough that it scales to meet production software requirements.
golover721 7y ago
What id love to see more is blurring the line between user and designer. Too often software gets in the way of the user and simple tweaking to an interface etc. can make a world of difference. Unfortunately this is usually either not possible or involves a user navigating endless configuration options or worse configuration files. Maybe that’s not a big deal to us in the software industry but it is a huge problem for your average user.
- AnIdiotOnTheNet 7y ago
  I agree. There's no reason we can't have this, we've had tools like Delphi and VB for a long time now. Why can't I just choose widgets from a palette and make my own Outlook interface? Maybe it could even be taken a step further and turn it into a UNIX pipeline composition equivalent in GUI form. Trying to imagine what a system could look like, I see a kind of tiling window manager in which you can place arbitrary widgets (list views, sliders, text entry, etc) and hook together their inputs and outputs, maybe with a little scripting glue.

106 points by stevekrouse 7y ago

Tool itself is at https://coda.io https://coda.io, seems similar to but more powerful than Notion, (https://notion.so https://notion.so) which I have used, with pricing to match. Tangentially, it's good of Panic to link to the above at https://www.panic.com/coda/ https://www.panic.com/coda/ - or perhaps they were just getting fed up with dealing with people in the wrong place!

trevyn 7y ago
Coda bought the name from Panic.
AlphaWeaver 7y ago
I'm a little bit obsessed with keeping up with solutions in this space, and I've been watching both Coda and Notion for a while. Coda actually just released their v2.0 a few days ago which has brought some much needed bugfixes and stability improvements. I've had some time to discuss larger strategy with their team, and I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability. I definitely like their product, and am following them going forward. If you're at all interested in this space, you should check out Coda just for the sake of seeing where we are (as a field) in solving this problem.
- OJFord 7y ago
  > I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability. That's exactly it, I was saying to a colleague earlier that I wish* there were an open-source self-hostable option, but the closest I've found - Trilium Notes - is way further over to 'capability' than 'easy to use / discoverability', to use your spectrum. (I was a bit harsher, describing it as a spectrum from good UX to programmable.) *(mainly because exports aren't that useful - Notion exports some but not all data, and then you've got to sanitise (or get lucky) the CSVs it does export for the new tool)

ohduran 7y ago

Imagine we build the ideal programming language that both technical and non-technical humans alike can understand. What does it look like? I'm thinking about Excel spreadsheets. Let me elaborate: a non-technical guy creates a monstrosity: one of those spreadsheets that "works", and tasks the programmer with maintaining it. At every level, the non-technical understands what's going on, because he is familiar with most formulas (that's the beauty of Excel IMO). He just wants the programmer to focus on making sure that everything works "just fine". Forget for a moment about what "just fine" means. Let's say they can go back and forth until they can convey what they mean to each other. My point is that the very first sentence of the post is not correct. > “The world’s been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one. It feels kind of broken,” A non-technical person CAN indeed make software... he just can't make maintainable software, and eventually his incompetence backfires. If I'm correct, then Corda and other tools aimed at "making the laymen build software" are solving the wrong problem. The spreadsheet, and before that a piece of paper, just solved that problem. What the laymen need are the mental tools that a programmer uses to "speak" about software, in the sense that what a human can see on the screen isn't the whole picture of what technical people mean by "software". Hope I made myself understood. Can anyone assist? Am I wrong?

ohduran 7y ago
One possible explanation for why non-technical people "can't" build software is simply that they don't want to learn how to do it. But that isn't the problem that Corda is trying to solve, I gather. The client avatar for Corda is, I reckon, the guy who wants to "hit the ground running" and become able to speak "software" to a programmer.
PeterBarrett 7y ago
It would depend on the scope of what people are trying to achieve, at a certain point of complexity you pass from being a "non programmer" to being a programmer due to all of the inferred learning you get from experience. I know a handful of non programers who can automates tasks in their everyday workflow but as you say they're not maintainable pieces of software or particularly transferable, they are custom tools they create for their own flow.

tempodox 7y ago

According to my own distinction, Blurring the Line Between User and Programmer is unpossible: A user is someone who asks why a software is not working (and even in the 21st century this is still far more common than it should be). A programmer is someone who asks why and how a software is working. Eventually this also includes failure modes, so the user's question above will not stay unanswered forever.

mcherm 7y ago
> Blurring the Line Between User and Programmer is unpossible And why on earth do you believe that this difference in mindset cannot be taught?
- scroot 7y ago
  This is (sort of) one of the sticking points people like Kay and especially Papert made. Because all computing is interactive, it is always an ongoing part of a more general "learning process." There are many types of learners and ways that they can internalize otherwise complex systems/concepts. It is the job of the computing environment to be flexible enough to take advantage of each person's particular method for learning how to properly (and powerfully) manipulate it. Lots of talk about spreadsheets in here, and rightly so. See also Hypercard. These systems are (were) incredibly popular, and regular people were able to do things with them that they could not in other media. It's largely because the systems they represented were well designed -- not because people had some particular competency in "abstract thought" or "systems thinking." We are all human and, for the most part, we all do that stuff one way or another.
- Supermancho 7y ago
  It is near impossible to teach a mindset that is not desired.

chewxy 7y ago

Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.There are many programs, each does a different thing, you program your final product by composing programs. Users of the final product are the programmers. I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven't finished it. Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want! Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it. You may think the solution is to get people to publish accessible APIs. I think that's a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products. I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.

scroot 7y ago
> Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it. It's the right attitude to take, but let's try to provide some definitions. What does it mean "to program"? Certainly we have contemporary ideas of what it all involves. But at the end of the day it's hard to come up with a more encompassing definition than "telling a computer what to do (and possibly what to do later)." This means that by merely "using" a computer (ie through a GUI or whatever -- manipulating it somehow) one is, by this definition, doing some kind of programming. With that definition in mind, we now see that the systems we have provided users are completely hamstrung. We have given them limited environments and languages (languages here being mostly of a visual/UI variety) to work with. What's worse is that we have goo examples from even recent history about how alternatives can work: Visicalc, Hypercard, Smalltalk, etc. Insofar as these conversations rely on discussing "programming languages" -- a loaded term, and only part of the picture really -- rather than whole "computing environments," then we tread further down a losing path for everyone.

zupa-hu 7y ago

Not directly related, but The Whole Code Catalog seems to be a really interesting collection.

zupa-hu 7y ago
To avoid confusion, it's from the same author: https://futureofcoding.org/catalog/ https://futureofcoding.org/catalog/

WickedFlick 7y ago

I'm not terribly excited with the idea of making spreadsheet style programs easier, but I suppose it can't hurt, either. Personally, I think programming languages becoming closer to spoken languages would be more useful. I first learned of that concept from this Reddit thread: https://www.reddit.com/r/linux/comments/da718w/i_think_the_foss_movement_should_want_to_maximize/ https://www.reddit.com/r/linux/comments/da718w/i_think_the_f... There, the author of the thread talks about the benefits of Inform 7, a programming language specifically designed for creating interactive fiction games. It's an incredibly impressive bit of work, and is the most promising path toward getting regular folk into programming. I also came across this interesting article from Wolfram: https://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/ https://blog.wolfram.com/2010/11/16/programming-with-natural... which goes into natural-language programming and how they will (hopefully) become dominant in the future.

pintxo 7y ago
Do you have an idea on how to solve the fuzziness and ambiguity problems in spoken language? This IMHO is the largest problem with spoken language, no parentheses, lots of synonyms/homonyms etc.
mpweiher 7y ago
> programming languages becoming closer to spoken languages One word: AppleScript

jbattle 7y ago

We've all seen incredible things built in spreadsheets. Spreadsheets are plenty powerful. I haven't met a clever+motivated person yet that couldn't build something incredible in a spreadsheet. What I think is missing is a way to help the author (and other team members) make sense of the artifact as it gets more complex. Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs. With spreadsheets for example, you are basically forced to find a cell that seems to have data you like. Then you have to back-track formula references + check for macros/scripts and hope that no references have broken. I humbly submit this is a problem that a team like the Coda team should be solving.

infogulch 7y ago
Excel needs exactly one thing to blow open the doors on productive programming: a new "function" data type. Since it's just a data type, you put it in a cell just like any other data type. Have some way to call it, like `A1(arg1, arg2)` or something. Now you can leverage the full capabilities of Excel to manage it, name it (named ranges), etc just like other data. A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.
- ahane 7y ago
  sounds like a great idea
- jagged-chisel 7y ago
  Sounds like you want to move VBA into the cell. I issue no opinion on doing that, just offering an observation.
  - infogulch 7y ago
    Actually you make a great point (thank you!), but honestly I wouldn't want it to have anything to do with VBA. For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.

mfer 7y ago

This reminds me a lot of Word. You can embed a spreadsheet and you can add code to the document (I even remember using VBScript back in the day). What's old is new again?

datavirtue 7y ago

Uh. No.

mmphosis 7y ago

I like going the other way where as a "Programmer" I don't need to program so many things. Most "things" can be declared: text, html, lists, trees, tables, databases, ... For example in XFCE, I can add an "Applications Menu" to the menubar (panel) and use a custom menu file with a list (or tree) of programs to run. The icons, labels and how to run the programs are declared in .desktop files -- no "programming" required.

Discombulator 7y ago

I have not looked into Coda yet, but have a few observations on the user / programmer divide. To me, spreadsheets are just another programming paradigm. I have seen business users build impressive things using Excel (excluding here VBA). I'd even say that in terms of raw productivity (i.e., just in terms of business problems solved over time, without any consideration for maintainability etc), the spreadsheet paradigm is vastly superior to the regular textual programming paradigm – as long as the problem is simple enough. And most of normal business is dead simple. As soon as the process or problem hits a certain complexity, the Excel solution becomes painful to use, understand and change. I believe this is in part specifically fault of the tool - while Microsoft has been doing a great job in terms of power user features (Power Query, PowerPivot), they have apparently not been willing to extend the spreadsheet paradigm itself to meet the requirements we demand from business software, which is a pity and missed opportunity. Secondly, what I have also observed is that most users, even users building complex workbooks, are not willing to make the jump to textual programming (e.g., VBA). I think programming in general requires a high level of frustration tolerance that most people are not willing to bring up except when they really have to (e.g., to use Excel, which is basically unavoidable in 99% of businesses). To summarize, there is still room to come up with a system that makes building simple things as simple as Excel, while being flexible enough that it scales to meet production software requirements.

golover721 7y ago

What id love to see more is blurring the line between user and designer. Too often software gets in the way of the user and simple tweaking to an interface etc. can make a world of difference. Unfortunately this is usually either not possible or involves a user navigating endless configuration options or worse configuration files. Maybe that’s not a big deal to us in the software industry but it is a huge problem for your average user.

AnIdiotOnTheNet 7y ago
I agree. There's no reason we can't have this, we've had tools like Delphi and VB for a long time now. Why can't I just choose widgets from a palette and make my own Outlook interface? Maybe it could even be taken a step further and turn it into a UNIX pipeline composition equivalent in GUI form. Trying to imagine what a system could look like, I see a kind of tiling window manager in which you can place arbitrary widgets (list views, sliders, text entry, etc) and hook together their inputs and outputs, maybe with a little scripting glue.