4 ms·

A lot of replies are missing the point. It's not "apps integrate better with each other". It is "there are no apps". So what would Adobe sell, if not the "Ph

A lot of replies are missing the point. It's not "apps integrate better with each other". It is "there are no apps". So what would Adobe sell, if not the "Photoshop app"? It would sell the Photoshop "menu of filters", the "selector toolbox", the "color histogram view" and such. But the workspace where you see the image and apply the selectors or filters would be outside Photoshop itself. It would be a standard part of the system, where the image could come from and go into another organizing system (possibly provided by another vendor). You could mix organizing systems, sharing/versioning systems and filters/selectors/menus/views from various vendors, commercial or free or open source. This would apply not just to images, but to all kinds of media - movies, documents, including "code".

belugacat 6y ago
The big issue here being that Adobe has zero interest in selling this, and this kind of model would not lead to a $250B market cap business. Adobe wants to tightly control the experience, record how you use the software, display their own branding, try to upsell you on their other products and services, etc etc. Software businesses care about controlling the UX/branding/etc. tightly, because that's where the money is - not selling "menus of filters". That's why every webpage is nowadays is a SPA that hijacks standard browser features like scroll and copy paste and no one looking to make money was ever interested in the semantic web. I'm very aligned with the views exposed in the article and your comment, and have been working on some open source approaches to it in my free time for a few years now. I figure that the only way that it can maybe work is to make something for myself that I love using, and maybe some other enthusiasts will like it too and it can grow a bit from there. But there's probably no way it would ever meaningfully compete with Photoshop, because it goes against every economic incentive that software companies have. In parallel, I also suspect that that's why the design/UX of open source applications tend to be extremely poor in general - great, tight design is expensive and needs strong economic incentives.
- rogual 6y ago
  Yes, open source sounds like the right place for ideas like this, for the reasons you mention. Consider Emacs, whose hundreds of extensions give you this mix-and-match setup, or something similar to it. I think I might really like working with a system that works in this way, with a bit from here, a bit from there -- but I'd want access to the code, because it would take a lot of tweaking to make things nice.
- SilasX 6y ago
  That is exactly my thinking. This model goes contrary to the needs of propriety software, to lock you into a whole system you can charge for. (And FWIW, I don't have the vendetta against proprietary software like a lot of HN seems to, so I'm sympathetic here about breaking the incentives for production of software that legitimately needs paid devs and can't get enough via donations. But if Open Source teams can make it work, I'm all for that!) OTOH, as a general model ... I can see why it has failed to pick up, at least with typical devs and prevailing software practices. It requires a level of care about interfaces and interoperability that is not very common. More often, you see APIs broken willy-nilly with no functional need to. Stable standards for exchange of data require a lot of work and are the exception -- even when you have them, there will be the warts that reveal abstraction leakage. (Another comment mentions how HTML was quickly broken.[0]) The no-app approach with basically be that fight, but for every external touch point, of every module. I do hope the dev world can make that work ... but also: understand what you're fighting against. [0] https://news.ycombinator.com/item?id=25021180 https://news.ycombinator.com/item?id=25021180
