When we first announced the Spark authoring experience initiative for Drupal in May of last year, we chose Drupal 7 as our target in order to develop the features and get them in front of testers as quickly as possible. After DrupalCon Munich in August, the team shifted efforts towards Drupal 8 core instead, in order to more directly improve the experience of Drupal itself. Since then, we have successfully worked with the community to drive home a redesigned and mobile-friendly toolbar, support for draft revisions, in-place editing, numerous mobile improvements, and have WYSIWYG and unified in-place editing on the way.
This has kept the team pretty busy, however, and so the Drupal 7 version of Spark has not been receiving many updates in the meantime. Olivier Friesse (noisetteprod) of Radio France graciously offered to sponsor work to help things along. Thanks to this sponsorship, we were able to have Théodore Biadala (nod_) of Acquia's Professional Services team spend 3 weeks on getting the in-place editing feature production-ready for Drupal 7, including:
Working towards a stable release for Drupal 7 naturally identified bugs with the Drupal 8 implementation of inline editing, which are being tracked in this issue: https://drupal.org/node/1894454.
In short, the needs of Radio France have brought tremendous value for the entire community, in both Drupal 7 and Drupal 8. If you'd like to try out the work that we've done, download the 7.x-1.0-alpha7 release of Spark or Edit 7.x-1.0-alpha6!
Thanks once again, Olivier and Radio France, for your support! If other companies would like to sponsor further work on Spark, please let me know.
A major focus of usability efforts in Drupal core has been around making it easier to edit things on your site. In Drupal 7, we introduced the Contextual links and Overlay modules to make it simpler for content authors and site builders to jump directly to the parts of the administration that relate to the things they see directly on the page, such as blocks or menus. Drupal 8 has now upped the ante with the new in-place editing feature, which allows for direct modification of content on your site, within the context of the page it is displayed on.
The next logical step is to take in-place editing to the next level by unifying contextual editing paradigms: combining the concept of "edit mode" with the ability to contextually edit more than just fields on content, in order to allow for contextual editing of everything on the page, in a mobile-first way.
Specifically, we need to address the following challenges:
Here is a video showing what we'd like to propose for solving these problems in Drupal 8 core:
We've now performed several rounds of internal usability testing on this functionality, and it has tested really well so far, with a high emotional value: in general, people can't believe this is Drupal. :-) Check out the prototype yourself at https://projects.invisionapp.com/share/U2A4IAGX.
I'm very excited about these changes, and feel that if we can get this into Drupal 8 it could be game-changing. But what do you think? If you like it, we'd love help with implementation and reviews in the core issue at http://drupal.org/node/1882482.
In the summer, I announced that we would adopt Aloha Editor as part of Drupal 8. The primary reason was that Aloha was the only WYSIWYG editor that supported in-place ("true" WYSIWYG) editing; something we need to accomplish our vision for in-place editing. The Aloha Editor developers have been excellent in their attention to Drupal's needs. However, due to the nature of their editor being based around the concept of "true" WYSIWYG, we've run into some issues (which the Aloha Editor folks are actively working on) surrounding the user experience and accessibility of Aloha Editor when using it on the back-end.
Since that announcement, CKEditor has caught up, and now offers feature parity to Aloha Editor when it comes to our needs. Frederico Knabben, creator of CKEditor, has reached out to offer whatever support he can to make CKEditor and Drupal work together better. They already prototyped a convincing alternative to Aloha Editor's killer "Blocks" system (which is an excellent match for Drupal's need to manage content within text content in a structured manner). In addition to that, we found that CKEditor is more mature in terms of APIs, documentation, and ecosystem around the project. Hence, after days of research and weeks of further discussion, the consensus is that CKEditor is now our best choice.
Therefore, we are going to switch from Aloha to CKEditor for Drupal 8 core. By making this switch, we will not only have a more mature WYSIWYG editor, but we also free up resources to work on other parts of Drupal's authoring experience. The CKEditor team has committed to fix the 8 functional gaps that we've identified in their two next upcoming releases.
Last-minute decisions like this are never easy. But we make them in order to do what is best for Drupal. I'd like to thank both the Aloha Editor team and the CKEditor team for helping us evaluate both editors and working with the Drupal community on closing functional gaps. But don't take your eyes off Aloha Editor; it's an editor that continues to hold a lot of promise for the future of the web.
The Spark distribution is a Drupal 7 distribution which aims to prototype cutting-edge authoring experience improvements that we hope to propose for inclusion in Drupal 8 core. Since we announced Spark back in May, we've shown videos of prototypes of inline editing, responsive layout building and mobile administration. The rest of the Spark team (Angela Byron, Kevin O'Leary, Wim Leers, Gábor Hojtsy, Jesse Beach, Preston So and Dharmesh Mistry) has also been working hard to make these designs a reality.
There has been a lot of great progress over the past months, and with the release of Spark 7.x-1.0-alpha4, Spark is now ready for some community testing! Each module/theme that Spark builds upon is a separate, standalone contributed project that can be integrated into existing sites. This alpha release includes:
If you'd like to try the distribution out without downloading and installing it, check our demo site at http://demo.sparkdrupal.com. (Note that since this site is open to anyone, it might look a bit funny at any given time. If things are really broken, please check back later.)
There is still much to do, but hopefully this release will provide a good understanding of the direction Spark is taking, and what we hope to propose for inclusion in Drupal 8 core. We greatly welcome feedback, bug reports and patches in the Spark issue queue.
At DrupalCon Munich next week, we'd love to talk more about how we can move some of these things into Drupal 8 core. We've setup various Spark sessions and BoFs at DrupalCon Munich to plan and brainstorm about this.
After a lot of discussion and testing, we decided to adopt the Aloha Editor as the WYSIWYG editor for Spark, and possibly for Drupal 8 core. Check out Wim's blog for the details. In short, it is the best HTML5 based WYSIWYG editor; fast, well-written and future-proof.
Here is a screenshot of our latest designs of how we envision integrating the Aloha Editor in Spark on a mobile device:
I also wanted to give a big thank you to Haymo Meran, creator of Aloha Editor and Director of Product Experience at Gentics Software GmbH, both for hosting a Drupal/Aloha collaboration sprint at his company's offices in Vienna last month, and also for changing the license of Aloha Editor to GPLv2+ (from AGPLv3) so that it could be used with Drupal!
It's an incredible gift to the Drupal project and the Open Source community at large. Thanks!
Today, I'd like to share an HTML/JS prototype we've created for a mobile toolbar and dashboard for Drupal that we hope to include as part of the Spark distribution and then propose for Drupal 8 core as part of the Drupal 8 Mobile Initiaitve.
Drupal 7's default administration tools (e.g. Toolbar module and Shortcut module) were not designed in a “mobile first" way, and as such can be difficult to work with on tablets or smartphones. For example, here is a screenshot of what happens to the Toolbar and Shortcut modules when using a responsive version of the Bartik theme on an iPhone:
We set out to do justice to the complexites of Drupal's administration layer while accounting for the constantly evolving universe of devices. We think what we've come up with is scalable, responsive, and usable.
Here is Preston So, author of the prototype, demonstrating the functionality in a short, 7 minute video:
As we begin work on this feature, it will live at the Mobile friendly navigation toolbar project as a contributed module for Drupal 7 first. If these changes are well-received, I hope we can target this functionality for Drupal 8 core, as a replacement for the Toolbar and Shortcut modules.
Today, I'd like to share designs we've created for a "responsive layout builder" for Drupal that we hope to include as part of the Spark distribution. I'm very excited about this because it brings mobile and responsive web design to the masses.
We've worked on this "responsive layout builder" concept for many weeks, and I believe the result is groundbreaking. While other layout building approaches hand-wave responsive design and produce messy markup, our approach promises to be simple to use, produce clean and semantic markup. At the same time educating the user on the logic of responsive design. Once implemented I think that this is something that could really push Drupal to the forefront of the competition.
What better than to show you what we have come up with? The following 8-minute video walks through the designs, and also provides a bit of background on the Spark project:
Special credit goes to Kevin O'Leary from Acquia for being the driving force behind this work.
Technically, this is intended to layer on top of the Panels module, for better forwards-compatibility with Drupal 8. We hope to integrate this work with the research and prototyping actively being done for the Drupal 8 Blocks and Layouts initiative.
Acquia is actively seeking implementation partners for this and other important work. If interested, please contact Angela Byron. We'd love to work with others on this.
You may remember that two weeks ago, I shared a video of an in-line editing prototype that we'd like to add to the Spark distribuion in addition to this responsive layout building tool. Its implementation is well underway in the Edit module.
As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if any of the above functionality sounds exciting to you and you'd like to help!
The goal of the Spark distribution is to incubate authoring experience improvements in a Drupal 7 and Drupal 8. It was announced earlier this month, and since then we've been hard at work on initial research and design.
The Spark team's primary focus is on improving Drupal's content authoring and editing experience, and the first feature we're prioritizing is in-place editing: the ability to edit content, menus, etc. directly on the page, without the need to navigate to a separate edit form. Think of it as "true" WYSIWYG.
Members of Acquia's design team spent time analyzing how some of the most widely adopted Open Source as well as proprietary CMSs do in-place editing. We then prototyped some initial ideas, and performed usability testing on those prototypes to see what works and what doesn't. After a number of iterations, we're happy to report that the usability testing has validated Spark's general design direction. People loved the prototype. Now is a good time for us to share our initial prototype and to solicit further feedback from the community so we can shift gears into implementation.
The following 5-minute video walks through the HTML/JS prototype, and also provides a bit of background on the Spark project:
Our goal is to deliver this functionality in a contributed module for Drupal 7 first and foremost, which will live at the In-Place Editing project on drupal.org. This module will be bundled into the Spark distribution. Depending on how it is received, I hope we can also target this functionality for Drupal 8 core.
From a technical architecture standpoint, we are currently in the process of selecting the WYSIWYG editor to use in Spark for in-place editing of HTML content. For now, we plan to focus on supporting only the Filtered/Full HTML text formats in order to get us to something testable faster.
Later, we are hoping to branch out into other areas of authoring experience too, including helping with the content creation form improvements that the Drupal usability team has been spear-heading, as are well as the layouts UI work being actively discussed in the usability group. The Drupal usability team is doing an incredible job with these issues, and once fully staffed, I would like to see the Spark team help implement these improvements for Drupal 8 and backport them to Drupal 7 so we can ship it with the Spark distribution. (Did I mention that the Spark team is hiring? ;-))
As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if this functionality sounds exciting to you and you'd like to help!
At DrupalCon Denver, I announced the need for a strong focus on Drupal's authoring experience in my State of Drupal presentation. During my core conversation later in the week, I announced the creation of a Drupal 7 distribution named "Spark" (formerly code-named "Phoenix"). The goal of Spark is to act as an incubator for Drupal 8 authoring experience improvements that can be tested in the field.
I hope for Spark to provide a "safe space" to prototype cutting-edge interface design and to build excellent content tools that are comparable with the experience of proprietary alternatives. While not a final list, some initial thinking around the features we want to experiment with is:
The vision behind the Spark distribution is to be "the Pressflow of Drupal authoring experience". Pressflow provided a "spoon" of Drupal 6 with various performance enhancements that made their way into Drupal 7 core while it was in development. The same improvements were made available to Drupal 6 users so they could easily be tested in the field. With Spark, we want to test authoring experience improvements in Drupal 7 on real sites with real users and real content. We also want to target the best improvements for inclusion into Drupal 8 core.
I'm excited to announce that Acquia will fund the Spark distribution. Core developers Gábor Hojtsy and Wim Leers will work on Spark full-time starting in late May. They will work along side Angie Byron (webhchick), Alex Bronstein (effulgentsia), myself and other members at Acquia. While we have some promising candidates so far, Acquia is still seeking two applicants to join the Spark team (with a strong preference to candidates located in or willing to move to the Boston area):
The Spark team will collaborate with the Drupal usability and the core development teams.
Updates from Dries straight to your mailbox