An Agile Front End Workflow
Eric Smith
@ericgsmith
Welcome etc. FED story.
How many people are excited about the agile part?
How many people are excited about the front end part?
Intro... I'm a developer and I get excited about solutions...
What I'll be showing you in the next 40 minutes is our new way of working
Talking about process, technology, etc.
Project Timeline
Explain sprint 0, typical project lifetime.
Explain what typical scaling up is.
Ticket Workflow
Talk through peer review, qa, done.
The old way
The way things have always been done.
Give examples eg a view (simple), search results (complex)
Talk about arrow = gap.
The Process Problem
- Development is a bottleneck
- Theming at the end creates pressure
Themer twiddles thumbs at start of the project.
This creates a gap - this increases over the life of the project.
Themer goes insane at the end of the project.
The Historical Problems
- Drupal - A million ways to die
- CSS is a one man game
- Hell is other people's CSS
- Adding things to the end of stylesheet
- Time taken to deliver a page that looks the same
- Onboarding time for new developers
Historical problems we want to solve, not related to the old way.
Preprocess functions, theme functions, templates, ctools style plugins, display suite, etc..
CSS is a one man game is a myth
Ask devs if they have ever done this
Interact with PMs re page the looks the same - views news / blog example
The Target
- A development team not an individual
- An efficient workflow
- Deliver amazing results and value each sprint
Link last point to the old way gap - this is just the opposite to the problems
Sprint 0
- Theme setup
- Drupal's CSS / markup
- CSS Methodology / Architecture
- Documentation
- Automation
- Assets
- Testing
- Definition of done
- Team structure
Explain the checklist.
Explain the PM's role / awareness for devs.
Clarify it's making decisions not always developing.
CSS Foundations
Talk about responsibilities of the leaders.
Interact with crowd, get people to stand up if they are front end
devs, sit down if they don't use a preprocessor.
Mention references at end of talk, briefly cover smaccs.
SMACCS - this is the bit where we build something and
tell drupal about it.
Talk about pattern libraries / components.
Talks about folder structure scaffold
Coding standards
Drupal has CSS coding standards
The rest of the web has coding standards
There are tools to help you enforce coding standards
Most people know the php coding standards
Things like line length, spacing, naming conventions.
It is there for consistency - most historical problems are there
due to inconsistency or bad css.
Learn from sass coding standards. Again, we are building
something and telling drupal about it - so learn from
the other 98%
Will my team mates understand this?
Project readme is essential.
All setup info, e.g bundler / npm need to be explicit.
Don't assume everybody will know.
Don't be afraid to point out the obvious. E.g. I can't
remember how to compile less files?
Documenting CSS
PHP Tell the why, not what.
CSS Tell the what / when / how / why / where and why.
Story about generating html from css.
Hologram syntax
/*doc
---
title: Alert
name: alert
category: basics
---
I am a comment
```html_example
<div class="alert">I am the example code</div>
```
*/
Explain parent / category relationship.
Explain how to set up and what you will show next.
PatternLab
talk about how we've used it.
plug github repo
talk about how it might impact d8
Benefits
- Visibility within the dev team
- Visibility for the client
- You can test the style guide
- You can theme without Drupal
Give team benefit example.
Give estimation / double checking with client example re forms
Regression testing / responsive testing
Briefly mention Gary / bringing in a front end dev. Explain
that is a possibility, not what happened.
Doubts
- Duplication of markup
- A solution for any project size?
- Yet another tool to learn
Sprint 1 onwards...
We can start themeing / building css without drupal markup
What we did wrong
3 User stories
- Theme: no dependency
- Functionality: no dependency
- Integrate: dependent on both
Talk about ticket structure / child tasks
Give examples of different stages of the project
(e.g kickoff through to ecommerce)
What we did right
1 User story - up to 3 sub tasks
- Theme
- Functionality
- Integrate
Talk about how PO can perceive this
The new way
The gap is smaller, it should never go over one sprint.
Theme tickets
- Look to the style guide for existing styles
- Estimate new components / prototype
Bring up previous story - this is agile, client might be happy
to reuse than to create extra work.
Talk about whose job it is to estimate components
Prototyping inside Drupal
- Not tied to functionality
- Designer can sign off mid sprint
- HTML / CSS is integrated once signed off (and functionality is developed)
Prototyping does not mean throwing your work away or duplicate effort.
Same CSS is used as its within the website.
Give example of building something quickly in the first sprint.
Simple module that is essentially a serious of page callbacks, templates and a theme function.
Not tied to functionality: unblocks the themer and reinforces good practise to not rely on build classes
Interactive / responsive elements clarified in browser during the sprint
/**
* Implements hook_menu().
*/
function sage_statics_menu() {
$items = array();
$items['statics/%'] = array(
'page callback' => 'sage_statics_page',
'page arguments' => array(1),
'access arguments' => array('access content'),
);
return $items;
}
/**
* Page callback: Statics pages
*/
function sage_statics_page($page) {
switch ($page) {
case SageStatics::PAGE_BOOK_PRODUCT:
return theme(SageStatics::THEME_BOOK_PRODUCT);
// etc...
}
}
Development tickets
(Mostly) Unchanged
Explain communication with themer, possibly picking
out classes if it is simple enough.
Make sure all data is available for the front end.
Integration tickets
- Available when theme and dev work is complete
- Can be shared amongst the team
Typically just merging the markup from the statics into the actual theme.
AbstractThemeProcessor
abstract class AbstractThemeProcessor {
/**
* @var array
*/
private $vars;
/**
* @param array $vars
*/
private function __construct(&$vars) {
$this->vars = &$vars;
if ($this->isApplicable()) {
$this->execute();
}
}
/**
* @param array $vars
* @return static
*/
public static function process(&$vars) {
return new static($vars);
}
/**
* @return mixed
*/
abstract public function execute();
/**
* @return bool
*/
abstract public function isApplicable();
}
Article Processor
class ArticleNodeProcessor extends AbstractNodeProcessor {
// Example variable.
const VAR_EXAMPLE = 'example';
const VAR_EXAMPLE_FROM_NODE = 'example_node';
/**
* {@inheritDoc}
*/
public function isApplicable() {
return $this->isNodeType(ArticleController::getClassEntityBundle());
}
/**
* {@inheritDoc}
*/
public function execute() {
$this->articleController = example_article_factory()->initWithEntity($this->getVar('node'));
$this->addExtraDisplayItems();
}
/**
* Add extra display items.
*/
public function addExtraDisplayItems() {
$this->setVar(self::VAR_EXAMPLE, 'Variable value');
$this->setVar(self::VAR_EXAMPLE_FROM_NODE, $this->articleController->getExampleValue());
}
}
/**
* Implements template_preprocess_node().
*/
function example_preprocess_node(&$vars) {
ArticleNodeProcessor::process($vars);
ArticleNodeTeaserProcessor::process($vars);ß
BlogNodeProcessor::process($vars);
CarouselItemNodeProcessor::process($vars);
}
Another Problem
"That hover colour isn't right"
"That slide transition is too slow"
Build up the story with example of complex backend development.
@todo: TEST!
Refactoring will happen often.
Questions?
- Mail: eric.smith@cameronandwilding.com
- Twitter: ericgsmith
An Agile Front End Workflow
Eric Smith
@ericgsmith
Welcome etc. FED story.
How many people are excited about the agile part?
How many people are excited about the front end part?
Intro... I'm a developer and I get excited about solutions...
What I'll be showing you in the next 40 minutes is our new way of working
Talking about process, technology, etc.