Prototyping in the browser

Software design and development is hard and it’s expensive. A plethora of tools and techniques must be conquered to get from an initial idea to a first click or tab, often just to find out that the users behave quite differently than expected.

Let’s cut some corners! This talk will demonstrate some techniques and technologies on how get the first feedback that much faster and all that within an environment we all share: the browser.

Transcript

1. Prototyping
   in the browser
   

   View Slide

2. View Slide

3. @polarblau
   

   View Slide

4. Prototyping in the browser
   I had the opportunity to work about 50% of my time during the past 5 years on so called
   prototypes for web apps or larger sites for clients, usually within larger teams.
   Still today, the work of prototypes takes about 50% of my week.
   In this context I had the chance to get a clearer impression on how companies use prototypes
   as well as gather some insights on how to build them more effectively.
   

   View Slide

5. Prototyping in the browser
   This talk will be split into two parts:
   1. I’d like to take a few minutes to discuss protoypes in general as well as what prototypes
   currently mean for web development
   2. I’ll give you an high level overview over how I am currently working on prototypes in every–
   day projects
   

   View Slide

6. Prototyping in the browser
   Let’s dive and take a look at what a Prototype can or can not be and why you might want to
   consider using this approach for your own applications and sites.
   

   View Slide

7. Terminology
   Language is funny thing, it always comes with a context yet we often decide to ignore the
   context or remove it artificially. I strongly believe that a lot more issues — especially in
   programming–related fields like web development — are caused directly or indirectly by
   language and the failure to consider context appropriately than by technology.
   As an example: Terms like “Prototyping” live through peaks in usage and often change their
   meaning throughout, causing problems when communicating across generations.
   

   View Slide

8. in30minutes.com
   When I grew up, a prototype was a physical object. We would hear of models of new cars with
   new powerful engines yet no clearly recognizable physical shape.
   

   View Slide

9. πρωτότυπον
   (prototypon)
   And it turns out that this understanding is somewhat close to the origin of the word
   “Prototype”.
   

   View Slide

10. “primitive form”
    There’s no restriction to shape or appearance included.
    

    View Slide

11. “The original or model
    on which something is
    based or formed.”
    I personally like this definition, as it states that a prototype can be an “original”, a useful
    object on it’s on but always functions as starting point for something else.
    

    View Slide

12. A B
    Product
    Prototype
    A prototype works as a vehicle, that gets you where you want to go. It can be starting point
    and way, but it’s never the goal.
    

    View Slide

13. A B
    Surely, prototype and final product will almost always have an area of overlap, but they don’t
    necessarily have to and it’s important that they are not the same.
    

    View Slide

14. A B
    Surely, prototype and final product will almost always have an area of overlap, but they don’t
    necessarily have to and it’s important that they are not the same.
    

    View Slide

15. Early Apple prototype
    from the 1980s, on
    display at Frog Design,
    San Francisco.
    

    View Slide

16. Terminology
    (and the internet)
    With the internet being a representation of society, language doesn’t stop to evolve online. In
    fact, the evolution rate of language is a lot higher than offline.
    With the written word still dominating the environment, people seek and find alternative ways
    to express themselves and are creating variation and dialects in the process.
    

    View Slide

17. View Slide

18. The internet and web development world seems to be particularly good in re–using words
    from the offline world, and giving them new often only slightly metaphorical meaning.
    

    View Slide

19. It’s a cookie,
    get it?
    The internet and web development world seems to be particularly good in re–using words
    from the offline world, and giving them new often only slightly metaphorical meaning.
    

    View Slide

20. 
    And here’s what ticks me off a bit and I’d love to hear if other people have made the same
    experience. When I hear the word “Prototype” in context of web apps, this is what’s usually
    meant by it:
    

    View Slide

21. “Something I tell the developer so
    she will work cheaper, faster and
    skip those time consuming tests
    which no one will ever see
    anyway. Ermarghed! This is going
    to be the best web app ever!
    Javascript and frameworks for
    everyone! ”
    

    View Slide

22. A B
    ==
    The prototype has become the product for very dubious reasons.
    

    View Slide

23. “
    “Even if your idea is worth stealing,
    the hard part is implementing the
    idea, not coming up with it.”
    — Guy Kawasaki on NDAs, 2008
    Let’s back up for a second and try to find a better and more helpful definition of “Prototype”
    for the web. Let’s try to define what makes a prototype a prototype and when it’s a good idea
    to use one.
    

    View Slide

24. Software is hard
    Software is hard, no doubt about it. And Software includes for me by definition all things that
    run within your browser. I could list what makes working on the web difficult — but I’m pretty
    sure everyone is more than aware of why our job sucks sometimes.
    

    View Slide

