Words coexist with power in a relation analogous to that which proletarians have with power. Employed by it almost full time, exploited for every sense and nonsense that can be squeezed out of them, they still remain in some sense fundamentally alien to it.
Drupal 8 ships with a significant overhaul of the content creation page (“node form” for intimi). It’s design process and subsequent implementation are extensively documented on drupal.org. This is a high level summary of how this redesign come to be.Steps in the process:
Who were working on this? In the earliest design stages primarily 3 people: Bojhan Somers, Jared Ponchot and moi, Roy Scholten. Many more helped with finetuning design elements, usability testing, writing and reviewing code and all the other little and not so little things that go into getting a big design change committed to Drupal core. Thanks all.Research & sketching
We didn’t spend much time building the case for a better content creation page. No problem because most were already aware of the big room for improvement.
The research was two-part: “what does Drupal do?” And “what are other systems doing?” For the Drupal aspects, we looked at how and where contributed modules add functionality to this screen. We reviewed other systems looking for patterns in how functionality was grouped and arranged on the page.
That input was then translated into very generic concept sketches, comparing and contrasting several arrangements of the three basic feature groups: content, settings and actions. From there, we proposed to pursue one specific direction in more detail. Before we did that, we opened up the work so far for feedback: http://groups.drupal.org/node/214898Design
Starting from that very rough initial layout we started exploring the details of that arrangement. Which items belong in which area and how would they behave? How would it work on small screens? Which items to call out, which ones to push back?
Then Jared Ponchot stepped in and pulled all that sketching together in high-definition mockups. And on these we iterated again a couple of times, detailing the arrangement of interface elements, the use of color and other ways to (de-)emphasise certain parts of the whole. A comparison with the then current state of the Seven admin theme identified how we would have to extend its visual language to accommodate this new design.
And that’s where we opened up for another round of feedback: http://groups.drupal.org/node/217434Test
A working prototype of the design proposal was coded and made available on a test site. A usability test plan was drafted and several people used that script to test the prototype with people both new to and experienced with Drupal. One of the few times we actively pushed for community driven usability testing actually. Results from the testing were reported in the implementation issue and individual issues were opened for the necessary changes.
Usability test plan: http://groups.drupal.org/node/223959Implementation
The prototype for testing was created in context of the implementation issue. We spent a lot of time translating the design proposal into actionable tasks.
The distinction between rough prototyping code and actual core worthy implementation was a bit unclear at first but we very quickly got to a usable demo. The overarching “meta” issue has over 300 comments. Which is usually a sign of a large undertaking that’s not sufficiently broken down in seperate actionable tasks. But, we got there in the end!
Implementation meta issue: https://drupal.org/node/1510532Lessons (not? :-) learned
- Good: working with a small team. It allowed us to focus on what needed to be done and move relatively fast.
- Good: Publicly documenting the research and sketching phases was a lot of work but worth it. Pulling a finalised glossy photoshop design out of the hat would not have created the same engagement and constructive feedback
- Good: counter to the previous point but also a good thing was that the initial sketches and design mockups were shared only within the very small team of 3 to 5 people. This kept momentum up but more importantly allowed us to focus on the actual design work. A broader discussion would very likely have shifted towards discussing implementation challenges, which is not what you’re after when still exploring multiple options.
- Not so good: we prototyped only one working version quite late in the process. Only after a lot of time invested did we get to see and feel a somewhat working version. This narrowed our bandwidth for subsequent changes, which were relatively small tweaks, keeping the basic paradigm intact. We never really pitted two or more radically different approaches against each other. This was mostly a time and energy issue: we only had the bandwidth to work through one design direction.
- Not so good: Doing the design phases outside of the issue queue (where implementation happens). This was a necessary but difficult trade off. The issue queue doesn’t lend itself to explorative work with lots of ambiguity so the design work wasn’t tracked there. Many core developers did not closely follow the process as it happened on groups.drupal.org, so when we brought the design over to the issue queue with the proposal to go build this, much of the earlier discussion points got brought up again.
- Not so good: Not having a primary code architect as part of the team. We could have prevented at least some of the rehash in the issue queue if we had had a knowledgeable core developer on the design team. Having somebody who could answer to the technical implications of the design and help break down the work into manageable tasks the would probably have gotten us off to a better start with implementation.
A quick tally of the number of comments across the main discussion threads and issues for this project: more than 1200. And that doesn’t even include huge additions like the WYSIWYG editor and the improved previews. Not to say that this doesn’t happen in other initiatives, but you can see how demanding it is for anyone who wants to keep track, especially if you want to make sure that the big picture doesn’t get lost in the myriad of details.How to get better, faster?
The amount of work will always be huge. I think the gains are in finding a better balance in:
- Feeling free to write quick throw-away code in the initial explorations so people can get a feel of what might work and we can test it.
- Reducing wasted efforts (in code and discussion) during implementation.
Understanding the distinction between these two, and being clear about when the first ends and the second begins will already be a big step forward.
Further discussion: Determine process for big UX changesTags: drupaluxauthor uxdrupalplanetSub title: Drupal 8 has a redesigned content creation page. This is how it came to be.
We are working tirelessly to make Drop Guard better, faster and more friendly for developer. In this blog post we present you a "sneak peek" of our revamped project creation process, with this end in mind to please you with greater usability for getting started with your project in Drop Guard!
So let's get more detailed: the creation process will be split into 3 independent configuration screens.
1. On the first screen you will be able to quickly connect Drop Guard to your repository and enjoy it's updates monitoring capabilities - even without installing a Drop Guard module.
2. Second screen will be for those who immediately want to integrate Drop Guard in their daily maintenance routine. It's about telling Drop Guard what to do when the update of a certain type is detected.
3. Third screen will be all about events - sending e-mails, running SSH commands, pinging your favourite CI tool or merging branches based on certain conditions.
So below we share the preview of the new "Updates setup" wizard. As opposed to the "accordion-like" endless form, we now have the sleek step-by-step configurator, which allows you to quickly instruct Drop Guard what to do when updates are detected (embracing best update practices and being able to set a single configuration for different types of updates).This is a screenshot of the update types configuration in the old project creation process:
And here you can enjoy the sneak peek of the new process:
If you're a Drop Guard user or just curious - don't hesitate and leave your feedback on it. We'd love to optimize Drop Guard for every workflow and we can't do it without your voice! You prefer a personal contact? Find our data here: About Drupal Drupal Planet Project Process
Our Drupal development experts compiled their best advice for running effective automated tests that will save time and money. Complex development projects are likely to have many releases and have much to gain from implementing an automated test framework. Read this guide for advice on how your team should approach writing test cases, choosing the right tools to execute tests, and how to emphasize visibility in sharing the test results.
Jeff Geerling's Blog: Set up a hierarchical taxonomy term Facet using Facet API with Search API Solr
I wanted to document this here just because it took me a little while to get all the bits working just right so I could have a hierarchical taxonomy display inside a Facet API search facet, rather than a flat display of only the taxonomy terms directly related to the nodes in the current search.
Basically, I had a search facet on a search page that allowed users to filter search results by a taxonomy term, and I wanted it to show the taxonomy's hierarchy:
To do this, you need to do two main things:
- Make sure your taxonomy field is being indexed with taxonomy hierarchy data intact.
- Set up the Facet API facet for this taxonomy term so it will display the full hierarchy.
Let's first start by making sure the taxonomy information is being indexed (refer to the image below):
TexasCamp is two days of DrupalCamp, intended for Drupal admins and users, sitebuilders, themers and developers. Expect sessions from beginner to expert level, with the brightest minds in the Drupal world attending and presenting.
You can attend TexasCamp for only ...Read more
Each day, more Drupal 7 modules are being migrated over to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules available for Drupal 8. This week: Admin Toolbar.Tags: acquia drupal planetadmin toolbardrupal 8Drupal modules
Drush is a command line interface that help us to speed up administrative and development tasks for Drupal sites. After installing this Drush, we’ll be able to perform useful action simply by typing command into a terminal —actions that would usually take multiple steps in a web browser. Drush runs on Drupal 6, 7 well as 8.
Note: Drupal 8, works only with Drush 8.
Couple of task which can be be done using Drush easily are :
Download contrib modules
Update Drupal and contrib module versions
Clear the cache
Run Drupal with a lightweight web server
Import, export and merge configuration
In previous blog post we have installed Drupal 8 on our system manually as well as using Drush. Drupal 8 Provides two built in content type Article and Basic page. We can use this to create pages. But most of time we need to either add fields to these content types or we just need to add new content type to organize the content better.
Probably the first change site builders will notice in Drupal 8 are the changes to content types and fields. The field changes affect not only content types, but any entity that can have fields e.g. taxonomy or user profile.
When we edit any content type,…
The Stanford Drupal Camp is a two-day event to discuss and learn about Drupal, an open-source content management system that powers thousands of websites at Stanford, and millions of websites beyond.
This year, the Stanford Drupal Camp emphasizes introductory sessions focused on content strategy as well as thought-provoking sessions for researchers in academia. Those new to Drupal and Content Strategy will be particularly interested in the events on Friday, whereas experienced Drupallers (yes, we spell it with two "L"s at Stanford) may be more interested in Saturday's program.
I am planning to propose a session for DrupalCon New Orleans about Drupal 8 development and Drupal Console and currently looking for session name ideas.
Session abstract text:
Drupal is infamous for his learning curve of drupalisms but Drupal 8 simplifies and standardize the development process, unfortunately this comes with a cost. Drupal 8 is more technically advanced compared to its predecessor and managing the increasing complexity of Drupal 8 could be a daunting task.
The Drupal Console is a CLI tool that helps you manage that complexity allowing you to generate boilerplate code, interact and debug Drupal 8.
The Drupal Console has been designed to increase productivity making Drupal development and interaction efficient and enjoyable.
Come along as we explore this tool that will help you developing by taking advantage of the modern PHP practices introduced into Drupal 8.jmolivas Thu, 02/04/2016 - 00:07
Some of our very own DrupalCon Asia organizers are members of the Drupal Association. We spoke to them about why membership is so important to them, and their answers were so great we had to share. Continuing from a previous blog post, we'd like to invite you to read why they support the community and the Drupal project with us.
Drupal 8.0.3 and Drupal 7.42, maintenance releases with numerous bug fixes (no security fixes), are now available for download.Download Drupal 8.0.3
Download Drupal 7.42
Upgrading your existing Drupal 8 and 7 sites is recommended. There are no major nor non-backwards-compatible features in these releases. For more information about the Drupal 8.x release series, consult the Drupal 8 overview. More information on the Drupal 7.x release series can be found in the Drupal 7.0 release announcement.Security information
We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.
Drupal 8 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.
There are no security fixes in these releases of Drupal core.Bug reports
Drupal 8.0.x and 7.x actively maintained, so more maintenance releases will be made available, according to our monthly release cycle.Change log
Drupal 8.0.3 contains bug fixes and documentation and testing improvements only. The full list of changes between the last 8.0.x patch release and the 8.0.3 release can be found by reading the 8.0.3 release notes. A complete list of all changes in the stable 8.0.x branch can be found in the git commit log.
Drupal 7.42 contains bug fixes and minor new features. The full list of changes between the last 7.x patch release and the 7.42 release can be found by reading the 7.42 release notes. A complete list of all changes in the stable 7.x branch can be found in the git commit log.Update notes Planet DrupalDrupal version: Drupal 7.xDrupal 8.x
Nobody wants a website that can be hacked. Drupal has a great security track record and works hard to ensure that core and contributed modules are safe for everyone to use. One of the most common types of security issue is a cross-site scripting attack (XSS). In Drupal 8 we've made extensive changes to the theme system that reduce XSS vulnerabilities.
This past weekend, our thriving Vancouver community came together and worked on getting a variety of Drupal contrib projects ready for Drupal 8. This weekend allowed us to put on the finishing touches needed to get a stable 8.x-1.0 release out to the community! Let's have a look at what's new about this release of Basic, as well as some upcoming features.
While working on recent Drupal projects, I learned that Internet 10 and 11 (IE10-11) no longer support IE conditional comments. Conditional comments allow us to target specific versions or version ranges of IE to correct bugs or inconsitentices that normally are not present on other browsers. Typically for IE9 and below, we have been able to write conditional css by using something like this:
We've removed the Composer-managed vendor from the git repository.
There will not be any changes for people downloading Drupal 8 from drupal.org. The Drupal.org packager will add dependencies to zip and tar package.
If you're not using zip / tar files, e.g. when using a git clone, run composer install to get dependencies. See https://www.drupal.org/documentation/install/download#git for instructions.
Manage external css & jss through Drupal admin UI & Contexts. Files support multiple versions based on prod/stage/dev environments for easier development on production instances.
This module was developed by Interscope Records and designed with Acquia Sitefactory in mind to accommodate building sites in a multisite environment off a shared codebase without the need to push out updates for theme-level updates.