jcelerier 6y ago
It would likely mean losing lots of integration and special features though. If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ? You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :) Also enjoy teaching students or even learning to do anything. With big software like Photoshop (or musical equivalents), you can take the book that comes with it and become fairly proficient at pretty much everything that the app allows. How would that work if there is no individual software ? What screenshot do you show on the docs ? How do you make YouTube videos when most people may have a different setup than yours ?
- TeMPOraL 6y ago
  > If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ? Simple. The object that owns the "modal UI" part would own, or at least aggregate, a right-click menu. The canvas shouldn't be busy handling right-click menus anyway, it should provide an interface to access and manipulate the underlying bitmap. The "modal UI" would own the right-click handler, and would populate the context menu with a filtered choice of options, including functionality provided by different objects. It's more complex than naive approach with everything being owned by a single one, but fundamentally not that different from a design you'd arrive to if you were intended to allow for plugins in your application - except now the "plugin manager" isn't in your app, but in your OS. > You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :) Krita people could provide a 10-bit canvas implementation that offers an 8-bit canvas-compatible interface. Alternatively, your UI could require canvas objects implementing a 10-bit canvas interface, but you - or a third party - would also provide an adapter (polyfill, as the kids say today) that wraps the MS Paint 8-bit canvas behind a 10-bit canvas interface. -- The teaching point you bring up is a strong one, and I don't have a good answer. I think Microsoft's COM, the Emacs ecosystem and every game with a large modding scene (e.g. Kerbal Space Program) all provide evidence that a fully interoperable system turns users into sysadmins. You don't need to code to use such a system, but you'd better be prepared to be aware of all the components, and do a bit of configuring, if you want anything other than the defaults. (But, as every game with a large modding scene demonstrates, it's not necessarily that hard for regular non-tech-savvy users either.)
djrobstep 6y ago
Exactly - for example, resizing photos. Imagine a resizer object, that could be used: - to implement resizing in various interfaces for image objects - in a script (think unix pipes but operating over real image objects, not streams of bytes) - wired up to various events and data sources for automation (when my aunt emails me a picture, resize it and put it in this folder) The resizer wouldn't be hidden behind some app's implementation - it would be a first class object you can inspect and interact with ("ok, looks like this resizer objects takes an image object as an inputs and outputs another image. i'll drag an image onto it right now to try it out")
- marcus_holmes 6y ago
  One of the big problems I've seen with multi-vendor systems that co-operate is if something didn't work. It was never clear where the problem was because the system incorporated multiple products from multiple vendors. So if your resizer object didn't work for some images after upgrading Photoshop, but it used to in the old version, how do you get that fixed? In a single-vendor program, it's clearly a bug in the program and you can hand it back to the vendor to fix it. When multiple vendors are involved, it gets way more complicated. Each has a tendency to blame the other, and not take responsibility for the problem. Each will claim that they are coding to the interface specification. And they might be, it's just that the specification isn't tight enough to make all interactions bulletproof. I don't really have a solution (apart from "write a really, really, tight interface. No, tighter than that"), but I've seen the problem enough to be skeptical that we can have this. edit: I should add that I wish we could have this.
  - imhoguy 6y ago
    This. It is not just vendors, but also teams within any company. E.g. operating systems: Windows, Android, iOS/OSX - all are composed of modules which are running as isolated processes and communicating over agreed interfaces. Before system upgrade reaches the market there are countless meetings between teams to sort out bugs and design inconsistencies.
lixtra 6y ago
You mean like everything is a file and you could build pipelines of simple commands to modify your data? That’s genius!
- djrobstep 6y ago
  Exactly, but imagine real objects instead of text streams, and rich interfaces instead of lo fi terminals from the 70s.
  - mrmonkeyman 6y ago
    Of course, how brilliant. Now, imagine if I could represent these "real objects" with something as interoperable as, say, plain text. How innovative, imagine this! Now all parts of the system speak an universal language. Break down all barrieres!
askvictor 6y ago
To some degree, Android's Intent system works towards this, in an extensible way.
Someone 6y ago
On the plus side, this could be a way for those who don’t sell apps to compete with the juggernauts. Yes, people could unite to improve, say, GIMP, by writing extensions for it, too, but if such extensions were usable elsewhere, too, maybe, more people would write extensions.
greggman3 6y ago
Microsoft already tried this in in mid 90s. It was called OLE (Object Linking and Embedding). You could embed a photoshop document live in your word document and if you clicked the embedded document the photoshop UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue because things like UI, when you click the embedded document, what should happen? How much of photoshop's ui should be shown vs Word's (the outer app). It was also a nightmare because unless every user had the exact same apps on the exact same version nothing worked. Your embedded photo uses filter XYZ but that's only in version 7+ of whatever app edited it, etc... https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
- Galanwe 6y ago
  Not even mentioning the insane amount of security issues with OLE components.
- djrobstep 6y ago
  Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which are both surmountable problems.
  - WJW 6y ago
    The terminal is absolutely full of apps though. It's literally an environment designed around invoking other programs. Pipelines are indeed very powerful, but mostly for a specific class of tasks. As soon as you need interactivity, the pipeline model losess a lot of benefits. None of the popular databases, web servers, games or office suites are implemented as terminal pipelines. The other problem with pipelines is that while they scale reasonably well with data size, they don't scale quite as nicely with task complexity. A five-program pipeline with complex command line arguments can already be complex to understand. A 500-program pipeline would be a total nightmare, especially when it starts including components for error reporting and retry behavior.
stan_rogers 6y ago
...and you've just turned Phtoshop into a slightly worse version of Gimp. Congratulations. Without adjustment layers and other non-destructive editing features, Photoshop becomes a whole lot less useful as a professional tool.
orbifold 6y ago
Adobe has an API for all of their software, in principle you can hook into it with your own code. The main problem is that the document model are really complex, so I doubt lots of people would do that in their free time.
BlueTemplar 6y ago
This doesn't make any sense. Apps are what allows you to do any work on the data, starting with being able to display the data on a screen (or print it on paper). Data without apps is completely useless.
- bantunes 6y ago
  That's a bit reductive. Surely there could exist a model where work on data doesn't have to be mediated through "apps", and this is what the article refers to.
  - BlueTemplar 6y ago
    "work on data" is the definition of "app". Unless you're willing to go through your hard drive platters yourself with a magnetized needle ? (or whatever the equivalent is for SSDs) EDIT : Though even in that hypothetical case, you would need to follow an "app" (more commonly known under the term "algorithm") to be able to make sense of the magnetic domains that you're detecting !
mmphosis 6y ago
Apple already tried this in in mid 90s. It was called OpenDoc. You could embed a drawing document live in your word processing document and if you clicked the embedded document the drawing UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue because things like UI, when you click the embedded document, what should happen? How much of the drawing's ui should be shown vs word processor's. It was also a nightmare because unless every user had OpenDoc and the exact same components on the exact same version nothing worked. https://en.wikipedia.org/wiki/OpenDoc https://en.wikipedia.org/wiki/OpenDoc

belugacat 6y ago

The big issue here being that Adobe has zero interest in selling this, and this kind of model would not lead to a $250B market cap business. Adobe wants to tightly control the experience, record how you use the software, display their own branding, try to upsell you on their other products and services, etc etc. Software businesses care about controlling the UX/branding/etc. tightly, because that's where the money is - not selling "menus of filters". That's why every webpage is nowadays is a SPA that hijacks standard browser features like scroll and copy paste and no one looking to make money was ever interested in the semantic web. I'm very aligned with the views exposed in the article and your comment, and have been working on some open source approaches to it in my free time for a few years now. I figure that the only way that it can maybe work is to make something for myself that I love using, and maybe some other enthusiasts will like it too and it can grow a bit from there. But there's probably no way it would ever meaningfully compete with Photoshop, because it goes against every economic incentive that software companies have. In parallel, I also suspect that that's why the design/UX of open source applications tend to be extremely poor in general - great, tight design is expensive and needs strong economic incentives.

rogual 6y ago
Yes, open source sounds like the right place for ideas like this, for the reasons you mention. Consider Emacs, whose hundreds of extensions give you this mix-and-match setup, or something similar to it. I think I might really like working with a system that works in this way, with a bit from here, a bit from there -- but I'd want access to the code, because it would take a lot of tweaking to make things nice.
SilasX 6y ago
That is exactly my thinking. This model goes contrary to the needs of propriety software, to lock you into a whole system you can charge for. (And FWIW, I don't have the vendetta against proprietary software like a lot of HN seems to, so I'm sympathetic here about breaking the incentives for production of software that legitimately needs paid devs and can't get enough via donations. But if Open Source teams can make it work, I'm all for that!) OTOH, as a general model ... I can see why it has failed to pick up, at least with typical devs and prevailing software practices. It requires a level of care about interfaces and interoperability that is not very common. More often, you see APIs broken willy-nilly with no functional need to. Stable standards for exchange of data require a lot of work and are the exception -- even when you have them, there will be the warts that reveal abstraction leakage. (Another comment mentions how HTML was quickly broken.[0]) The no-app approach with basically be that fight, but for every external touch point, of every module. I do hope the dev world can make that work ... but also: understand what you're fighting against. [0] https://news.ycombinator.com/item?id=25021180 https://news.ycombinator.com/item?id=25021180

jcelerier 6y ago

It would likely mean losing lots of integration and special features though. If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ? You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :) Also enjoy teaching students or even learning to do anything. With big software like Photoshop (or musical equivalents), you can take the book that comes with it and become fairly proficient at pretty much everything that the app allows. How would that work if there is no individual software ? What screenshot do you show on the docs ? How do you make YouTube videos when most people may have a different setup than yours ?

