The recording of Michel Beaudouin-Lafon’s UIST vis...
# thinking-together
b
The recording of Michel Beaudouin-Lafon’s UIST visions talk, “A World Without Apps”, is now online.

https://www.youtube.com/watch?v=ntaudUum06E

g
This talk as some of the same issues of Bret Victor's talk. Yes, in some kind of utopia where there are not bad actors then having all apps share all data is great. But in the real world (the one we have today) we want (well I want) each app to have it's own data because I don't want any app to read my data. I don't want facebook to be reading the data of all my other apps. I don't want every app I download and every library in every app I download to read my context, check my calendar, look at my photos, So, I love the idea, but in reality I have no idea how it would work. I get that it would be great if Uber/Lyft/Grab would look at my calendar and auto-order me a cab when I arrive at the airport and it could even look in my credit card history and figure out which hotel I booked so it knows both I'm at LAX and I'm staying at Hotel X. At the same time I absolutely don't want Uber/Lyft/Grab to have access to that data. Someone brought up the issue after the talk but he basically just dismissed it. I feel like that's really the real issue that has to be solved. The idea of gluing tools together has been around forever. It's failed multiple times. Mostly probably for techincal reasons but now on top of technical reasons we're adding security reasons.
s
This was a good presentation, thanks for sharing, @Brian Hempel. But wow, the Q&A in the end makes me want to get to know the audience much more than the speaker. Super thoughtful questions and not very satisfying answers. On the actual challenges with that vision: On mobile platforms today, we slowly get more control over which data and capabilities we want to share with apps, and a lot of people find that extremely annoying. It's an interesting design challenge to find a good balance here. There are also more and more extensions points added that would take us just a little bit into the direction of that tools/substrates vision, but ironically it's often developers who are not willing to make a feature available to other parts of the system like that, because that breaks their business model. And that's what's really blocking progress: business models. The powerful incentives created through how all this created value is funded have taken us completely off track and into dangerous territory. We happily pay with our information to get stuff for "free", which is why we're not in control of it in the first place. And now almost every big tech company is more interested in learning even more about us to target us better and serve us ads and few really care about better tools for unlocking our creativity.
b
@gman I actually think the security issue is less of a problem. Part of the app-less vision is that it’s your computer doing all the work. You have the right components so that you can build your own tool to look at your own calendar and order your own ride. Each component is sandboxed, simple, and has a type so you can know if it’s not performing any I/O you don’t ask of it.
@Stefan UIST 2020 will be in Minneapolis Oct 20-23 http://uist.acm.org/uist2020/. You could go and find these people. But keep in mind that, as Michel lamented, software is not the main focus anymore. This year’s talks give a sense of the current focus: https://www.youtube.com/playlist?list=PLqhXYFYmZ-Vfu0KfdHiw0oZl50QTEPrBp. We did get Sketch-n-Sketch into UIST though.
p
Security is already a huge concern. You can control which apps can access your camera, but not how your information is used or to whom it’s transmitted. The world we’re trying to imagine here is one intensely focused on data integration, where it should be natural to reason about, and enforce policies around, data flows and provenance.
Think Eve, not.. anything normal.
My questions were the same as some of the ones from the talk: who coordinates the effort to design, build, evaluate, and maintain this system (if it is one system); how is that work sustained; to whom is it accountable and how. And the juicy stuff: what does designing for everyone, doing everything, in every context look like? What are the goals and constraints of the software that would make this possible, maybe easy? As someone in the audience pointed out, people have been thinking about the juicy stuff for a long time. I read a 25-year-old paper on it from the other day. Besides being adorably focused on CLOS, its ideas are very familiar. On the other hand, there has been much discussion and some real innovation in how we coordinate work over the last twenty years (e.g. GitHub, open source business models, OpenCollective). Some of it is relevant to the first question. I very much want a space to talk about these things, ideally with people with real, relevant experience.
b
@Peter Abrahamsen If components are pure functions, then you know that no transmission can happen. We’re just too used to a world where programs can perform arbitrary I/O. The permission you give to the component is not to access the camera (that’s easy, that’s an input to the function) but to access the net—which you would not do with the same component! Instead, you would have component A process your camera data. You’d see the result, so you’d know the extent of information. Component B would have the permission to transmit that to some remote entity and you’d hand off that information to component B.
p
Right. One of the key problems is that if control over your data means components run on hardware you trust, we’ve cut out a lot of sustainability/business models for developing components.
👍 1
So then we ask, if nobody’s trying to fulfill the expectations of venture capital, how can you rely on free labor? What work ought to be coordinated? How much coordination is needed to ensure good outcomes for users? To what extent to different users need to be using the “same” components?
A really useful framing for me has been economical. We kind of vaguely agree on where we’re trying to get to. How do we make it as cheap as possible to achieve that vision? Maybe we don’t need a sizable team in San Francisco toiling for many years to figure all this out?