The ownCloud user interface has come a long way during the past 6 years in terms of the user experience as well as the used technologies. Also very basic engineering considerations led us to the decision to walk a new path and move ownCloud to the next level: ownCloud Phoenix.
New frontend concept
It all started as a prototype written by Felix Heidecke to play with some new ideas for the ownCloud web UI.
The Phoenix Frontend Project is a clean start to tackle a couple of difficulties that are regularly encountered in frontend development. Namely, an easy way to write HTML-templates, separate them from the data model and create a clean and understandable structure to write code.
We embrace UIKit. We achieve modular UI components and an atomic design pattern. This pattern is easy to understand, even for non-coders. You will not have to write a single line of CSS to use it.
Finally, we want to create a better user experience. Using pre-defined behaviors and appearances in UIKit, as well as the consultancy and review from ownCloud UX-Designers.
Technology Foundation
It’s time to leave all the ownCloud front end jungle behind. Over the past years, we integrated a great variety of JavaScript libraries, components, and frameworks into ownCloud. Phoenix will start on a green field, using latest front-end technologies like WebPack, Vue.js, and UIKit.
Phoenix will exist in total separation from the ownCloud Core. The goal is to get a true web client which holds only HTML, JavaScript and CSS files.
Phoenix will communicate with the ownCloud Core only via our public APIs like WebDAV and the OCS Share APIs.
The foundation for the communication has been laid down back in 2017 during the Google Summer Of Code. Noveen Sachdeva implemented the js-owncloud-client library and the corresponding feature to allow cross-domain requests to the ownCloud Core. CORS allows any web page to access the ownCloud via its APIs.
Because there are some security considerations, users need to explicitly allow access from other domains.
From a deployment perspective, Phoenix can run in an isolated environment. You can host it on a web server on its own. You, of course, can also host it as an ownCloud application from within the same web server which is hosting the ownCloud backend as well.
The first deployment model targets bigger and clustered installations where operators of ownCloud like to have more control over resource utilization and network topology.
The second deployment model will follow the ease of use principle which ownCloud follows since its very first days. Phoenix will be installed and updated via the ownCloud Marketplace and will be operational right after installation.
Impact on the overall ecosystem and code base
As a strong requirement to Phoenix , we have to keep the apps concept. Any developer has the capability to implement an app on their own which extends and enhances the Phoenix frontend. As we can foresee currently any front-end app written for Phoenix will not be allowed to ship any server-side code.
In case front-end and back-end features need to be implemented to fulfill the needs of a developer, he will implement two isolated apps. One holding the frontend part and one holding the backend, providing additional APIs to be used by the front end.
This clear separation will require changes to almost all apps which live today in the ownCloud ecosystem. As of today, all apps ship both parts in the same app. This is a breaking change in the ownCloud architecture but we are willing to take that.
Given this requirement, anything related to themes and white labeling needs to be moved as well. Today it is the backend which performs all necessary mechanisms to load alternative templates and style sheets. But this is the clear responsibility of Phoenix to render the pages properly.
Thinking about the final goal: the ownCloud backend server will no longer hold any JavaScript or stylesheets but PHP code only.
This will push its stability much further. In conclusion, we will develop frontend and backend independently from each other. We actually live this development model quite successfully for years with the development of desktop client, Android and iOS apps.
How to get there
First of all we need to keep the current front end alive until Phoenix is stable enough. We always need to provide a fallback to the old frontend during the time of migration.
In the very first step we will focus on the files app and try to ship this as alternative user interface via the marketplace as a dedicated app as soon as possible. Release early, release often!
As you are reading this we are evaluating students for this year’s Google summer of code in close collaboration with CERN and AARNet to bootstrap this very first phase!
Right after that, we take care of the theme support. Just to make sure that we don’t miss any necessary foundation work in the beginning.
Last but not least: We will add the app plugin mechanism and will find first candidates.
This is Open Source!
Are you interested in building the next big thing for ownCloud together with skilled people from the ownCloud community?
Join us on ownCloud Talk – channel Phoenix to collaborate on ownCloud Phoenix!
