Re: [fonc] Task management in a world without apps.
Instead of 'applications', you have objects you can manipulate (compose, decompose, rearrange, etc.) in a common environment. The state of the system, the construction of the objects, determines not only how they appear but how they behave - i.e. how they influence and observe the world. Task management is then simply rearranging objects: if you want to turn an object 'off', you 'disconnect' part of the graph, or perhaps you flip a switch that does the same thing under the hood. This has very physical analogies. For example, there are at least two ways to task manage a light: you could disconnect your lightbulb from its socket, or you could flip a lightswitch, which opens a circuit. There are a few interesting classes of objects, which might be described as 'tools'. There are tools for your hand, like different paintbrushes in Paint Shop. There are also tools for your eyes/senses, like a magnifying glass, x-ray goggles, heads-up display, events notification, or language translation. And there are tools that touch both aspects - like a projectional editor, lenses. If we extend the user-model with concepts like 'inventory', and programmable tools for both hand and eye, those can serve as another form of task management. When you're done painting, put down the paintbrush. This isn't really the same as switching between tasks. I.e. you can still get event notifications on your heads-up-display while you're editing an image. It's closer to controlling your computational environment by direct manipulation of structure that is interpreted as code (aka live programming). Best, Dave On Thu, Oct 31, 2013 at 10:29 AM, Casey Ransberger casey.obrie...@gmail.com wrote: A fun, but maybe idealistic idea: an application of a computer should just be what one decides to do with it at the time. I've been wondering how I might best switch between tasks (or really things that aren't tasks too, like toys and documentaries and symphonies) in a world that does away with most of the application level modality that we got with the first Mac. The dominant way of doing this with apps usually looks like either the OS X dock or the Windows 95 taskbar. But if I wanted less shrink wrap and more interoperability between the virtual things I'm interacting with on a computer, without forcing me to multitask (read: do more than one thing at once very badly,) what's my best possible interaction language look like? I would love to know if these tools came from some interesting research once upon a time. I'd be grateful for any references that can be shared. I'm also interested in hearing any wild ideas that folks might have, or great ideas that fell by the wayside way back when. Out of curiosity, how does one change one's mood when interacting with Frank? Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
It's worth noting that this was the scheme at PARC and was used heavily later in Etoys. This is why Smalltalk has unlimited numbers of Projects. Each one is a persistant environment that serves both as a place to make things and as a page of desktop media. There are no apps, only objects and any and all objects can be brought to any project which will preserve them over time. This avoids the stovepiping of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the objects, and George Bosworth's PARTS system showed a similar but slightly different way. Also there is no presentation app in Etoys, just an object that allows projects to be put in any order -- and there can many many such orderings all preserved -- and there is an object that will move from one project to the next as you give your talk. Builds etc are all done via Etoy scripts. This allows the full power of the system to be used for everything, including presentations. You can imagine how appalled we were by the appearance of Persuade and PowerPoint, etc. Etc. We thought we'd done away with both operating systems and with apps but we'd used the wrong wood in our stakes -- the vampires came back in the 80s. One of the interesting misunderstandings was that Apple and then MS didn't really understand the universal viewing mechanism (MVC) so they thought views with borders around them were windows and view without borders were part of desktop publishing, but in fact all were the same. The Xerox Star confounded the problem by reverting to a single desktop and apps and missed the real media possibilities. They divided a unified media world into two regimes, neither of which are very good for end-users. Cheers, Alan From: David Barbour dmbarb...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Thursday, October 31, 2013 8:58 AM Subject: Re: [fonc] Task management in a world without apps. Instead of 'applications', you have objects you can manipulate (compose, decompose, rearrange, etc.) in a common environment. The state of the system, the construction of the objects, determines not only how they appear but how they behave - i.e. how they influence and observe the world. Task management is then simply rearranging objects: if you want to turn an object 'off', you 'disconnect' part of the graph, or perhaps you flip a switch that does the same thing under the hood. This has very physical analogies. For example, there are at least two ways to task manage a light: you could disconnect your lightbulb from its socket, or you could flip a lightswitch, which opens a circuit. There are a few interesting classes of objects, which might be described as 'tools'. There are tools for your hand, like different paintbrushes in Paint Shop. There are also tools for your eyes/senses, like a magnifying glass, x-ray goggles, heads-up display, events notification, or language translation. And there are tools that touch both aspects - like a projectional editor, lenses. If we extend the user-model with concepts like 'inventory', and programmable tools for both hand and eye, those can serve as another form of task management. When you're done painting, put down the paintbrush. This isn't really the same as switching between tasks. I.e. you can still get event notifications on your heads-up-display while you're editing an image. It's closer to controlling your computational environment by direct manipulation of structure that is interpreted as code (aka live programming). Best, Dave On Thu, Oct 31, 2013 at 10:29 AM, Casey Ransberger casey.obrie...@gmail.com wrote: A fun, but maybe idealistic idea: an application of a computer should just be what one decides to do with it at the time. I've been wondering how I might best switch between tasks (or really things that aren't tasks too, like toys and documentaries and symphonies) in a world that does away with most of the application level modality that we got with the first Mac. The dominant way of doing this with apps usually looks like either the OS X dock or the Windows 95 taskbar. But if I wanted less shrink wrap and more interoperability between the virtual things I'm interacting with on a computer, without forcing me to multitask (read: do more than one thing at once very badly,) what's my best possible interaction language look like? I would love to know if these tools came from some interesting research once upon a time. I'd be grateful for any references that can be shared. I'm also interested in hearing any wild ideas that folks might have, or great ideas that fell by the wayside way back when. Out of curiosity, how does one change one's mood when interacting with Frank? Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list
Re: [fonc] Task management in a world without apps.
Alan Kay alan.n...@yahoo.com writes: One of the interesting misunderstandings was that Apple and then MS didn't really understand the universal viewing mechanism (MVC) so they thought views with borders around them were windows and view without borders were part of desktop publishing, but in fact all were the same. When we design an environment/framework, there are always tradeoffs to make when deciding what capabilities to include in the medium. A common problem is capabilities becoming obsolete and being worked around, for example many filesystems have provided metadata facilities over the years, but these have all hit limits which end up being worked around by storing metadata in files, making the FS unnecessarily complex. Another problem is restricting the technology which can be used by clients; for example browsers will only run Javascript, which made them 'toys' for many years in the eyes of C/C++/Java programmers. Unfortunately, a big factor is also the first-to-market pressure, otherwise known as 'Worse Is Better': you can reduce the effort required to implement a system by increasing the effort required to use it. The classic example is C vs LISP, but a common one these days is multithreading vs actors, coroutines, etc. In the case of an OS, providing a dumb box to draw on is much easier than a complete, complementary suite of MVC/Morphic/etc. components, even though developers are forced to implement their own incompatible integration layers, if they bother at all. This is why I'm not a fan of HTML5 canvas, since it's a dumb box which strips away the precious-little semantics the Web has, and restrict mashups to little more than putting existing boxes next to each other. Cheers, Chris PS: I spent one summer living in Etoys on my OLPC XO-1, creating physics simulations. It's a very nice system once it's gotten used to. It's one thing to drag and drop tiles to make a scribbled picture start spinning, it's quite another to make the tiles themselves start spinning :) PPS: I keep meaning to pull those those simulations off my XO and upload them to squeakland. Unfortunately I reached a point where they maxed out the RAM so I couldn't finish them :( ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
n 31 October 2013 17:37, Chris Warburton chriswa...@googlemail.com wrote: …many filesystems have provided metadata facilities over the years, but these have all hit limits which end up being worked around by storing metadata in files, making the FS unnecessarily complex. ReiserFS, from at least version 3, implemented extended attributes (xattrs) as directories, meaning that there were no arbitrary limits. I never understood why other FSes didn't do the same, as it surely makes the code simpler than having a special fixed-size implementation. However, having thought about ResierFS, the idea of xattrs themselves seem pretty odd, because what is data and what is metadata can depend on context, plus of course you're never going to get all the metadata out of files and into FS attributes; and it seems odd to have two different fundamental APIs (regular file API and xattr API) to manipulate different instances of the same on-disk representation (files in directories). ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Hi Chris, I get your point but I have really grown to dislike that phrase Worse is Better. Worse is never better. Worse is always worse and worse never reduces to better under any set of natural rewrite rules. Yes there are advantages in the short term to being first to market and things that are worse can have more mindshare in the arena of public opinion. Worse is Better sounds like some kind of apology to me. cheers, -David Leibs On Oct 31, 2013, at 10:37 AM, Chris Warburton chriswa...@googlemail.com wrote: Unfortunately, a big factor is also the first-to-market pressure, otherwise known as 'Worse Is Better': you can reduce the effort required to implement a system by increasing the effort required to use it. The classic example is C vs LISP, but a common one these days is multithreading vs actors, coroutines, etc. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
In the spirit of equivocation when I look at the world we live in and and note the trends then I feel worse, not better. -David Leibs On Oct 31, 2013, at 11:10 AM, David Barbour dmbarb...@gmail.com wrote: The phrase Worse is better involves an equivocation - the 'worse' and 'better' properties are applied in completely different domains (technical quality vs. market success). But, hate it or not, it is undeniable that worse is better philosophy has been historically successful. On Thu, Oct 31, 2013 at 12:50 PM, David Leibs david.le...@oracle.com wrote: Hi Chris, I get your point but I have really grown to dislike that phrase Worse is Better. Worse is never better. Worse is always worse and worse never reduces to better under any set of natural rewrite rules. Yes there are advantages in the short term to being first to market and things that are worse can have more mindshare in the arena of public opinion. Worse is Better sounds like some kind of apology to me. cheers, -David Leibs On Oct 31, 2013, at 10:37 AM, Chris Warburton chriswa...@googlemail.com wrote: Unfortunately, a big factor is also the first-to-market pressure, otherwise known as 'Worse Is Better': you can reduce the effort required to implement a system by increasing the effort required to use it. The classic example is C vs LISP, but a common one these days is multithreading vs actors, coroutines, etc. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Alan, I appreciate the peek into history! I had to look up Fabrik and PARTS. I love the idea of running presentations as live coding; in fact, I shall endeavor to do so for any talks I give regarding my own system. Smalltalk has a lot of good ideas, but they're sometimes mixed with not-so-great ideas and difficult to separate. Even today, the idea of applications as objects in the IDE gives results in a knee-jerk rejection response from many people who fear a tight coupling (to share the app, I need to share the whole IDE!) based largely on Smalltalk's example. Language-layer security and an alternative state model could address this issue, enabling easy decoupling of behavior from environment. Similarly, MVC has several properties that I believe have been more harmful than helpful. Models in MVC systems are neither compositional nor open, and controls were decoupled from views, which hinders direct manipulation and physical metaphors. More modern variations such as MVVM are improvements, but they're still a long way from collaborative projectional editors or spreadsheets. But the good ideas should be preserved, separated from the chaff, reused in new contexts. It's interesting to pick apart history and hypothesize why various good ideas have failed to gain traction. Best, Dave On Thu, Oct 31, 2013 at 11:31 AM, Alan Kay alan.n...@yahoo.com wrote: It's worth noting that this was the scheme at PARC and was used heavily later in Etoys. This is why Smalltalk has unlimited numbers of Projects. Each one is a persistant environment that serves both as a place to make things and as a page of desktop media. There are no apps, only objects and any and all objects can be brought to any project which will preserve them over time. This avoids the stovepiping of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the objects, and George Bosworth's PARTS system showed a similar but slightly different way. Also there is no presentation app in Etoys, just an object that allows projects to be put in any order -- and there can many many such orderings all preserved -- and there is an object that will move from one project to the next as you give your talk. Builds etc are all done via Etoy scripts. This allows the full power of the system to be used for everything, including presentations. You can imagine how appalled we were by the appearance of Persuade and PowerPoint, etc. Etc. We thought we'd done away with both operating systems and with apps but we'd used the wrong wood in our stakes -- the vampires came back in the 80s. One of the interesting misunderstandings was that Apple and then MS didn't really understand the universal viewing mechanism (MVC) so they thought views with borders around them were windows and view without borders were part of desktop publishing, but in fact all were the same. The Xerox Star confounded the problem by reverting to a single desktop and apps and missed the real media possibilities. They divided a unified media world into two regimes, neither of which are very good for end-users. Cheers, Alan -- *From:* David Barbour dmbarb...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Thursday, October 31, 2013 8:58 AM *Subject:* Re: [fonc] Task management in a world without apps. Instead of 'applications', you have objects you can manipulate (compose, decompose, rearrange, etc.) in a common environment. The state of the system, the construction of the objects, determines not only how they appear but how they behave - i.e. how they influence and observe the world. Task management is then simply rearranging objects: if you want to turn an object 'off', you 'disconnect' part of the graph, or perhaps you flip a switch that does the same thing under the hood. This has very physical analogies. For example, there are at least two ways to task manage a light: you could disconnect your lightbulb from its socket, or you could flip a lightswitch, which opens a circuit. There are a few interesting classes of objects, which might be described as 'tools'. There are tools for your hand, like different paintbrushes in Paint Shop. There are also tools for your eyes/senses, like a magnifying glass, x-ray goggles, heads-up display, events notification, or language translation. And there are tools that touch both aspects - like a projectional editor, lenses. If we extend the user-model with concepts like 'inventory', and programmable tools for both hand and eye, those can serve as another form of task management. When you're done painting, put down the paintbrush. This isn't really the same as switching between tasks. I.e. you can still get event notifications on your heads-up-display while you're editing an image. It's closer to controlling your computational environment by direct manipulation of structure that is interpreted as code (aka live programming). Best,
Re: [fonc] Task management in a world without apps.
It can be depressing, certainly, to look at the difference between where we are and where we could be, if we weren't short-sighted and greedy. OTOH, if you look at where we are vs. where we were, I think you can find a lot to be optimistic about. FP and types have slowly wormed their way into many PLs. Publish-subscribe is gaining mindshare. WebRTC, HTML Canvas, WebSockets, etc. have finally resulted in a widespread VMs people are actually willing to use (even if they could be better). On Thu, Oct 31, 2013 at 1:16 PM, David Leibs david.le...@oracle.com wrote: In the spirit of equivocation when I look at the world we live in and and note the trends then I feel worse, not better. -David Leibs On Oct 31, 2013, at 11:10 AM, David Barbour dmbarb...@gmail.com wrote: The phrase Worse is better involves an equivocation - the 'worse' and 'better' properties are applied in completely different domains (technical quality vs. market success). But, hate it or not, it is undeniable that worse is better philosophy has been historically successful. On Thu, Oct 31, 2013 at 12:50 PM, David Leibs david.le...@oracle.comwrote: Hi Chris, I get your point but I have really grown to dislike that phrase Worse is Better. Worse is never better. Worse is always worse and worse never reduces to better under any set of natural rewrite rules. Yes there are advantages in the short term to being first to market and things that are worse can have more mindshare in the arena of public opinion. Worse is Better sounds like some kind of apology to me. cheers, -David Leibs On Oct 31, 2013, at 10:37 AM, Chris Warburton chriswa...@googlemail.com wrote: Unfortunately, a big factor is also the first-to-market pressure, otherwise known as 'Worse Is Better': you can reduce the effort required to implement a system by increasing the effort required to use it. The classic example is C vs LISP, but a common one these days is multithreading vs actors, coroutines, etc. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
On Thu, Oct 31, 2013 at 12:37 PM, Chris Warburton chriswa...@googlemail.com wrote: In the case of an OS, providing a dumb box to draw on is much easier than a complete, complementary suite of MVC/Morphic/etc. components, even though developers are forced to implement their own incompatible integration layers, if they bother at all. This is why I'm not a fan of HTML5 canvas, since it's a dumb box which strips away the precious-little semantics the Web has, and restrict mashups to little more than putting existing boxes next to each other. There is worse is better, but there also is less is more. From a limited perspective, it may be difficult to tell the difference. We should be careful to not mistake these. In this case, the other POV is that the canvas is a humble box that doesn't arrogantly presume it knows better than its users how to format a display. :) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Essentially a problem oriented window is what you want. In something like Lively Kernel, this becomes a problem oriented widget. On Oct 31, 2013 10:30 AM, Casey Ransberger casey.obrie...@gmail.com wrote: A fun, but maybe idealistic idea: an application of a computer should just be what one decides to do with it at the time. I've been wondering how I might best switch between tasks (or really things that aren't tasks too, like toys and documentaries and symphonies) in a world that does away with most of the application level modality that we got with the first Mac. The dominant way of doing this with apps usually looks like either the OS X dock or the Windows 95 taskbar. But if I wanted less shrink wrap and more interoperability between the virtual things I'm interacting with on a computer, without forcing me to multitask (read: do more than one thing at once very badly,) what's my best possible interaction language look like? I would love to know if these tools came from some interesting research once upon a time. I'd be grateful for any references that can be shared. I'm also interested in hearing any wild ideas that folks might have, or great ideas that fell by the wayside way back when. Out of curiosity, how does one change one's mood when interacting with Frank? Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
