Drupalcon Dublin - Day 2 - morning sessions
Improving the Responsive Web Design Process in 2016
This was a beginner level talk, rapidly reviewing various aspects of responsive web design, more from the technical considerations than the visual design front. It did include a number of useful tips, including:
- Consider font size based on distance to target device to user’s eyes.
- Use an average of 40 - 80 characters per line to aid readability
- Use system fonts where possible (for speed)
- Use fewer fonts where possible (for speed)
- Use modern formats (WOFF2 / WOFF) to reduce page size
- For images, make use of picture cropping and optimisation for different orientations and screen size
- SVGs wherever possible (but not for photos)
- Consider testing on proxy based browsers (250 million users)
- Consider compression at proxy
- Test sites without JS.
- Test on opera mini.
- Beyond the mouse:
- Touch targets should be large enough:
- 57px x 45px for fingers.
- 72px x 45px for thumbs.
- Test with just the keyboard.
- Touch targets should be large enough:
- Responsive web design patterns:
- It is good practice to follow patterns for common user interactions such as navigation and forms.
My key takeaways
- Add touch target size tests to pre-launch checklist
- Take a look at Opera Mini
The core conversations track includes a number of sessions intended to update the community on the state of play with initiatives within Drupal core, and opening up for a two way conversation on issues and direction. Tim Millwood provided an update on the Drupal 8 Workflow Initiative and invited us to discuss.
The big news is that the content moderation module is included as an experimental module in Drupal 8.2. This is largely a rename of the Workbench Moderation module from Drupal 7, and provides additional workflow states for content, other than just published and unpublished, laying the foundations for complex content workflows.
There are already a number of modules is contrib that make use of content moderation to provide additional functionality. Tim provided a quick rundown of these.
This allows all content entities on a site to be revisionable. Most of the other extensions have multiversion as a dependency.
Using trash 8.x-2.x-dev you can move entities to the trash, then potentially undelete them later, or empty the trash to permanently delete.
Workspaces module allows the concept of a revisionable site-wide workspace, to stage changes in content and configuration before deploying to the published state. This is pretty cool, and as I understand can allow for changes in configuration and content to be tested fully before publishing all at once. There is a demo of workspace in a recent blog from Dries.
Tim posed the question “Should we try to add workspaces to core before the revisioning is added?”, highlighting the difficulty of interdependent functionality when moving contrib to core.
I was always taught that conflicts are best avoided, but a little conflict resolution can come in handy, and in my experience is often best with the help of a facilitator. This module sounds like it can be that facilitator. When two revisions can be generated from the same parent content item, they can diverge. If these two revisions both wish to be published, how can we assess the conflicts and merge the changes? When working with code, git usaully deals with this very well, and this module apparently follows a similar path, potentially allowing a three way merge between two conflicting edits and their common parent. Far out!
Favourite quote from the audience:
“Workspaces are… like… a whole new dimension of problems!”
My key takeaways
- Content managers will LOVE the trash module.
- Complex wrokflows have a bright future in Drupal 8.
- Much respect to Tim Millwood, Dick Olsson and the whole workspace initiative team.
See the sesesion: https://events.drupal.org/dublin2016/sessions/workflow-initiative
Drupal and the Physical World
This talk focused on linking Drupal with data coming from the physical world, and using that to provide an enhanced learning experience for trainee surgeons. Keyhole surgery is a tough job, and surgeions need to be dextrous and accurate. There are a number of challenges when providing training in such techniques, and testing and tracking progress. In this example trainees would use a camera and a probe, both on the end of long wands, one in each hand. They put these into a small box to try to hit specific target LEDs, with a screen being the only visual information to guide the surgeon. The leds and sensors are all connected to an arduino which feeds the data via usb to a laptop, via a chrome extension, and back to Drupal. I believe the video feed is also captured.
The Drupal site in question was an extended version of Opigno, a learning management system provided as a distribution. This was the first time I’d heard of Opigno, so I was interested to see it in action and hear how the team had extended the system relatively easily.
Here’s how it works:
- Student starts the assessment:
- Google Chrome app retrieves assessment parameterss via Drupal’s restapi.
- Student runs through assessment hitting targetLEDs.
- Student completes assessment:
- Video footage saved over webrtc.
- This uses Kurento media server.
- results saved in the Drupal LMS
Other tools? Why use Drupal for the LMS?
The client had tried other tools including Moodle, but it wasn’t flexible enough, wouldn’t scale, hard to extend to interact with physical hardware.
My Key takeaways
- Drupal’s REST API allows us to communicate with data from the physical world.
- Not too hard to write a small Chrome or Firefox entension to integrate Drupal REST API with USB data from Arduino or similar devices.
- Opigno is an interesting Drupal distribution that may be of use to clients in the education sector.