Benchmark Slim with Markdown

bench_slim_md.rb

require 'slim'
require 'benchmark/ips'

Benchmark.ips do |x|
  x.report("pure slim") { Slim::Template.new('template_slim.slim').render }
  x.report("slim with markdown") { Slim::Template.new('template_md.slim').render }
  x.compare!
end

results.txt

Warming up --------------------------------------
           pure slim    11.000  i/100ms
  slim with markdown    22.000  i/100ms
Calculating -------------------------------------
           pure slim    111.471  (± 3.6%) i/s -    561.000  in   5.038270s
  slim with markdown    232.836  (± 3.9%) i/s -      1.166k in   5.016963s

Comparison:
  slim with markdown:      232.8 i/s
           pure slim:      111.5 i/s - 2.09x slower

template_md.slim

.cut
  markdown:
    Though some of our customers are new to creating guided tours, many do have
    experience with building walkthroughs developed and controlled by their
    product development and engineering teams. At some point, they outgrow this
    process and come to Inline Manual.

     Naturally, one of the most common questions we hear when they join our
    webinars and demos early in their search is “How much control will I have?” Or
    as one client put it more plainly: “Can I get this out of the hands of
    engineering?” Ouch.

.details
  markdown:
    ### DIY is not A-OK

    At the start, development or engineering teams implement open source
    libraries to build tutorials, tooltips and tours right into their
    applications. This works really well for a little while. Marketing teams see
    people are completing their onboarding, the support teams see less tickets.
    Everyone is happy! This works for a little while, until suddenly it just
    doesn’t.

    Especially when the teams are small, it means communication is easy, and any
    required changes can be made quickly. As a small company grows, or of course
    in larger companies, the people who see the need to build those tours are
    based in the marketing or support teams.

    This means requests for changes to tutorials get filed alongside bug reports
    and feature requests. In terms of priority, this means they may have to wait
    days or weeks to see their changes made. Each request must be carefully
    communicated, because any further change means yet more delays.

    This means they have a number of problems.

    #### What are some problems a DIY approach creates?

      * **Authoring and creating content is slow.**
        * Requests for changes can take a long time to fulfill. Even with simple
          text changes, each new alteration is a new “work request” or backlog
          issue, subject to the prioritization of product development.
      * **It’s not possible to change content on the fly.**
        * Depending on the workflow, it can sometimes mean a marketing team
          member must hand over a document which carefully specifies the text,
          directions, and click actions to design a walkthrough. They have to
          include marked-up screenshots to even show where to place the launchers or
          tooltips. Then this has to coded and developed with skills only a
          developer has, and precious developer time is tightly time-boxed.
      * **Not on the same schedule**
        * Because of the reasons described above, though the marketing team
          might need a tour to be updated now, they still have to wait until the
          planned release to see their changes live.
      * **No [Analytics](https://inlinemanual.com/analytics). Lack of visibility into results.**
        * The teams who need to track results have little insight into which
          content is performing best, and where people are getting lost in drop-
          off funnels. They may be using site analytics, but it’s difficult to
          identify where the content is helping or not.
      * **It’s time-consuming to develop and test.**
        * Selecting the right elements, testing, and managing the tours - it all
          gets complex when you’re taking a code-only DIY approach to managing the
          content.

    We hear about these issues from our new customers. These are not terrible
    tales of woe. These are normal, practical problems and friction they deal with
    day-to-day. And, it was all probably manageable until it became clearly too
    costly and time consuming. Small frustrations like these seems to build up
    until it’s just too much.

    At some point, they come to the conclusion that the time spent in
    communication, coordination and development of product tours could be better
    spent by moving control over to the marketing and support teams who are
    closely monitoring user engagement and needs.

    The problem is, our potential customers must evaluate all of the onboarding
    solutions out there, find a good one and then finally, convince their
    engineering teams <em> it’s time to let go</em>.

    ### What is engineering concerned about?

    Considering the amount of friction a DIY solution can cause, you have to
    wonder then, why would engineering teams be so unwilling to let go of this?
    When their response is delayed, it can make marketing and support teams feel
    like communicating with customers is must be considered low-priority by
    engineering teams.However it’s more likely the opposite, that the engineering
    teams do hold this as very high-priority, and they want it to be as high-
    quality as their app, QA tested, and seamlessly branded.

    In fact, engineering might be afraid that using a third-party solution will
    mean it would be inferior to what they can craft bespoke for their
    application. Let’s consider their concerns.

    * **What about the lack of design control?**
      * They want to be able to control of the CSS entirely. They want to
        inherit or reuse the existing CSS from their application so updates are
        easier to manage. They don’t want a third party solution confusing their
        brand experience.
    * **What about the display, positioning, placement?**
      * They’re concerned about being unable to control where tips appear, by
        either choosing selectors, or manually editing selectors, and placing
        where they appear.
    * **Do we want to do maintain yet another third party service?**
      * They might worry about having to reconfigure every time a third party
        service updates. Or having to engage a third party service who charges for
        yet more professional services just to make the basic features work as
        expected.
    * **What about the lack of QA and testing? Don’t touch the live site!**
      * They’re worried about letting support and marketing teams edit
        interactive elements which will be edited LIVE on a LIVE site. That is
        crazy talk. They prefer clear points for QA, testing and deployment. They
        don’t want to deal with kludgy workarounds of copying or re-creating
        tours.

    Finally, and this might sound harsh, but some extent Engineering teams
    feel guilty about adding tutorials to apps. It’s a delicate subject to broach.
    Admitting your UI needs a tour is like saying there’s an inferior user
    experience that needs an interpreter. User experience designers may, as
    <a href="https://vimeo.com/131407754" target="_new">Kathy Sierra said</a>,
    think a product should be so good it doesn’t need a manual.

    Engineering teams therefore might feel the issues could be fixed with a
    better design. Maybe they have to tweak the UI or add another feature? And
    this explains why product-specific issues can take precedence when there are
    requests for updating a product tour.

    Of course engineering will continue the conversation with users to find
    tweaks and improvements to the interface. What engineering teams don’t know
    yet is that by having contextual help, tutorials and auto-launching tours they
    can provide a more empathic user interface which gives support to different
    customer groups even better than they can in their UI.

    For example, new users might leap delightfully into a new UI or feature, and
    yet existing users might need more hand-holding to manage the change to un-
    stick their habits. There are also certain kinds of users to playfully
    discover in a UI, and other users who really want assurance the entire way.

    Perhaps there isn’t even a clear way to tweak the UI to help all users. But
    a guided tour can, and perhaps even smarter by providing specific user groups
    the right messages. When the engineering and product teams give control of
    this layer to their customer-facing colleagues, they can have a more
    emotionally responsive and helpful UI. And, it can save hundreds of support
    requests from existing users asking “who moved things around here?”

    In Part 2, we’ll answer your questions about how much control you’ll have
    when you’re using Inline Manual.

template_slim.slim

.cut

  p Though some of our customers are new to creating guided tours, many do have
    experience with building walkthroughs developed and controlled by their
    product development and engineering teams. At some point, they outgrow this
    process and come to Inline Manual.

  p Naturally, one of the most common questions we hear when they join our
    webinars and demos early in their search is “How much control will I have?” Or
    as one client put it more plainly: “Can I get this out of the hands of
    engineering?” Ouch.

.details

  / p
  /   img src=image_path('blog/blog-fb-li-control.jpg') class='img-responsive'
  / br

  h3 DIY is not A-OK

  p At the start, development or engineering teams implement open source
    libraries to build tutorials, tooltips and tours right into their
    applications. This works really well for a little while. Marketing teams see
    people are completing their onboarding, the support teams see less tickets.
    Everyone is happy! This works for a little while, until suddenly it just
    doesn’t.

  p Especially when the teams are small, it means communication is easy, and any
    required changes can be made quickly. As a small company grows, or of course
    in larger companies, the people who see the need to build those tours are
    based in the marketing or support teams.

  p This means requests for changes to tutorials get filed alongside bug reports
    and feature requests. In terms of priority, this means they may have to wait
    days or weeks to see their changes made. Each request must be carefully
    communicated, because any further change means yet more delays.

  p This means they have a number of problems.

  p
   strong What are some problems a DIY approach creates?

  p
   ul
    li
      strong Authoring and creating content is slow.
      ul
        li Requests for changes can take a long time to fulfill. Even with simple
          text changes, each new alteration is a new “work request” or backlog
          issue, subject to the prioritization of product development.
    li
      strong It’s not possible to change content on the fly.
      ul
        li Depending on the workflow, it can sometimes mean a marketing team
          member must hand over a document which carefully specifies the text,
          directions, and click actions to design a walkthrough. They have to
          include marked-up screenshots to even show where to place the launchers or
          tooltips. Then this has to coded and developed with skills only a
          developer has, and precious developer time is tightly time-boxed.
    li
      strong Not on the same schedule.
      ul
        li Because of the reasons described above, though the marketing team
          might need a tour to be updated now, they still have to wait until the
          planned release to see their changes live.
    li
      strong No <a href="https://inlinemanual.com/analytics">Analytics</a>. Lack of visibility into results.
      ul
        li The teams who need to track results have little insight into which
          content is performing best, and where people are getting lost in drop-
          off funnels. They may be using site analytics, but it’s difficult to
          identify where the content is helping or not.
    li
      strong It’s time-consuming to develop and test.
      ul
        li Selecting the right elements, testing, and managing the tours - it all
          gets complex when you’re taking a code-only DIY approach to managing the
          content.

  p We hear about these issues from our new customers. These are not terrible
    tales of woe. These are normal, practical problems and friction they deal with
    day-to-day. And, it was all probably manageable until it became clearly too
    costly and time consuming. Small frustrations like these seems to build up
    until it’s just too much.

  p At some point, they come to the conclusion that the time spent in
    communication, coordination and development of product tours could be better
    spent by moving control over to the marketing and support teams who are
    closely monitoring user engagement and needs.

  p The problem is, our potential customers must evaluate all of the onboarding
    solutions out there, find a good one and then finally, convince their
    engineering teams <em>it’s time to let go</em>.

  h3 What is engineering concerned about?

  p Considering the amount of friction a DIY solution can cause, you have to
    wonder then, why would engineering teams be so unwilling to let go of this?
    When their response is delayed, it can make marketing and support teams feel
    like communicating with customers is must be considered low-priority by
    engineering teams.However it’s more likely the opposite, that the engineering
    teams do hold this as very high-priority, and they want it to be as high-
    quality as their app, QA tested, and seamlessly branded.

  p In fact, engineering might be afraid that using a third-party solution will
    mean it would be inferior to what they can craft bespoke for their
    application. Let’s consider their concerns.

  p
   ul
    li
      strong What about the lack of design control?
      ul
        li They want to be able to control of the CSS entirely. They want to
          inherit or reuse the existing CSS from their application so updates are
          easier to manage. They don’t want a third party solution confusing their
          brand experience.

    li
      strong What about the display, positioning, placement?
      ul
        li They’re concerned about being unable to control where tips appear, by
          either choosing selectors, or manually editing selectors, and placing
          where they appear.
    li
      strong Do we want to do maintain yet another third party service?
      ul
        li They might worry about having to reconfigure every time a third party
          service updates. Or having to engage a third party service who charges for
          yet more professional services just to make the basic features work as
          expected.

    li
      strong What about the lack of QA and testing? Don’t touch the live site!
      ul
        li They’re worried about letting support and marketing teams edit
          interactive elements which will be edited LIVE on a LIVE site. That is
          crazy talk. They prefer clear points for QA, testing and deployment. They
          don’t want to deal with kludgy workarounds of copying or re-creating
          tours.

  p Finally, and this might sound harsh, but some extent Engineering teams
    feel guilty about adding tutorials to apps. It’s a delicate subject to broach.
    Admitting your UI needs a tour is like saying there’s an inferior user
    experience that needs an interpreter. User experience designers may, as
    <a href="https://vimeo.com/131407754" target="_new">Kathy Sierra said</a>,
    think a product should be so good it doesn’t need a manual.

  p Engineering teams therefore might feel the issues could be fixed with a
    better design. Maybe they have to tweak the UI or add another feature? And
    this explains why product-specific issues can take precedence when there are
    requests for updating a product tour.

  p Of course engineering will continue the conversation with users to find
    tweaks and improvements to the interface. What engineering teams don’t know
    yet is that by having contextual help, tutorials and auto-launching tours they
    can provide a more empathic user interface which gives support to different
    customer groups even better than they can in their UI.

  p For example, new users might leap delightfully into a new UI or feature, and
    yet existing users might need more hand-holding to manage the change to un-
    stick their habits. There are also certain kinds of users to playfully
    discover in a UI, and other users who really want assurance the entire way.

  p Perhaps there isn’t even a clear way to tweak the UI to help all users. But
    a guided tour can, and perhaps even smarter by providing specific user groups
    the right messages. When the engineering and product teams give control of
    this layer to their customer-facing colleagues, they can have a more
    emotionally responsive and helpful UI. And, it can save hundreds of support
    requests from existing users asking “who moved things around here?”

  p In Part 2, we’ll answer your questions about how much control you’ll have
    when you’re using Inline Manual.