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.

1. Prototyping in the browser
3. @polarblau
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.
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
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.
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.
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.
9. πρωτότυπον (prototypon) And it turns out that this understanding is somewhat close to the origin of the word “Prototype”.
10. “primitive form” There’s no restriction to shape or appearance included.
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.
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.
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.
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.
15. Early Apple prototype from the 1980s, on display at Frog Design, San Francisco.
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.
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.
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.
20. <rant> 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:
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! ”
22. A B == The prototype has become the product for very dubious reasons.
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.
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.
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?
26. We don’t want to make mistakes We generally and officially don’t want to make mistakes.
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?
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.
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.
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 …
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?
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.
33. Educational Fast Cheap Pick all? And … if using the right tools, I can get them all. When building a prototype.
34. Prototype == Let’s recap — a prototype
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.
36. “Scientific” tool A prototype has to function as a tool to gather insights of some sorts — either into user behavior or internal workflows.
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.
38. Prototype != However, …
39. A cheaper way to get your app done A prototype is not a way to get to “B” faster and cheaper.
40. A prototype is not a way to get to “B” faster and cheaper.
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.
42. And it will not allow you to throw crap at your user. Prototypes don’t come with BETA flags.
43. Fast Simple Disposable Fun Here’s my refined definition for prototypes on the web. And yes — keep it fun you’ll keep innovating.
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.
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:
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/
47. Prototyping in the browser So let’s rename this talk slightly …
48. Prototyping for the browser … to prototyping for the browser.
49. Ubiquitous Why the browser? Why not images, paper prototypes, prototyping apps? The browser is omnipresent and very powerful.
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.
51. Development tools It comes with powerful tools to make our job easier.
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.
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.
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.
55. Within templates Scripting tools (Thor) Helpers … I’m using Ruby within templates, to write helpers and scripts.
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.
57. Get started quickly It helps you to get set–up really fast.
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.
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.
60. Dependencies management
61. Views and layouts Middleman has a built–in layout engine with support for multiple, switchable layouts, views and partials…
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.
63. Server Middleman sports an easily accessible web server.
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
66. Export It allows you to easily export your project as static HTML/CSS/JS files.
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.
68. Mark–up Haml [Slim, Jade] For mark-up I’m using Haml, a HTML templating language you’ve likely at least heard about.
69. Indentation == nesting It speeds up writing HTML massively for me, as it’s whitespace–sensitive.
70. %article %section %h1 Hello World %p Content goes here %a(href="http://foobar.com") Foobar! To nest tags, simple indent them.
71. #foo BECOMES <div id="foo"></div> It comes with handy shortcuts.
72. .bar BECOMES <div class="bar"></div> #foo.bar BECOMES <div id="foo" class="bar"></div> AND A LOT MORE!
73. Haml + Ruby For me, Haml really starts to shine when used with some Ruby helpers and functions.
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.
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.
76. Layouts and partials It supports layouts and partial views
77. %body #container = partial "header" #main = yield = partial "footer" This is a layout, yield will insert whatever the current view returns.
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.
79. Helpers And it has a whole array of handy helpers.
80. = simple_format("hello\nworld") BECOMES <p>hello<br/>world</p> = pluralize(2, "person") BECOMES 2 people
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.
82. Indentation == nesting And as you’re likely aware, it works very similarly to Haml — hierarchy is expressed through indentation.
83. article h1 color: red span color: green
84. Variables We got variables
85. $some-color: #f00 article h1 color: $some-color span color: green
86. Operations Mathematical operations.
87. $width: 100px .half width: $width / 2 .half-plus width: $width / 2 + 20px
88. Functions Functions
89. $some-color: #f00 article h1 color: lighten($some-color, 50%) // => #f33
90. Mixins Repeatable blocks of code through mixins — a sort of function which takes even arguments.
91. =very-important($color: red) font-weight: bold color: $color article h1 +very-important
92. Partials And once again partials and includes which Sass will compile into the same file.
93. @import "header" @import "footer"
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.
95. friends: - Tom - Dick - Harry YAML is a human readable data format much like JSON but without the curly braces.
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.
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.
98. en: hello: world: "Hello" A YAML file as used by Middlemans i18n functionality.
99. %h1= I18n.t("hello.world") And this is how you’d use it within the app.
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.
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.
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.
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.
104. Layouts and partials The previously mentioned tools support this approach through layouts and partials — enabling re–usable view code.
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.
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.
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.
108. Custom tool chain Scripts As a lazy developer I’ve started to use Thor scripts which can be executed from the terminal for …
109. Generators … the generation of files and components
110. Finders … to find and modify stuff within a project
111. Visualizations … or to visualize certain aspects of a project.
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.
113. Asset management Problems including asset management …
114. Session management … session management
115. i18n … or content and internationalization.
116. Questions?
117. Thanks! Kiitos!