Taking the plunge: Why you should use new technology on client projects
- 1. Taking the plunge Why you should use new technology on client projects
- 2. @_tommyferry Hello! • WordPress Developer @ Pragmatic - WordPress agency Web Developer @ Sharpmonkeys - Digital marketing Lead Organiser WordCamp Brighton 2019: 16th-18th Aug.
- 3. @_tommyferry Who’s installed the classic editor plugin on their site(s)?
- 5. @_tommyferry Using new technology is scary!
- 6. What are new technologies? ...and why should we care about using them?
- 7. @_tommyferry ● New Frameworks and Libraries● New WordPress Features ○ Gutenberg Editor ○ Data API ○ REST API ● New Architectural Approaches ○ Headless/decoupled CMS ○ JAMstack (e.g. Gatsby.js) ● New User Experiences ○ Progressive Web Apps (PWA) ○ Accelerated Mobile Pages (AMP) New technology examples ○ React, Redux, and Next.js ○ Vue and Angular ○ GraphQL ● “New” Build Tools ○ Webpack, Gulp, and Grunt ○ Babel (ES6 transpiling) ○ NPM and Composer ○ Version Control
- 8. @_tommyferry ● New Frameworks and Libraries● New WordPress Features ○ Gutenberg Editor ○ Data API ○ REST API ● New Architectural Approaches ○ Headless/decoupled CMS ○ JAMstack (e.g. Gatsby.js) ● New User Experiences ○ Progressive Web Apps (PWA) ○ Accelerated Mobile Pages (AMP) New technology examples ○ React, Redux, and Next.js ○ Vue and Angular ○ GraphQL ● “New” Build Tools ○ Webpack, Gulp, and Grunt ○ Babel (ES6 transpiling) ○ NPM and Composer ○ Version Control New technologies can be overwhelming!
- 9. @_tommyferry ● Better developer experience ○ More flexible development ○ More efficient development ○ New features ● Better end user experience ○ Better front end performance ○ Better UI experience ○ New features The benefits of using a new technology It’s shiny and exciting!
- 10. @_tommyferry ● Better developer experience ○ More flexible development ○ More efficient development ○ New features ● Better end user experience ○ Better front end performance ○ Better UI experience ○ New features The benefits of using a new technology > It solves a problem < It can still be shiny and exciting!
- 11. What are the risks? (This is the scary bit...)
- 12. @_tommyferry ● We might not deliver what’s expected ● We might take too long to deliver ● We might not know the downsides ● We might find it hard to maintain ● We might fail! The risks of using a new technology > Expensive <
- 13. How do we minimise the risks? ...and make sure nothing blows up?
- 14. @_tommyferry ● Choose the right project and the right client ● Be transparent about the risks ○ Sell the benefits but be open and honest about the downsides ○ They might say no (and that’s okay)... but they might say YES ● Start small. One feature at a time, not a whole project! ● Give yourself more time. No, more than that... How to minimise the risks ● Prototype. No need to be perfect, just enough to know more ● Review often. Can we still do this? Is this right?
- 15. What might that look like? Time for a case study...
- 16. @_tommyferry The Project: Lindy Electronics An extensive site redevelopment ● Designs (existing brand guidelines) ● Site development ○ Multilingual site translations: German, French, and Italian ○ Content cloning between sites ○ Custom Vimeo integration ○ Content animation ● WP Multisite + Advanced Custom Fields + Starter Theme ● Bespoke templates with modular components
- 20. Some modular components (or “blocks”)Some modular components
- 22. The ACF “editor”
- 23. @_tommyferry The Problem ● Simple UI but not wysiwyg ● Wanted more flexible layouts ● Flexible at a component level ● Inflexible at the template level > Editing Experience <
- 24. @_tommyferry Benefits ● Does what they want ● Still a modular approach ● Industry & technology leading ● Allows us to try Gutenberg Risks ● An unknown new technology ● More work = more expensive ● Not 100% stable The Solution > Gutenberg <
- 25. @_tommyferry ● Added Gutenberg to one of their content types ● 12 custom blocks with multiple content fields ○ Able to reuse markup from existing components ● Created modular settings panels and reused across blocks ○ Theme color, fonts, alignment, etc ● Custom block categories ● Deactivated core blocks What we built
- 27. The old editing experience
- 28. The new editing experience
- 29. Where did we end up? The Gute, the Berg, and the Ugly
- 30. ● The client loves using it! ● Wysiwyg editor interface solves the problem ● Plenty of editor freedom… but not too much ● We’ve since enabled Gutenberg on other content The Gute “It's so easy to build the website…” photo by @jontyson on Unsplash
- 31. ● Core blocks were added with similar functionality ● No defined best practice so we had to dig deep into Gutenberg ● Some blocks weren’t used - we wasted effort The Berg photo by @charlesdeluvio on Unsplash
- 32. The Ugly ● The documentation was patchy in areas ● Refactoring custom blocks is hard and really slowed us down ● We should have worked with the core blocks photo by @ayahya09 on Unsplash
- 33. How did we benefit? What do we actually get after all this stress?
- 34. @_tommyferry Benefits For us ● Continued strong relationship with the client ● Successful project to use as a case study for pitches ● Starting point for future work with Gutenberg
- 35. @_tommyferry Benefits For me ● Better understanding of Gutenberg ● Improved JavaScript ● Starting point for React focussed learning ● Get to do presentations
- 36. We made it! What did we learn?
- 37. @_tommyferry Takeaways ● Make sure the technology solves the problem ● Get the client invested in the journey ● It’s okay to not know everything ● Learn what can be applied elsewhere ● Consolidate your new knowledge