Spark

26 September, 2013
Description

We had two CKEditor Q&A BoFs at DrupalCon Prague: one for site builders, one for developers. They both used the same presentation to get everybody up to speed, but we applied different nuances.

This was presented together with the CKEditor team.

Note: the slides including screenshots and screencasts are on GitHub at https://github.com/wimleers/talk-ckeditor-drupal8-qa, feel free to reuse them in your blogs & talks!

Demo

1. Why the Drupal 7 modules (CKEditor/WYSIWYG modules) sucked and the Text Editor/CKEditor modules in Drupal 8 rock 2. How to enable CKEditor for a text format. 3. How to configure CKEditor, and how that UI automatically updates your filter settings. 4. The things CKEditor can do out of the box (Advanced Content Filter, image uploading, image alignment and captioning, in-place editing, and so on). 5. How Advanced Content Filter prevents crappy HTML. 6. The things CKEditor can do with additional configuration (site-specific “styles” for content e.g. for callouts). 7. The things CKEditor can do if you install additional plugins. 8. How Drupal 8’s caption filter plus the corresponding CKEditor widget provide the end user with a great UX, yet with clean, non-blobby content in the database. 9. CKEditor plugin demos that show the range of things you can achieve with CKEditor.

Q&A

After that, we opened the floor to any and all questions you might have.

Were present to answer questions:

  • Wim Leers, who was the liaison between Drupal and CKEditor, and led the integration
  • Frederico Knabben, CKEditor founder/project lead, CKSource owner
  • Wiktor Walc, CKSource CTO, worked on CKEditor modules for ages
  • Piotrek KoszuliĹ„ski, CKEditor developer, developed the CKEditor Widgets system and worked on the Advanced Content Filter system and pasting support
  • Olek NowodziĹ„ski, CKEditor developer, worked on the Advanced Content Filter system, HiDPI (retina) support and many parts of CKEditor
Conference
DrupalCon Prague
Date
Location
Prague, Czech Republic
31 May, 2013

Drupal 8 will ship with big authoring experience improvements: WYSIWYG editing & in-place editing, thanks to the Spark distribution that Acquia — my employer — is sponsoring.

But how well does it fare with the growing importance of structured content? Do Drupal 8’s WYSIWYG & in-place editing enable it or prevent it?

The new web world order: many form factors

The Big Thing of the last few years: the advent of mobile. Inherent to that: websites that are optimized for mobile devices and act as data providers for apps.

A new form factor — mobile devices — changed web development forever. Before mobile, the life of web developers and authors (content creators) was relatively simple: make sure websites work well on a few typical screen sizes (let’s deny the existence of Internet Explorer 6 and all the misery it caused).

But … we cannot predict what’s next. We cannot predict new content consumption form factors. That’s where content strategy becomes vitally important:

content strategy is to copywriting as information architecture is to design

26 May, 2013
Description

At DrupalCon Portland, I presented together with fellow Acquia Spark team member Jesse Beach on the accessibility improvements that we helped bring to Drupal 8. See http://portland2013.drupal.org/node/2158.


Drupal 8 will be the most accessible version of Drupal yet. We are expanding the foundational HTML markup support into APIs that make it easy to express the state of the page components, not just their properties. One example is Drupal.announce, which passes strings to an ARIA-live region to be read by a speaking User Agent. Another is simple management of tab ordering for constrained page navigation by keyboard (Drupal.TabbingManager). And we intend that these APIs be utilized throughout Drupal core and contrib.

As front-end developers, we are well familiar with oft-touted techniques of visual presentation — layouts, grids and typography to name a few. In this session, we will make the case for the aural user interface. Our pages should be accessible just as well by sound as they are by sight. The aural UI cannot be an afterthought. It must be designed, iterated and tested like any other UI.

Drupal 8 will provide the tools to build amazing aural UIs. Find out how you can incorporate these techniques into your modules so that your work will be accessible to the widest possible audience.

Conference
DrupalCon Portland
Date
Location
Oregon Convention Center, Portland, OR
Duration
60 minutes
15 August, 2012

We had already let you know that we would be using Aloha Editor as the WYSIWYG editor in Spark. In short: it has a very complete feature set, a proven plug-in system, solid cross-browser support, it can do “nested editables”, and so on; but most notably it’s the best WYSIWYG editor out there that can do “true WYSIWYG”.

Sprint

To accelerate the integration of Aloha Editor into Spark’s Edit module, we decided to do a code sprint with the Aloha Editor developers. Acquia flew out Théodore “nod_” Biadala and Wim Leers to Vienna (Daniel “sun” Kudwien unfortunately wasn’t able to make it), to hack three days (July 16–18) in a row to get us as far as possible. Three of the Aloha Editor developers were working full-time with us.
We’d like to thank Aloha Editor’s parent company, Gentics, for their generous contribution and amazing hospitality.

The most notable goals were:

10 July, 2012

A few weeks ago, we showed the in-line editing prototype we had built for Spark, which has now blossomed into Edit module. Additionally, we also pointed out that we were in the process of selecting the WYSIWYG editor to use in Spark. This selection process was performed in the public Spark issue queue, in order to gather community feedback and to attempt to reach consensus. 73 people followed that issue, about two dozen of whom contributed to the discussion as well.

2 May, 2012

After working at Nascom for a very brief time, I will soon start working at Acquia! I’ll be working on the Spark project as a Senior Software Engineer in the Office of the CTO (OCTO), reporting directly to Dries!

Why I left Nascom

I chose Nascom because I felt it was the best fit for me. I really preferred working for a Belgian company. Nascom seemed to have it all1, but in the end, it was not a good match. I still stand by my choice of Nascom being the best possible choice I could have made, when limiting my choices to Belgian companies. They’re great. But the spark was missing for me.