25. Software is expensive
    Which makes Software expensive. I’ve recently heard that more than 90% [CITATION] of all
    software projects are abandoned before completion. That’s a hell of a waste of money and
    time. — There has to be a way to improve this situation, right?
    

    View Slide

26. We don’t want
    to make mistakes
    We generally and officially don’t want to make mistakes.
    

    View Slide

27. We don’t want need
    to make mistakes
    The truth is — we really do need to make mistake. However would we ever find out what
    works or doesn’t work, assuming we’re not just copying the same old crap and are actually
    innovating?
    

    View Slide

28. We just don’t want to
    release a useless product
    What we really do not want to is release a product no one — maybe not even ourselves —
    want to use because it misses the user’s needs by a mile.
    

    View Slide

29. Innovate
    Test
    Evaluate
    Adjust
    What we should really do — and you have heard this in many different contexts before — is
    iterate over changes and go back to improve on our findings.
    Sounds expensive? — Try to keep the cycle as short as possible and you will safe time and
    money in the end. That’s not a secret.
    

    View Slide

30. Fast
    Cheap
    Pick two!
    Good
    Here’s how I look at prototype development, personally. These are the factors that are
    involved, the “how” we want to build prototypes for web apps.
    I don’t know what “good” means before I don’t test with real users, so let’s scrap that …
    

    View Slide

31. Production
    quality
    Fast
    Cheap
    Pick two!
    … and replace it with high or production quality — “well done”. We should have an idea on
    what that means.
    Still we only get to pick two, right?
    

    View Slide

32. Educational
    Fast
    Cheap
    Pick two!
    And that’s‚ where — for me personally — a prototype allows me to make a course correction
    a production wouldn’t allow me to.
    I’ll replace my expectations on quality with my own personal growth. I want to learn
    something new and experiment, which will benefit the production app behind this prototype
    and every app after that.
    

    View Slide

33. Educational
    Fast
    Cheap
    Pick all?
    And … if using the right tools, I can get them all. When building a prototype.
    

    View Slide

34. Prototype
    ==
    Let’s recap — a prototype
    

    View Slide

35. Throw–away product
    Has to be short–lived and go through short cycles. It will make innovation easier and ease the
    pain dramatically when a restart is required.
    

    View Slide

36. “Scientific” tool
    A prototype has to function as a tool to gather insights of some sorts — either into user
    behavior or internal workflows.
    

    View Slide

37. A great way to learn
    and to fail early
    And a prototype should provide a comfortable way to fail and learn. It shouldn’t hurt to fail
    too much.
    

    View Slide

38. Prototype
    !=
    However, …
    

    View Slide

39. A cheaper way to get
    your app done
    A prototype is not a way to get to “B” faster and cheaper.
    

    View Slide

40. A prototype is not a way to get to “B” faster and cheaper.
    

    View Slide

41. An excuse to release a
    half–baked solution
    And it will not allow you to throw crap at your user. Prototypes don’t come with BETA flags.
    

    View Slide

42. And it will not allow you to throw crap at your user. Prototypes don’t come with BETA flags.
    

    View Slide

43. Fast
    Simple
    Disposable
    Fun
    Here’s my refined definition for prototypes on the web.
    And yes — keep it fun you’ll keep innovating.
    

    View Slide

44. Prototyping in the browser
    Having this runt out of the way, let’s take a look at how my approach to prototypes — which
    is of course largely influenced by the teams I work with.
    

    View Slide

45. Prototyping in the browser
    This talk is called “Prototyping IN THE BROWSER”, so I feel compelled to point out for
    completeness’ sake that it is in fact possible to do some of the work required to get a
    prototype or web app up and running within the browser:
    

    View Slide

46. Remy Sharp has a nice video on how to use the Chrome developer tools to edit local files,
    there’s tons of extensions etc., etc. — but that’s not really what I’m after.
    http://remysharp.com/2012/12/21/my-workflow-never-having-to-leave-devtools/
    

    View Slide

47. Prototyping in the browser
    So let’s rename this talk slightly …
    

    View Slide

48. Prototyping for the browser
    … to prototyping for the browser.
    

    View Slide

49. Ubiquitous
    Why the browser? Why not images, paper prototypes, prototyping apps?
    The browser is omnipresent and very powerful.
    

    View Slide

50. Full–featured
    interaction layer
    It already has everything we need to make a prototype functional, as it basically represents
    the same environment the final version will run in.
    

    View Slide

51. Development tools
    It comes with powerful tools to make our job easier.
    

    View Slide

52. Forgiving
    And it’s forgiving. If you have some time — take a look at how browsers parse and
    understand your code. There’s some awesome articles around.
    Remember when we replaced “high quality”? This property of the browser will be invaluable in
    this regard.
    

    View Slide

