Future of programs, sites, and apps
There are three types of software that I would like to talk about. Programs you install in your computer, sites you open in the web and apps you download on your device. Usually, even they are called the same — ‘applications’, in this article, however, for clarity I have added some distinction in terms.
All three types often perform the same tasks, but somehow there are still major differences that are always present, always in the back of your mind, always kind of getting in the way. Even if it is 3 versions of the same enterprise software. Something is not fully said out loud about the downsides of each type of software. And what could be done about it?
And yes, before you say it — there are several more types of software that we are not going to discuss today. No chatbots, voice assistants or embedded programming of killbot swarms.
First I will shortly go through all three application types and then will present to you several ideas I have on how current systemic faults could be improved in a feasible manner. Enjoy.
Programs. Applications on your PC, Mac or Linux.
Out of three, this is the type of software that has been with us the longest. You used to get it on floppy disks or CDs, and now you download it from the internet.
But it is still the same, it works offline most of the time, it generates tons of files on your hard drive, you might even still be able to buy it outright without signing up for some kind of subscription deal.
Also, it neatly uses all the time tested features of your operating system. You can switch to the next app with the shortcut, you can minimize or resize it separately from other apps, you can see how much computing power it is consuming and so on.
Of course, you can also damage it by messing with its files or killing it off in the middle of some important process. Or it can damage your operating system by doing something not fully appropriate.
Overall there is some kind of raw power that sometimes gets out of control, but when properly controlled can deliver a lot of punch.
Sites. Applications that you open in the browser.
Web-based software has revolutionized the way software is developed, distributed and used. I am not going to describe here all the implications of that, only will leave with you nugget of thought — it could be that web enterprise software revolution is the single thing that has kept MacOS relevant and why it has experienced this surge of revival among creatives of all types.
It is always available, from any device, as long as you remember your password. Or at least your Google or Facebook password. It is always up to date, most of the time it is not possible to even open an older version of it.
At the same time, it does not use all those nice features creators of your operating system have so painstakingly built. It is living inside of the browser, which is a real system program, but each web site is nothing more than a tab or a window of it. If you use tabs, as browsers are configured by default, then you can’t easily arrange sites side by side, or switch to it separately or easily find it among other tabs. If you move it as a separate browser window, then it still is hard to find among other browser windows, all of them are also brought forward every time you focus on one of them and in general, they do not feel very native to the operating system.
Apps. Applications that you install on your mobile.
The newest category of the three. For more than ten years apps have been around, and you can find an app version of most of the most important enterprise software programs. And devices, where you can install apps, are cheap and easily available. And ever since the iPad was launched, people have been predicting the end of the PC era and the rise of apps.
Yet PCs are not dead. Apps have not taken over and besides niche cases, most work is still done on PCs. Why is that? Of course, there always some legacy software that is never going to get ported over, but even newly established enterprises are supplying their workers with laptops not tablets. Why is that?
Apps can do so many things. You can do data entry, you can browse the data, you can do sales, you can take notes, you can even fill in spreadsheets. Plus you can also take photos much more easily and know your location, and use gestures, and accelerometer, biometric sensors and more. Probably there is more checkboxes ticket in a few year old iPad than in your new laptop. And it is very mobile.
Yet data input speed is glaringly slow. Typing with fingers on glass is just not comparable with any, even the worst, keyboard. and gestures and taps are fine, but for a lot of more advanced work, you need that trackpad or mouse to click on exactly right pixel, not in its general vicinity.
Of course, you can attach a keyboard and add a Bluetooth mouse to your tablet. And after a decade of evolution, you can also put some apps side by side. Yet somehow this contraption still feels like a substitute, not like a real thing. Why?
Main differentiator — interfaces between apps.
Originally there was pretty much only one way how programs could interact with one another. By using files in the hard drive. Files initially were all looking the same, but later also type extensions were added. Now also laymen could understand what can be done with each file. Relatively straightforward concept — each file type can be opened by a particular set of programs and if you try to open it by some other program, it will not be possible.
Generally, it has worked well like that, and if a new type of file is added, then a new extension is created, not to mess up this widely understood idea. Of course, there can be some technical files that are completely incompatible, yet still share extension, but as long as consumers are not required to use them, it is still fine, as the idea of interoperability is preserved.
Later on, also clipboard was added, so you can copy-paste things between separate programs. At first, you could paste only text, but later different programs started to recognize images, and also to preserve rich formatting of the text (although as well all know, that is still a messy business).
Sometimes it goes further, like, if you copy something from one Office program to another it might try to embed the object, instead of changing it into text or image. This feature is hard to predict and adapt to even after it has been there for more than 20 years. Is it editable if it is embedded? will anybody else be able to edit it? Or maybe it is just a link to the original document? Who knows.
When web sites that do enterprise software became a thing, they were initially built with various browser add-ons, like Java Applets or Microsoft ActiveX, to mimic the native OS-level capabilities. Yet they ended up neither working properly like native programs, nor retaining amazing multi-platform capabilities of real web sites. And due to security issues, they often had a hard time working with files on your computer, and even with the clipboard.
Browsers evolved, addons were dropped, and now we can enjoy web-based software at its best. Yet it still has trouble with the clipboard. you can copy and paste text relatively predictably. But something more than text? Results are rarely predictable and as good as you would expect in the native program.
And with files, the situation is even worse. There is no way of your browser-based spreadsheet software to open a folder on your computer and then select a couple of files. It is not secure enough, so it is not possible. Full stop. You can only “upload” files using the means built into your browser. And all nice file handling features of your OS are just not used.
Correlated with this issue is also the fact that authors of web sites are not generating many files either. Everything you create is saved in “the cloud”, which in this case means, in the server of the web site. Not accessible directly as a file by you. You can’t back-up it, you can’t monitor it, you can’t share it with your colleague by using any other tools. You have to rely on the build-in mechanisms of a particular website. And they are all different. Sometimes you can “export” a file, but that by its very nature is a secondary copy of the actual work you have created.
Mobile apps have it even worse with interfaces. Saving something to files has been added only in very recent versions of IOs, and while it has been around longer in Android, it is still the same type of afterthought as it is on the web. Only files you can access readily and easily in the app are media files. They are segregated separately and you can work with them in many different ways. But any other files? Forget it.
The clipboard is there, but copy-pasting something is way harder than in programs or sites. Primarily just because selecting something to copy often requires precise input. Those mouse-targeted pixels, which are hard to come by in the mobile device input world. And it is a lot less transparent of what exactly gets copied or pasted. You can’t open notepad to see raw contents, it is often just a guess. And sometimes, like when you copy your password or ssh key, every symbol matters.
Forget security issues for a second, and imagine the file system access and the clipboard working the same way in mobile apps, web sites, and native programs. And all programs also being built to take advantage of this fact?
Exactly, that would remove a large part of the awkwardness we have to experience every time we want to do something more advanced with web sites and mobile apps. But due to security risks, that is not going to happen, not like that.
Feasible solutions to the interoperability problem.
The first possibility is to re-embrace files again. In mobile apps, it is already slowly happening, and in web sites, it also could start moving in the same direction.
Apple and Google have to actively encourage app developers to use file interfaces. They have already built the capabilities, but now it should be brought to the level that this is the default way people would expect their creative work to be saved.
To keep the system secure, and files easily accessible on other devices, devices need to rely on cloud file syncs, instead of direct raw access to the phone file system. Apple has done a good job in allowing Dropbox, google drive and iCloud folders to be first-class citizens in its Files app. a couple more releases and it will feel more and more like the cornerstone of the mobile landscape instead of an afterthought. It needs to be just as ubiquitous as “Media” or “Gallery” is on mobile phones, and it needs to play with all the cloud storage partners fairly, then it will be a success.
While for apps it is already on the way of getting fixed, for web sites it is a lot worse. No-one even seems to be planning to solve the issue. At least not directly as a part of the standard web toolkit.
Creating electron-based installable web apps is the relatively best way that people have come up so far. Even if they tend to be slow and resource hogs. Some would point to progressive web apps (PWA) as a real solution. At least, the thinking direction is correct, although both approaches do not really solve the issue of a standard web site being cut off from file system access, it instead creates a new hybrid app type.
The solution to giving good file access for web sites.
What I propose is something similar to iOS Files app, that would be a built-in feature of the browser (or at least a plugin), which would then expose all the cloud drives that user of this computer is currently using. and then this sandboxed filesystem would be made available to the web apps.
The site would then access this API, by asking permission first of course, and would be able to write and read its system and config files from the folder that you give to it. Of course, web sites have been working well without such explicit system file storage, so there is no grand need for it, although they have had to store mini files called cookies to keep your preferences locally. All those could go into the new files API.
And when saving new documents, you could explicitly point to your cloud documents folder, Dropbox, Google drive or more exotic providers. And the site would not be able to push you in one particular direction.
You as a user would win a lot. Web applications would become more interoperable again, you would be able to bring your application settings to other devices or browsers, without relying on browser built-in cloud sync capabilities (that are less than transparent). And when privacy regulations are tightened again, web sites might be forced to store more and more of their data in the user-controlled location, not on their servers. Also, corporate security standards would become a lot easier to enforce.
Improving clipboard
The clipboard is a beautiful non-file interface between applications. It has worked well for decades and it will keep working. It already has a lot of interoperability, but both web site and mobile app developers need to be pushed to use it more and use it better. If Google and Apple would tweak their app store algorithms to favor apps who have built better and better implementations of standard clipboard it would already be a great step forward.
For example, your calorie counting and exercise tracking app could allow you to copy your daily results with one click. And it would end up formatted as a markdown table when pasted.
Or food delivery app would allow to copy your order and when pasted it would show up as image with both visual and textual depiction of what you have ordered. Or maybe even richer format, that allows some interactivity, although that already sounds like something embeddable and that depends heavily on the place where content is pasted.
In any case, some gentle nudge from the vendors, and this functionality would become a lot more useful in the phone next to you.
Pushing the boundaries into the 21st century.
In the nineties, Microsoft was big on advanced interactions between applications, all those OLE and embedded ActiveX concepts. All those initiatives ended horribly. But that does not mean that this idea can’t be given a new life in a way that would address the needs of current users and by using the capabilities of current and future generations of the hardware.
Imagine all those side-by-side windows that all the operating systems now offer. They are neat, yet somehow apps do just that — they sit next to each other, without any interactivity beyond that. What could happen if the OS would allow apps to influence each other when they are in this side-by-side mode?
Simplest ideas would be on a system level. For example, you have a file explorer app to the left and media viewer to the right. Browsing through files could use media viewer to display their contents automatically, as you switch focus. And there would be no need for the little ugly preview functionality that is built into the browser. And the user would be able to switch preview software to another one, if he so fancies, thus pushing innovation. And media is not necessarily only images, it would be also videos, 3d graphics files, spreadsheets or exotic formats used by niche medical software.
Shared Context
Besides simple preview, apps could also share context between them. Imagine on the left you open a sales pipeline app, on the right you open spreadsheet editor. And then when you select a specific sales lead, its associated proposal sheet is opened. And when you switch from the spreadsheet to the image editor, it shows you a gallery of the pictures from the last sales meeting, where you can edit the picture that you had taken of the whiteboard. And when you switch on the right side from the image editor to your corporate task management software, then a project related to the sales lead opens automatically. You add a couple of tasks, change the status of some. And then you switch left side application from the pipeline to time reporting tool. And it links up with the project on the right side and allows you to report the time you have spent on it today.
On the next level of difficulty would be apps that enhance each other. One could be the main software, another one its plugin or extension. Or maybe one would be controlling another one in deeper detail. For example, one could be a point of sales application, and another would be a diagnostics app that allows uploading new data. Or one would be gallery app, while another would create image sets out of the gallery images and would reorganize its contents.
Summary of my excitement
The future is bright for the interaction of all the multitude of software we have around us. We just need to push ourselves, our vendors, and our developers into something amazing. Especially if ‘we’ are responsible for OS-level innovation. So please share this with the folks at Microsoft, Apple, and Google. Can’t wait for what the future will bring!
This article is part of a series of articles dedicated to user interfaces:
- Real Future of AR/VR input interfaces
- Future of programs, sites and apps
- What would a next-gen OS interface look like?
While you are here, please check out my new book “The Invisible Complexity.” (note that for shipping to Europe, it is better to use the amazon.de site instead. And the same goes for UAE — use amazon.ae site.)
In the book, I explore how large enterprises’ IT and business functions keep fighting about everything all the time. Why they do it, what drives them, what goals are set for them, and so on. I dive deep into thinking about how various psychological quirks that are part of our human condition are at fault most of the time.
How software architecture choices reflect the pros and cons of particular solutions and the requirements for the enterprise architect, goals set to the IT director, and what the CEO wants to say in the next quarterly earnings call. Everything is always interconnected, and it is a pure joy to try to untangle it all.
There are no magical three-step solutions provided in the book, but it will give you a lot of extra clarity of corporate technology affairs and some tools on how to influence them.
And if you live in the Baltics, do not hesitate to sign up for Fundvest, a mobile-first long-term investment platform that I have co-founded.
