DrupalCon Vienna 2017: Back to the Future: No More Static Mockups!
The foundation of the web is HTML, CSS, and JS. Let's get back to where we started.
Stop me if this sounds familiar: your client signs off on designs created in Photoshop/Sketch (or some other image generation-tool). You build a website for them based on these designs. It looks quite like the designs, but not exactly like them. It's not your fault. It's not the client's fault. But wouldn't it be nice if you could build exactly what the client signed off?
In this session I'll look at lambasting my most hated design tool - Photoshop. In short:
it's for editing photographs, not designing websites
it builds up expectations for clients
it’s a static representation of a dynamic object at one specific breakpoint
It cannot cater for responsive design in any meaningful manner
So far, I've found that coupled with InVision it makes for a guaranteed frontend nightmare!
I'll then talk a little about something more modern - SketchApp. Though built especially for designing user interfaces, it still falls waaaay short when you want to give your clients designs that they can touch and feel and smell and see exactly what they are going to get. I do happen to really like SketchApp, but only for ... (come and hear why!). While we are at it, we will also have a look at mirr.io and see how it paired with Sketch fails just like photoshop paired with InVision.
Following, I'll talk about "Design for the Browser" and/or "Design in the Browser". Basically, using modern tools (such as PatternLab/Fractal) and Component-based design principles to give your clients an interactive prototype of exactly what their final product will look like. Not an approximation of it, the thing itself - so the product they get is the product they sign off on. Or failing PatternLab, why not use the simplest tool - a code editor - to create your designs. Write HTML, CSS, JS - send your client a URL and then, BOOM! - give them what they want. Clients can test this design on phones, tablets, watches - heck, even computers! - and make sure it works before they get you to implement it. When your client signs off the design, they are signing off the whole frontend (in our case the Drupal theme itself).
Slides presented will give an outline of my approach to integrating Drupal with PatternLab. We'll look at the fundamentals of creating a real world region (header), node template (article), paragraph bundle (card layout), and list (views list of teasers).
Why will you be excited to hear about this? Well, after you put the process I outline in place, you will be one step closer to completing work on time and on-budget; your clients will be happier; your developers will be happier; you'll buy me a beer!
This presentation, an easy-going rant about how to make things better for frontend developers, will be a part conceptual, part practical, and part confessional (yes, I'll show you some of the crazy things I've been asked to implement, based on how this is possible with photoshop but impossible with code - and clients not knowing the difference). There is no prior knowledge required to understand the concepts and implications of this session. To implement what is proposed you will need just a rudimentary understanding of Drupal theming: basically, if you understand the different templates that make up a Drupal theme (page.html.twig, node.html.twig, etc), consider yourself qualified to take it to the next level.
No compromises. No surprises. We're going back to the future!
This session will be an expanded version of my similar talks at Frontend United (Athens) 2017 and DrupalCamp London 2017
Stop me if this sounds familiar: your client signs off on designs created in Photoshop/Sketch (or some other image generation-tool). You build a website for them based on these designs. It looks quite like the designs, but not exactly like them. It's not your fault. It's not the client's fault. But wouldn't it be nice if you could build exactly what the client signed off?
In this session I'll look at lambasting my most hated design tool - Photoshop. In short:
it's for editing photographs, not designing websites
it builds up expectations for clients
it’s a static representation of a dynamic object at one specific breakpoint
It cannot cater for responsive design in any meaningful manner
So far, I've found that coupled with InVision it makes for a guaranteed frontend nightmare!
I'll then talk a little about something more modern - SketchApp. Though built especially for designing user interfaces, it still falls waaaay short when you want to give your clients designs that they can touch and feel and smell and see exactly what they are going to get. I do happen to really like SketchApp, but only for ... (come and hear why!). While we are at it, we will also have a look at mirr.io and see how it paired with Sketch fails just like photoshop paired with InVision.
Following, I'll talk about "Design for the Browser" and/or "Design in the Browser". Basically, using modern tools (such as PatternLab/Fractal) and Component-based design principles to give your clients an interactive prototype of exactly what their final product will look like. Not an approximation of it, the thing itself - so the product they get is the product they sign off on. Or failing PatternLab, why not use the simplest tool - a code editor - to create your designs. Write HTML, CSS, JS - send your client a URL and then, BOOM! - give them what they want. Clients can test this design on phones, tablets, watches - heck, even computers! - and make sure it works before they get you to implement it. When your client signs off the design, they are signing off the whole frontend (in our case the Drupal theme itself).
Slides presented will give an outline of my approach to integrating Drupal with PatternLab. We'll look at the fundamentals of creating a real world region (header), node template (article), paragraph bundle (card layout), and list (views list of teasers).
Why will you be excited to hear about this? Well, after you put the process I outline in place, you will be one step closer to completing work on time and on-budget; your clients will be happier; your developers will be happier; you'll buy me a beer!
This presentation, an easy-going rant about how to make things better for frontend developers, will be a part conceptual, part practical, and part confessional (yes, I'll show you some of the crazy things I've been asked to implement, based on how this is possible with photoshop but impossible with code - and clients not knowing the difference). There is no prior knowledge required to understand the concepts and implications of this session. To implement what is proposed you will need just a rudimentary understanding of Drupal theming: basically, if you understand the different templates that make up a Drupal theme (page.html.twig, node.html.twig, etc), consider yourself qualified to take it to the next level.
No compromises. No surprises. We're going back to the future!
This session will be an expanded version of my similar talks at Frontend United (Athens) 2017 and DrupalCamp London 2017