53. Tools
    Let’s take a look at the gears. I’m using a fairly wide set of tools, each comes with it’s own
    strengths and problems — so I’ll go through them rather quickly.
    You will also know a some of them already, I’m sure.
    If you’re interested, look up these slides on Speakerdeck later, come ask afterwards or just
    go browser a bit.
    It is important for me, that these tools fulfill early mentioned criteria. — To say the least, they
    have to speed up my workflow.
    

    View Slide

54. Go–to language
    Ruby
    [Javascript, Python]
    As a go–to language, the language I use to solve all small issues I encounter along the way, I
    use Ruby. I love Ruby. RUBY IS AWESOME. If you haven’t yet - take a look.
    

    View Slide

55. Within templates
    Scripting tools (Thor)
    Helpers
    …
    I’m using Ruby within templates, to write helpers and scripts.
    

    View Slide

56. Server & framework
    Middleman
    [Serve]
    To keep all other tools together, I’m using Middleman — a so called static site generator. But
    it does a lot more than that.
    

    View Slide

57. Get started quickly
    It helps you to get set–up really fast.
    

    View Slide

58. $ gem install middleman
    $ middleman init awesome_proto
    or
    $ middleman init awesome_proto --template=html5
    It comes as Ruby gem — which is essentially a packaged Ruby library. You can generate a
    scaffold for your web app and use templates for custom structures while doing so. There’s a
    wide variety out there.
    

    View Slide

59. Conventions
    In the best tradition of Rails and “convention over configuration” it comes with conventions
    for most things you’ll need along the way and is extendable where it doesn’t.
    

    View Slide

60. Dependencies
    management
    

    View Slide

61. Views and
    layouts
    Middleman has a built–in layout engine with support for multiple, switchable layouts, views
    and partials…
    

    View Slide

62. OOTB support for
    meta languages*
    … in any templating language your heart desires. It also support a wide range of other meta
    languages — but more about that later.
    

    View Slide

63. Server
    Middleman sports an easily accessible web server.
    

    View Slide

64. $ middleman server
    == The Middleman is loading
    == The Middleman is standing watch at http://
    0.0.0.0:4567
    Start it with by running `middleman server` or simply `middleman` and it will start serving
    files and views at localhost
    

    View Slide

65. View Slide

66. Export
    It allows you to easily export your project as static HTML/CSS/JS files.
    

    View Slide

67. $ middleman build
    create build/images/middleman.png
    create build/images/background.png
    identical build/images/middleman.png
    identical build/images/background.png
    create build/javascripts/all.js
    create build/stylesheets/normalize.css
    create build/stylesheets/all.css
    create build/index.html
    AND A LOT MORE.
    

    View Slide

68. Mark–up
    Haml
    [Slim, Jade]
    For mark-up I’m using Haml, a HTML templating language you’ve likely at least heard about.
    

    View Slide

69. Indentation == nesting
    It speeds up writing HTML massively for me, as it’s whitespace–sensitive.
    

    View Slide

70. %article
    %section
    %h1 Hello World
    %p Content goes here
    %a(href="http://foobar.com") Foobar!
    To nest tags, simple indent them.
    

    View Slide

71. #foo
    BECOMES
    
    It comes with handy shortcuts.
    

    View Slide

72. .bar
    BECOMES
    
    #foo.bar
    BECOMES
    
    AND A LOT MORE!
    

    View Slide

73. Haml + Ruby
    For me, Haml really starts to shine when used with some Ruby helpers and functions.
    

    View Slide

74. %ul
    - 10.times do |num|
    %li= "Item #{num}"
    A simple example I’m using often to get a lot of content quickly to test e.g. floating layouts.
    This will print ten list elements.
    

    View Slide

75. Haml + Ruby + Middleman
    As Middleman is written in Ruby, it comes with a lot of layout helpers which you can use
    within of course within your Haml templates.
    

    View Slide

76. Layouts and partials
    It supports layouts and partial views
    

    View Slide

77. %body
    #container
    = partial "header"
    #main
    = yield
    = partial "footer"
    This is a layout, yield will insert whatever the current view returns.
    

    View Slide

78. = content_for :sidebar do
    = partial "product_sidebar"
    ELSEWHERE
    %aside
    = yield_content :sidebar
    content_for allows you to define a block of content to be used elsewhere on the page. Very
    handy for content outside the current view which depends on content within the view.
    

    View Slide

79. Helpers
    And it has a whole array of handy helpers.
    

    View Slide

80. = simple_format("hello\nworld")
    BECOMES
    hello
    world
    = pluralize(2, "person")
    BECOMES
    2 people
    

    View Slide

