Drupal provides numerous built-in user interactions. These include back-end admin configuration screens, but also end-user components. For authenticated users with admin permissions, that includes components such as the Toolbar, Contextual Links and Quick Edit. For all users, Drupal provides components like comments, search and user login forms.
As a server/PHP-based content management framework, Drupal relies a great deal on full page refreshes to provide additional options after a user interacts with a component. Full page refreshes can sometimes be avoided through the usage of Drupal's home-grown AJAX tools or through included third-party tools like jQuery or Backbone. Many of these tools still require a good deal of behind-the-scenes server interactions.
Meanwhile expectations for user interactions have increased, both due to the responsiveness of mobile native applications and JS-based single-page applications. Google details these expectations through a performance model called RAIL: https://developers.google.com/web/tools/chrome-devtools/profile/evaluate....
- Response: UI response received within 100ms of user interaction (16ms for touchdrag)
- Animation and scrolling: Render frames every 16ms (60 fps)
- Idle: Behind the scenes interactions with the server take place in batches of 50ms or less, to allow time for responding to user interactions
- Load: Full page loads take place in less than 1 second even on mobile connections (could be stretched up to 3 seconds)
There could be other metrics for performance. If power management (battery drain) and memory impacts were taken into consideration, this might be called PRIMAL for example.
Boosting key performance metrics would certainly help improve the experience of using Drupal, but more than that is probably necessary. Removing full page refreshes in order to show the results of a user interaction would also help. This is often called Optimistic UI: for a good explanation, see http://info.meteor.com/blog/optimistic-ui-with-meteor-latency-compensation.
We may be able to provide additional boosts to perceived performance and optimistic UI additions in the Drupal 8 cycle: some may need to wait until Drupal 9.
The goal of this META is to look at possible ways to meet the stated goals and evaluate the pros and cons of each. Ideally we reach some degree of shared consensus on ways to move forward.
Big Pipe (https://www.drupal.org/project/big_pipe) is one initiative underway that will help boost perceived load times. That may not have an impact on back-end administration screens unless cache tags are used for back-end components, which may or may not be useful.
Client-side JS frameworks are one way that many sites improve response time, particularly by storing large chunks of data in memory (often through JSON) that can be used to provide responses without the latency required for server roundtrips. The downside is often that client-side frameworks typically require a render-blocking download of the JS framework before the initial HTML for a page can be generated. This slows down the L in RAIL, particularly on mobile.
Client-side frameworks have tackled that challenge through the use of isomorphic JS: the initial page render is handled with server-side JS, typically with the use of Node. This helps to provide the best of both worlds.
Taking advantage of that solution with Drupal might prove very challenging, however. Pure usage of client-side frameworks could mean that content would only render when JS is active and functioning error-free. Drupal has typically excelled at progressive enhancement and accessibility, and relying solely on client-side rendering might contradict those principles. Using server-side JS rendering could require a large overhaul of Drupal's theme system in order to work on Node. Rendering some components with server-side JS (using Node) and others with Drupal's typical server-side PHP may or may not be possible.
The JS framework landscape is also highly volatile right now. Because an overhaul of Drupal's theme system could be time consuming, any client side framework selected could lose momentum as new frameworks with new techniques emerge. We have seen that when new technique emerges, it is sometimes adopted by other frameworks. React improved response time with virtual DOM diffing and load time with isomorphic rendering, and now Ember and Angular in their latest versions are adopting their techniques. If a framework is used to improve Drupal's user experience, we may want to select one that is likely to stay up to date with emerging techniques while providing backwards compatibility and security updates if their update pace is faster than what Drupal can keep up with through our release schedule.
Newer PHP-based techniques that use long-running PHP daemons to provide faster server responses without full bootstraps could also be explored. That does not eliminate latency from server roundtrips, but might be useful to explore.
Whichever path is used to improve Drupal's user experience, improvements to Drupal's APIs will likely be required—particularly for administrative interfaces.
Key goals to keep in mind:
- Fast initial load time: user interaction improvements ideally still use progressive enhancement
- Fast responses to user interactions
- Minimize full page refreshes and server bootstraps
Other issues have explored including client-side frameworks in core () and moving all or part of Drupal's theme system to render with Node JS ( ). Those might be methods we end up exploring in order to meet our goals. The goal here is to take a step back and look more fundamentally at what are the user experience goals we want to achieve and what are the best ways to do so for the Drupal community.
Ideally we find options that excite the existing Drupal community about the direction we head and may even excite others outside the Drupal community about the front-end (and back-end) work being done to improve Drupal's user experience.
- Propose various ways user experience goals could be met
- Evaluate the pros and cons of each method
- Reach consensus on ways forward
User interface changes
Ideally this results in numerous user interface changes that simplify how users interact with Drupal.
API changes could range from improving Drupal's REST API for administrative interfaces to a complete rewrite of the theme system.
Data model changes
In theory Drupal's data model should not need to change.