TeMPOraL 6y ago
> If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ? Simple. The object that owns the "modal UI" part would own, or at least aggregate, a right-click menu. The canvas shouldn't be busy handling right-click menus anyway, it should provide an interface to access and manipulate the underlying bitmap. The "modal UI" would own the right-click handler, and would populate the context menu with a filtered choice of options, including functionality provided by different objects. It's more complex than naive approach with everything being owned by a single one, but fundamentally not that different from a design you'd arrive to if you were intended to allow for plugins in your application - except now the "plugin manager" isn't in your app, but in your OS. > You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :) Krita people could provide a 10-bit canvas implementation that offers an 8-bit canvas-compatible interface. Alternatively, your UI could require canvas objects implementing a 10-bit canvas interface, but you - or a third party - would also provide an adapter (polyfill, as the kids say today) that wraps the MS Paint 8-bit canvas behind a 10-bit canvas interface. -- The teaching point you bring up is a strong one, and I don't have a good answer. I think Microsoft's COM, the Emacs ecosystem and every game with a large modding scene (e.g. Kerbal Space Program) all provide evidence that a fully interoperable system turns users into sysadmins. You don't need to code to use such a system, but you'd better be prepared to be aware of all the components, and do a bit of configuring, if you want anything other than the defaults. (But, as every game with a large modding scene demonstrates, it's not necessarily that hard for regular non-tech-savvy users either.)

djrobstep 6y ago

Exactly - for example, resizing photos. Imagine a resizer object, that could be used: - to implement resizing in various interfaces for image objects - in a script (think unix pipes but operating over real image objects, not streams of bytes) - wired up to various events and data sources for automation (when my aunt emails me a picture, resize it and put it in this folder) The resizer wouldn't be hidden behind some app's implementation - it would be a first class object you can inspect and interact with ("ok, looks like this resizer objects takes an image object as an inputs and outputs another image. i'll drag an image onto it right now to try it out")

marcus_holmes 6y ago
One of the big problems I've seen with multi-vendor systems that co-operate is if something didn't work. It was never clear where the problem was because the system incorporated multiple products from multiple vendors. So if your resizer object didn't work for some images after upgrading Photoshop, but it used to in the old version, how do you get that fixed? In a single-vendor program, it's clearly a bug in the program and you can hand it back to the vendor to fix it. When multiple vendors are involved, it gets way more complicated. Each has a tendency to blame the other, and not take responsibility for the problem. Each will claim that they are coding to the interface specification. And they might be, it's just that the specification isn't tight enough to make all interactions bulletproof. I don't really have a solution (apart from "write a really, really, tight interface. No, tighter than that"), but I've seen the problem enough to be skeptical that we can have this. edit: I should add that I wish we could have this.
- imhoguy 6y ago
  This. It is not just vendors, but also teams within any company. E.g. operating systems: Windows, Android, iOS/OSX - all are composed of modules which are running as isolated processes and communicating over agreed interfaces. Before system upgrade reaches the market there are countless meetings between teams to sort out bugs and design inconsistencies.

lixtra 6y ago

You mean like everything is a file and you could build pipelines of simple commands to modify your data? That’s genius!

djrobstep 6y ago
Exactly, but imagine real objects instead of text streams, and rich interfaces instead of lo fi terminals from the 70s.
- mrmonkeyman 6y ago
  Of course, how brilliant. Now, imagine if I could represent these "real objects" with something as interoperable as, say, plain text. How innovative, imagine this! Now all parts of the system speak an universal language. Break down all barrieres!

askvictor 6y ago

To some degree, Android's Intent system works towards this, in an extensible way.

Someone 6y ago

On the plus side, this could be a way for those who don’t sell apps to compete with the juggernauts. Yes, people could unite to improve, say, GIMP, by writing extensions for it, too, but if such extensions were usable elsewhere, too, maybe, more people would write extensions.

greggman3 6y ago

Microsoft already tried this in in mid 90s. It was called OLE (Object Linking and Embedding). You could embed a photoshop document live in your word document and if you clicked the embedded document the photoshop UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue because things like UI, when you click the embedded document, what should happen? How much of photoshop's ui should be shown vs Word's (the outer app). It was also a nightmare because unless every user had the exact same apps on the exact same version nothing worked. Your embedded photo uses filter XYZ but that's only in version 7+ of whatever app edited it, etc... https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

Galanwe 6y ago
Not even mentioning the insane amount of security issues with OLE components.
djrobstep 6y ago
Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which are both surmountable problems.
- WJW 6y ago
  The terminal is absolutely full of apps though. It's literally an environment designed around invoking other programs. Pipelines are indeed very powerful, but mostly for a specific class of tasks. As soon as you need interactivity, the pipeline model losess a lot of benefits. None of the popular databases, web servers, games or office suites are implemented as terminal pipelines. The other problem with pipelines is that while they scale reasonably well with data size, they don't scale quite as nicely with task complexity. A five-program pipeline with complex command line arguments can already be complex to understand. A 500-program pipeline would be a total nightmare, especially when it starts including components for error reporting and retry behavior.

stan_rogers 6y ago

...and you've just turned Phtoshop into a slightly worse version of Gimp. Congratulations. Without adjustment layers and other non-destructive editing features, Photoshop becomes a whole lot less useful as a professional tool.

orbifold 6y ago

Adobe has an API for all of their software, in principle you can hook into it with your own code. The main problem is that the document model are really complex, so I doubt lots of people would do that in their free time.

BlueTemplar 6y ago

This doesn't make any sense. Apps are what allows you to do any work on the data, starting with being able to display the data on a screen (or print it on paper). Data without apps is completely useless.

bantunes 6y ago
That's a bit reductive. Surely there could exist a model where work on data doesn't have to be mediated through "apps", and this is what the article refers to.
- BlueTemplar 6y ago
  "work on data" is the definition of "app". Unless you're willing to go through your hard drive platters yourself with a magnetized needle ? (or whatever the equivalent is for SSDs) EDIT : Though even in that hypothetical case, you would need to follow an "app" (more commonly known under the term "algorithm") to be able to make sense of the magnetic domains that you're detecting !

mmphosis 6y ago

Apple already tried this in in mid 90s. It was called OpenDoc. You could embed a drawing document live in your word processing document and if you clicked the embedded document the drawing UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue because things like UI, when you click the embedded document, what should happen? How much of the drawing's ui should be shown vs word processor's. It was also a nightmare because unless every user had OpenDoc and the exact same components on the exact same version nothing worked. https://en.wikipedia.org/wiki/OpenDoc https://en.wikipedia.org/wiki/OpenDoc