81. Stylesheets
    Sass
    [Less, Stylus]
    I write all stylesheets using Sass using the .sass syntax — not having to worry about braces
    and semi–colons is a huge time saver.
    

    View Slide

82. Indentation == nesting
    And as you’re likely aware, it works very similarly to Haml — hierarchy is expressed through
    indentation.
    

    View Slide

83. article
    h1
    color: red
    span
    color: green
    

    View Slide

84. Variables
    We got variables
    

    View Slide

85. $some-color: #f00
    article
    h1
    color: $some-color
    span
    color: green
    

    View Slide

86. Operations
    Mathematical operations.
    

    View Slide

87. $width: 100px
    .half
    width: $width / 2
    .half-plus
    width: $width / 2 + 20px
    

    View Slide

88. Functions
    Functions
    

    View Slide

89. $some-color: #f00
    article
    h1
    color: lighten($some-color, 50%) // => #f33
    

    View Slide

90. Mixins
    Repeatable blocks of code through mixins — a sort of function which takes even arguments.
    

    View Slide

91. =very-important($color: red)
    font-weight: bold
    color: $color
    article
    h1
    +very-important
    

    View Slide

92. Partials
    And once again partials and includes which Sass will compile into the same file.
    

    View Slide

93. @import "header"
    @import "footer"
    

    View Slide

94. Content / Data
    YAML
    [JSON, XML]
    I try to keep the actual content for the prototype as YAML files as Middleman provides OOTB
    support for it.
    

    View Slide

95. friends:
    - Tom
    - Dick
    - Harry
    YAML is a human readable data format much like JSON but without the curly braces.
    

    View Slide

96. %ul
    - data.friends.each do |friend|
    %li= friend
    And it’s very easy to use within the templates with a little bit of Ruby magic.
    

    View Slide

97. i18n
    Middleman comes with baked–in support for internationalization. Something you should
    definitely test within your prototype where it applies. Your app or site might need bigger
    adjustments to accommodate LTR languages, etc.
    

    View Slide

98. en:
    hello:
    world: "Hello"
    A YAML file as used by Middlemans i18n functionality.
    

    View Slide

99. %h1= I18n.t("hello.world")
    And this is how you’d use it within the app.
    

    View Slide

100. Scripts
     CoffeeScript
     [Opal]
     I’m trying to write all Javascript in CoffeeScript if my team allows it. But I won’t go any further
     in to detail here.
     If you are interested in CS but haven’t gotten around to learning it — follow me on Twitter.
     I’ve some upcoming course here in Helsinki you might want to attend.
     

     View Slide

101. Version control
     Git
     [SVN]
     Another thing I won’t go into much detail about is version control. If you keep your
     production app under version control you should definitely keep your prototype under VC.
     And Gits support for branching is like made for prototype feature cycles.
     

     View Slide

102. Techniques
     Still a quick overview over some of the techniques I’ve been using to get my prototypes done
     quickly before I let you go.
     

     View Slide

103. Modularity
     The biggest factor in speedy development for me is a modular structure.
     Modules and components of re–usable code — if built properly and with a certain degree of
     flexibility baked–in — will improve your work–speed that much.
     

     View Slide

104. Layouts and partials
     The previously mentioned tools support this approach through layouts and partials —
     enabling re–usable view code.
     

     View Slide

105. Plugin infrastructure
     I like to keep especially a good library of Javascript libraries and jQuery plugins I’ve written
     mostly myself around which all use similar structures are easily switched–out.
     

     View Slide

106. Component libraries
     (packaged)
     I recently had the opportunity to work with the fairly new and awesome front–end team at a
     local software company called Siili on the renewed Nokia.com which — for me is was a great
     use case component driven prototype development.
     

     View Slide

107. Ville
     This is Ville — the Creative Director at Siili and a dear friend of mine — I believe they’re
     hiring, too, btw..
     If you want to hear the story behind the hot dog suit, hit me up later.
     

     View Slide

108. Custom tool chain
     Scripts
     As a lazy developer I’ve started to use Thor scripts which can be executed from the terminal
     for …
     

     View Slide

109. Generators
     … the generation of files and components
     

     View Slide

110. Finders
     … to find and modify stuff within a project
     

     View Slide

111. Visualizations
     … or to visualize certain aspects of a project.
     

     View Slide

112. Custom tool chain
     Libraries
     And — last but not least — Middleman is only Ruby and built on Rack which makes it
     inheritably extendable. If a required functionality is not built–in go take a look around,
     someone might have already solved your problem.
     

     View Slide

113. Asset management
     Problems including asset management …
     

     View Slide

114. Session management
     … session management
     

     View Slide

115. i18n
     … or content and internationalization.
     

     View Slide

116. Questions?
     

     View Slide

117. Thanks!
     Kiitos!
     

     View Slide