Slide 1
Slide 1 text
Get rid of that
front end
@hagenburger #rubyconftw
Slide 2
Slide 2 text
nico@hagenburger.net
email
twitter
blog
first name
last name
Slide 3
Slide 3 text
(I’m from Germany. The country producing China Oil for Taiwan.)
Slide 4
Slide 4 text
livingstyleguide.org
@LSGorg
Slide 5
Slide 5 text
Mentor
https://instagram.com/langziehohr/
https://instagram.com/p/5198hBm7hS/
Slide 6
Slide 6 text
Organizer/designer
https://instagram.com/asaaki/
https://instagram.com/p/54xnvhp9Hy/
Slide 7
Slide 7 text
(Ruby) back-end vs.
front-end developers
Slide 8
Slide 8 text
Back-end developer
★ Hard to hire
★ Used to work with:
★ Databases
★ Services
★ Ruby
Slide 9
Slide 9 text
Front-end developer
★ Even harder to hire
★ Today mostly JavaScript based:
★ Grunt/Gulp/Broccoli/Webpack/etc.
★ Might not like use Ruby
Slide 10
Slide 10 text
Working as a team
★ JavaScript/Node might be harder to install
than expected
★ Ruby might be harder to install than expected
★ Note to self: Not everybody is using a
MacBook
Slide 11
Slide 11 text
Do you want to
combine this?
Slide 12
Slide 12 text
Might cost time.
Slide 13
Slide 13 text
Better use the time
to separate concerns.
Slide 14
Slide 14 text
Split up your
architecture
Slide 15
Slide 15 text
A typical project
Slide 16
Slide 16 text
Why
Phone
Apps?
Slide 17
Slide 17 text
Why
Phone
Apps?
APP
APP
HTML
and
CSS
Slide 18
Slide 18 text
(The architecture might look like this:)
Slide 19
Slide 19 text
(Step 1: Get the CSS out of the applications by creating a global front-end style guide)
Slide 20
Slide 20 text
(This is what style guides contains)
Slide 22
Slide 22 text
A style guide is a
copy & paste API
Slide 23
Slide 23 text
(3 × copy & paste)
(actual Step 1: We created an additional version of the HTML templates and more complexity)
Slide 24
Slide 24 text
(Step 2: Get the HTML out of the applications and providing the templates as API)
Slide 25
Slide 25 text
HTML can’t live without CSS
CSS can’t live without HTML
CSS
HTML
Slide 26
Slide 26 text
(Example for a style guide describing an API partial. The style guide is just the API
documentation.)
Slide 27
Slide 27 text
Remote partials
Slide 28
Slide 28 text
How to implement?
Slide 29
Slide 29 text
Different approaches
★ Completely separate
★ Two applications combined
★ As Ruby Gem
★ Monolith application
Slide 30
Slide 30 text
Completely separate
+Back end (Rails)
+Front end (JS on developing machine)
−Slow change processes
★ API:
★ Provide templates (e. g. as JSON)
★ Load all templates into back end at startup
Slide 31
Slide 31 text
Two apps combined
+Run the application (e. g. Rails) normally
+Run the front-end app (e. g. Middleman)
+Changes can be done more easily
−Still does not solve different working
environments
#protip: Use Foreman
Slide 32
Slide 32 text
GEM
+Include it into every app
+Helpers can be shared
+Form builders are possible
−Ruby back end only
−Harder to develop (Git)
Slide 33
Slide 33 text
One app
+Nothing much to change
+Share partials between app and style guide
−Still does not solve different working
environments
Slide 34
Slide 34 text
Versioning
Slide 35
Slide 35 text
Visual changes
★ CSS changes in the style guide
★ HTML in the app must reflect this
Slide 36
Slide 36 text
Example
Old version: New version:
(Applying this wrapper to all fields in the application might be a lot of work)
Slide 37
Slide 37 text
Version numbers
★ Gem version
★ NPM version
Slide 38
Slide 38 text
Git commit hash
★ Just refer to latest commit hash
★ Get the matching HTML for the CSS
Slide 39
Slide 39 text
Testing
Slide 40
Slide 40 text
Atomic design
@brad_frost
Slide 41
Slide 41 text
Split it up
Front end templates
(partials)
Back end views
(e. g. Rails)
API
Slide 42
Slide 42 text
Test it
Unit tests
(regression testing)
Integration tests
(e. g. Cucumber)
API
Slide 43
Slide 43 text
Regression testing
Old version: New version:
(Button height fails: Pink parts show diff.)
Slide 44
Slide 44 text
Default test Edge case test
Test cases
Slide 45
Slide 45 text
What’s an edge case?
★ Having the same HTML with different amount
of text
★ Having the same HTML without image (user
with no profile image)
★ Having the same HTML with too small image
Slide 46
Slide 46 text
Front end
Takes care that the
★ design won’t break
★ content won’t break
★ devices won’t break
Back end
Takes care that the
★ work flows won’t break
★ user input won’t break
★ security won’t break
Slide 47
Slide 47 text
JavaScript
Slide 48
Slide 48 text
Depends on the
framework.
(Backbone, React, and Ember might work well, Anguler could be tricky.)
Slide 49
Slide 49 text
I18n
Slide 50
Slide 50 text
Might be part of the
front end.
Slide 51
Slide 51 text
Why?
★ Translations need typography
★ Typography requires designers
★ Designers work in the front-end team
Slide 52
Slide 52 text
100 % 50 % 0%
(a designer knows which spacing is right)
Slide 53
Slide 53 text
I18n is design
and user experience.
Slide 54
Slide 54 text
Conclusions
Slide 55
Slide 55 text
Learnings
★ Keep it as simple as possible
★ Try using Mustache
★ Test the setup before releasing to your co-
workers (Readme, Mac/Win/Linux, …)
Slide 56
Slide 56 text
Takeaways
★ Your team must feel comfortable with your
architecture
★ Front end and back end getting more and
more different
★ Cherry-pick the parts you need
★ Some JS frameworks might be hard to use
Slide 57
Slide 57 text
URLs
★ https://github.com/hagenburger/styleguide-api
(WIP)
★ Also: https://github.com/webpack/webpack
★ http://atomicdesign.bradfrost.com
★ Slides: https://twitter.com/hagenburger
Slide 58
Slide 58 text
nico@hagenburger.net
email
twitter
blog
first name
last name
謝謝
Thank you!