Fixing Bootstrap’s known issue with iOS background scrolling

The Bootstrap 4.x framework has a known issue with iOS and modals: When a user “scrolls” on content within a modal overlay, particularly text input fields, background content may scroll (instead).

A quick fix:

body {
    width: 100%;
    max-width: 100%;
    will-change: position;

// Prevent Bootstrap 4.x iOS issue where user
// scrolls the body behind the modal when body height > 100vh

body.modal-open {
    position: fixed;
    top:    0;
    right:  0;
    bottom: 0;
    left:   0;

The use of will-change is entirely optional and may be overkill for the devices and browsers you intend to support. Use with caution.

.modal {
    will-change: display;

.modal-dialog {
    will-change: transform;

If I’ve “locked” the modal to a given height (to enable scrolling within the modal content, I’ll generally re-introduce a rule to activate that nice “bounce scrolling” effect on iOS. The target element may be different for your application or site.

.modal-body {
    overflow: auto;
    -webkit-overflow-scrolling: touch;

You can further choose to wrap these rules with a condition to target iOS devices only, if required:

@supports (-webkit-overflow-scrolling: touch) {
  /* CSS specific to iOS devices */ 

Hope that helps! Good luck.

Product innovation for everyone

Most of the new entrepreneurs I mentor have a product vision but little idea of how to turn their vision into something tangible and profitable.  They have some level of business understanding but little experience to guide their decisions.  They have tools like the ubiquitous “Lean Startup Canvas” but struggle to define their business plan, in particular knowing:

  • How to define a “customer segment” or “target market”
  • How to “validate” customers and prove real-world value
  • Which features, benefits, and other investments to prioritize

The hard problem of new product and company development is overwhelming to the new entrepreneur. In order to overcome such extraordinary difficulty, you must then be an extraordinary person! I believe this perspective may contribute to the public, romantic narrative of “genius product makers” like Steve Jobs and Elon Musk*.  But does “true innovation” require “real genius”, by definition?  In my opinion: No.

Recent scientific studies suggest that a belief in innate, ‘genius’ qualities (mostly in men) may do as much harm as benefit.  Specifically, for an entrepreneur, overvaluing one’s own (expert) opinion creates confirmation bias risk — this could mean allowing a preexisting vision to interfere with third-party feedback and “true” product or technical validation.

A chart of confirmation bias

So, if it doesn’t take a visionary genius, what does smart product development actually require?  Here’s my take:

  • A significant understanding of the customer (users) and the job that they are “hiring the product to do”.
  • Honest intent and excellence of execution
  • Proof that the product provides enough customer value (measured in money, primarily) to be “worth making

One method for creating products with less personal bias is “Outcome-Driven Innovation” (ODI).  ODI was created by Strategyn’s Tony Ulwick to discover “what customers really want”.  Phases in the model include:

  1. Intensive research and identification of customer “jobs to be done”.  The core premise here is that a customer (the product user) “hires” a product to complete a number of “jobs”.
  2. Data gathering on the importance to and current satisfaction of the customer in completing each job
  3. Aligning research data with a viable market strategy

At its heart, the premise of Outcome-Driven Innovation:

  • There are standard, useful models available for creative product development
  • Product outcomes can be defined clearly
  • Customer segments may be selected rationally

The conclusion then, is that “product innovation” is not something only practiced by media-savvy genius founders, but is in fact a teachable and achievable process for most people who are willing and able to put in the hard work.

The painting in the header of this post is Wanderer above the Sea of Fog.
*Also included: Mary Shelley, Edison, Tesla, Turing and whomever the next celeb is.

City of innovation

The Canadian newspaper The Globe and Mail recently interviewed me for “Tech firms aim to reverse Hamilton’s brain drain”, an article covering my work with Kevin Browne (Software Hamilton) and other partners to support a thriving software economy in the city.

Next week we launch the first-ever HamOnt JS conference with support from the Hamilton Innovation Factory, Forge and Foster, Hamilton Economic Development, CoMotion on King, and key organizing partner and longtime software community supporter Fluid Media.

The previous five years have demonstrated that positive innovative economic change is possible in the city of Hamilton.  Forward thinking, mutually-supportive organizations as above why the future will be even better!

Poster of Lister Block by YHM Designs

Your startup should be doing collaborative performance reviews. Here’s why.

When I started Weever Apps, our focus was on building our product and figuring out everything we might accomplish one day. Performance review meetings and similar corporate “kruft” wasn’t on the agenda —that stuff, after all, was exactly the kind of work that made up the type of company we didn’t want to build. We wanted to be different, to be better. We were wrong.

Performance reviews have helped make Weever Apps the better place to work. So why did we start spending time on something like performance reviews?

Here’s why: performance reviews improve a team’s ability to work together and get things done. The goal of a collaborative performance review is to get honest feedback from team members, identify issues and misalignments, and develop ways to work together to create a shared actions plan for the future.

For example, in 2016, I adapted the Lean Business Model Canvas into a Collaborative performance review template and started using it with my own team.

View and download the template

Select “file” > “make a copy” to create a copy in Google Drive for your own use.

If you’re new to the process, this all might seem daunting. So I’ve compiled a simple step-by-step list of how to stage a collaborative performance review:

  1. There is a manager (the facilitator) and an interviewee (the employee or peer). Both parties have access to a [collaborative review template] well in advance and come prepared to communicate their responses with each other.
  2. After verifying that both parties have had a chance to read through the template and gather their thoughts, the meeting starts. The facilitator reminds the interviewee that money/salary discussion is a distraction and not on the agenda.
  3. The manager (or peer) interviews the team member about their work tasks and roles that they like and dislike, following Sakichi Toyoda’s “5 Why’s” method as a guide.
  4. The interviewee communicates their own self-evaluation: the wins, losses, and challenges of their role, and (most importantly) the “why” behind each.
  5. Both parties review a predefined list of skill sets and evaluate how the interviewee is performing. Skills items include communication ability, initiative, attention to detail, and more. Skill discussion, not lengthy project-driven debates, should frame the review in a context of collaborative personal and professional development.
  6. The manager provides the employee with their evaluation. Critical, pre-captured feedback from other team members is included, but not in a combative or interrogative way (g., “one concern that came up from some of your teammates was…”).
  7. The manager and employee collaborate on an action plan to address existing issues, improvement areas and employee requests. Both the manager and the employee have action items (deliverables) to which they will be held accountable at the next review in three or four months.
  8. Finally, both parties sign the action plan and are encouraged to review it for a few minutes each week, evaluating whether they are accomplishing the goals they set forward together.

People on startup teams are more likely to have serious misalignments of roles, responsibilities and goals with their teammates. Early small misalignments often manifest as serious conflicts (and failed companies) in the future. Benefits that a collaborative performance review can deliver include:

  • Getting to the root causes of what is working and not working for team members, allowing teams to address fundamental problems and not various symptoms.
  • Identifying and addressing misalignments on roles and expected responsibilities among team members before they become (more) serious issues.
  • Identifying skill and growth opportunities (g., “I’d really like to try this…”) for each interviewee. This helps keep employees engaged and provides a young company the opportunity to see who may perform well in different roles.
  • Providing team members with specific, clear requests for professional improvement and defining the support required to do so.
  • Aligning team members on priorities, needs, goals and job expectations from others. In my experience, even people who work very closely together are surprised by some of the feedback they receive (both positive and negative). The review is an opportunity to see the company and their work in it from another’s perspective.
  • Setting a documented, collaborative and “fair” basis for future evaluations where both parties can review their performance in addressing the actions plan. In a good team environment evaluation is team-driven and not based on the whims of a manager’s personal bias or recent project experience.

As I have said before, strategy is overemphasized on startup teams; it is execution that matters most.  Performance reviews improve a team’s ability to execute on opportunities and, ultimately, that is what will make any company successful.

Hack Your Community at McMaster University

On November 1st I had the pleasure of serving as a volunteer judge for Spectrum's “Hack Your Community” event.  The 72 hour hackathon focused on creating solutions for the community as a whole and was supported by Community Foundations of Canada.

The winning team, “Project Jenny” embodied the spirit of the event in their innovation: a simple, low-cost, feature phone texting service that returns Google answers on-the-fly.  Well done!

How I hire software developers

I’ve noticed that quite a few job posts for software developers still recruit for “ninjas,” “makers,” or other hip job monikers.

As one of the people responsible for new hires at Weever Apps, I try to carefully write our job placement adverts to demonstrate that our business culture views a developer as a person and not as a cute title. When I see these “of the moment” job titles, I feel that the applicant is being treated only as a commodity. I believe in hiring people.

I was recently asked by a person I was interviewing for a position at Weever Apps how I evaluate software developer job applicants.  I explained that after I establish the applicant’s general technical qualifications, I then evaluate additional attributes to determine their suitability for the job: problem-solving experience, perseverance, and patience.

Problem-solving experience.

My first evaluation addresses the applicant’s commercial or self-directed problem solving experience, – and not their education, training, or certifications. I don’t think there’s a substitute for solving real-world problems with code or other tools. Great developers, in my experience, are professional problem-solvers.

Items which “flag” someone’s proven problem-solving experience include:

  • Active and varying roles on complex work projects.
  • Contributions to open-source github repositories.
  • Volunteering, or co-op work, or internships.
  • Personal projects.
  • Experience with a business case that’s similar to what we do at Weever Apps (fulfilling projects for enterprise clients, working with digital forms, etc.)

Perseverance and Patience.

As with all things, class and other types of privilege give undue advantage to some some individuals. Finding the time to contribute to a github repo, volunteer, or work on personal projects is much easier when you’re already well situated and/or well-off. So I also look for evidence of perseverance and patience in our applicants. While not everyone has the time to volunteer or work on side projects, but most people who really love coding will find ways to pursue and keep their passion active. continue to do so as much as they can.

Perseverance is important. Very few companies build things well on their first try. Most struggle through shifting project scope, employee turnover, miscommunications, and (sometimes) unreasonable expectations. The best people-at-building-things I’ve known have learned to match their intelligence with both the perseverance to confront tough, unfair problems, and with the patience to know when to step back, review whether the problem is actually being solved (well,) – and formulate a new plan.

So when you are looking (or hiring) for a reliable software developer position, remember the three P’s: Problem-solving experience, Perseverance, and Patience. It’s a good formula for developers and a good one for entrepreneurs too I think!