Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Prototyping in the browser

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.

Florian Plank

May 23, 2013
Tweet

More Decks by Florian Plank

Other Decks in Programming

Transcript

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. πρωτότυπον (prototypon) And it turns out that this understanding is

    somewhat close to the origin of the word “Prototype”.
  7. “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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. <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:
  15. “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! ”
  16. “ “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.
  17. 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.
  18. 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?
  19. 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?
  20. 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.
  21. 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.
  22. 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 …
  23. 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?
  24. 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.
  25. Educational Fast Cheap Pick all? And … if using the

    right tools, I can get them all. When building a prototype.
  26. 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.
  27. “Scientific” tool A prototype has to function as a tool

    to gather insights of some sorts — either into user behavior or internal workflows.
  28. 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.
  29. A cheaper way to get your app done A prototype

    is not a way to get to “B” faster and cheaper.
  30. 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.
  31. And it will not allow you to throw crap at

    your user. Prototypes don’t come with BETA flags.
  32. Fast Simple Disposable Fun Here’s my refined definition for prototypes

    on the web. And yes — keep it fun you’ll keep innovating.
  33. 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.
  34. 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:
  35. 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/
  36. Ubiquitous Why the browser? Why not images, paper prototypes, prototyping

    apps? The browser is omnipresent and very powerful.
  37. 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.
  38. 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.
  39. 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.
  40. 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.
  41. Within templates Scripting tools (Thor) Helpers … I’m using Ruby

    within templates, to write helpers and scripts.
  42. 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.
  43. $ 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.
  44. 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.
  45. Views and layouts Middleman has a built–in layout engine with

    support for multiple, switchable layouts, views and partials…
  46. 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.
  47. $ 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
  48. $ 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.
  49. Mark–up Haml [Slim, Jade] For mark-up I’m using Haml, a

    HTML templating language you’ve likely at least heard about.
  50. Haml + Ruby For me, Haml really starts to shine

    when used with some Ruby helpers and functions.
  51. %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.
  52. 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.
  53. %body #container = partial "header" #main = yield = partial

    "footer" This is a layout, yield will insert whatever the current view returns.
  54. = 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.
  55. 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.
  56. Indentation == nesting And as you’re likely aware, it works

    very similarly to Haml — hierarchy is expressed through indentation.
  57. Mixins Repeatable blocks of code through mixins — a sort

    of function which takes even arguments.
  58. 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.
  59. friends: - Tom - Dick - Harry YAML is a

    human readable data format much like JSON but without the curly braces.
  60. %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.
  61. 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.
  62. en: hello: world: "Hello" A YAML file as used by

    Middlemans i18n functionality.
  63. 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.
  64. 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.
  65. 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.
  66. 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.
  67. Layouts and partials The previously mentioned tools support this approach

    through layouts and partials — enabling re–usable view code.
  68. 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.
  69. 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.
  70. 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.
  71. Custom tool chain Scripts As a lazy developer I’ve started

    to use Thor scripts which can be executed from the terminal for …
  72. 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.