The Friend Unifying Platform (or FriendUP) is a new operating environment that seeks to more seamlessly and effectively bridge the two dominant productivity, enterprise, and consumer applications platforms in use today: Native applications (as on Windows, Mac, or Linux desktops), and Web-based apps (applications hosted on a central web server or distributed network, as in Amazon’s store, or Facebook’s social network). Of course, most computer users work with both of these platforms daily, for example, by using Windows PC productivity software alongside Web apps accessed within a standard browser such as Google Chrome.
Two Kingdoms… inches apart
Now some might ask, “What’s the problem with this?” Well, we’ve mostly grown accustomed to using these two platforms side-by-side, and basically taken for granted that we’re abiding by two separate paradigms and rule sets, and we’ve mostly accepted the limitations that result.
Over several decades, Microsoft (and similarly Apple for MacOS) has established an effective desktop paradigm with the following basic rules:
Workspace: The user sees a desktop workspace that takes up the full size of one or more display monitors. Several windows will be opened for different native applications, including a Web browser.
Storage: Upon the desktop sits a row of one or more icons representing an on-board HDD (Windows C:), applications or data folder ‘shortcuts’, and possibly network shared storage drives, removable USB devices, peripherals such as printers, and maybe for good measure, a remote Cloud drive, such as MS OneDrive, Google Drive, or DropBox. These all represent your ‘connected’ or accessible storage or hardware devices.
Applications Launch: Either by navigating through drives, data or applications folders, or selecting the central ‘Start’ menu, the user may launch any of the installed or accessible native Windows applications. Multiple applications can be run at once, each with its own window or screen. And each application enjoys common and equal access to all the drives, folders, and file-system noted in 2. above.
Applications or tool chain: In fact, we often use a mixed suite of applications from different software vendors, and complete tasks or sub-tasks through traversing these different applications, loading or saving our intermediate data files along the way. All native applications may access all the system drives in a uniform way, with typically standard file and data formats.
This ‘desktop’ paradigm for native applications works quite well indeed.
Now let’s take a look at the Web App paradigm, often associated with a client-server computing model, where the server does the heavy processing in a central location (on premises, or cloud remote), and one or more (or many) clients dial-in or connect to the server to request (and share) data, files, or specialized processing, through network transactions.
everal individual companies along the way, later banding together into internet or Web consortia, have established over the past few decades the highly efficient and scalable client-server (or internet) paradigm with notably different basic rules for Web apps:
Workspace: The user sees each single Web app isolated in its own web browser tab or separate browser window. Apps live (or execute) strictly within the browser, and are thus a ‘world apart’ from the client’s native OS desktop (can be completely different UI/UX).
Storage: Each Web app usually does not depend on the user’s local storage, or connected hardware resources — though some support file access, and send to printer. Intermediate application data, and even end results, are typically stored in the server’s storage. Some Web apps offer static import from / export to the client’s native OS storage through its standard File Requester dialog. But it is common for the Web apps to only support a sub-set of all of the file types available on the major native platforms. After all, users generally don’t intermix Web apps with native applications…
Application Launch: The user navigates to the url: of the desired Web app, either through an internal company home page or ‘launch screen’, or through the use of browser bookmarks, or by simply doing a Google search. The user often logs into the site or domain, and then abides by all the unique rules (and UI/UX) of that vendors’ environment. Unless the company IT department disallows it, the user may access or enter any of the (millions? of) web sites served from anywhere in the world. Note that none of these Web apps are ‘installed’ on the user’s machine. Rather, they are ‘out there’ in the cloud, and the user only interacts with them using their browser, through free access, or login credentials.
Applications or tool chain: Of course, multiple Web apps may be run at once on the user’s desktop, though each requires its own browser window, tab, or screen. In fact, some Web apps require or assume that they take over the user’s entire display. And each Web app may utilize the (Chrome) browser’s access to the user’s host OS (Windows, Mac, Linux), but this is typically limited to result downloads, or more commonly, to .pdf print documents or reports. Other than with some of the major enterprise cloud applications suite providers, such as Salesforce, SAP, or Oracle, individual Web apps are not typically provisioned to inter-work with each other, those from different developers or software vendors, or with native Windows applications.
This ‘Web app’ paradigm offers many powerful new, but different capabilities and opportunities, and yet we must follow different rules in where our programs are run, how they work with each other, and where our data is stored. In a sense, there exists practical barriers between desktop native applications run in a shared (Windows) workspace, and all the monolithic Web apps that we use essentially one-at-a-time, within a browser tab.
At least Two Problems — with One Friendly solution!
Computing in Transition
The first problem is that users are caught in a workspace of mixed paradigms — the Web app within the Browser, within the native desktop. Essentially, there’s a Chasm — legacy Windows native applications that many on the planet still use daily, and modern Web apps and Cloud suites, that are offering significant new benefits. But companies and users must endure the transition years. This creates a one or the other scenario, or as is often the case at many companies, users are caught in the middle, and must contend with the barriers, and cut-and-pasting, and work-arounds, when the company uses some tools from each paradigm for different functions, or between different work teams. And for companies that want to fully cloudify, they find that it can be a long and painful, and tricky process, like changing a tire while speeding down the highway.
Developer Ecosystem
The second problem, or perhaps missing opportunity, is the lack of a desktop ecosystem for Web apps. A mix-and-match tools & applications central economy for Web apps (with multiple competing, and interchangeable offerings), simply does not exist as it has for the Windows, Mac, and Linux native software platforms. Independent web developers can provide point solutions as stand-alone web-sites, but they are often unable to ‘leverage’ their offerings with those from other developers into a common ecosystem or shared desktop paradigm, like Cloud suite giants such as Salesforce or Google can.
Provide a Unifying Desktop Paradigm for Web apps and Native applications
FriendUP aims to bring legacy desktop native applications together with the modern Web apps, in a seamless and effective combination of the best of both worlds. For some users, it will involve bringing new or useful capabilities from one paradigm to the other, for others, FriendUP will reduce the limitations and pain of using the two paradigms and rules side-by-side, no longer having to jump through hoops and endure frustrating work-arounds. While still others will come to realize the significant benefits and remarkable new capabilities of removing the barriers between the two. For developers, it will present many new opportunities to easily cloudify legacy native applications, as well as provide facilities for a modern ecosystem of inter-working with both native and other Web apps.
Dormant
Friend delivers this central unifying capability through an underlying core functionality called ‘Dormant’. In a future article, we will explain the lower level details of how this works, and how simple it is for developers to take advantage of its many capabilities.
And of course many of the same points apply to mobile platforms such as Android and iOS, and new user experiences such as AR and VR.
Dormant provides for unified static or dynamic data exchange among and between Web apps, and between native applications and Web apps. And notably, this also enables the Friend Network with expansive parallel and consumer cluster computing capabilities. Stay tuned!