Coffee Walks is a new and ongoing interview show from the Pathwright team. Mark Johnson discusses the importance of side projects in his own life and the Pathwright team.

Coffee Walks is a new and ongoing interview show from the Pathwright team. We'll talk about technology and teaching through stories that connect them. In this episode, Mark Johnson discusses the importance of side projects in his own life and the Pathwright team. 

Host: Christian Shockley
Guest: Mark Johnson

More from Mark:

"How I Launched Six Side Projects in 2017" 

Have an idea for an interview topic? Send questions, comments, or topic suggestions our way on Facebook, Twitter, or Instagram or email christian@pathwright.com. We'd love to hear from you!

coffee_walks_1-_mark_johnson_on_side_projects.mp3

The first person to ever complete a Pathwright course was a retired gentleman in his 70s. He’d never even used a computer before. His granddaughter set him up with a laptop, internet connection, and a barely-working Pathwright account.

The first person to ever complete a Pathwright course was a retired gentleman in his 70s. He’d never even used a computer before. His granddaughter set him up with a laptop, internet connection, and a barely-working Pathwright account that he used to blaze through the course faster than all the other beta testers.

That was in 2011 when Pathwright was just two twins (Mark & me) hacking together in our spare bedroom and spare time. Our first goal was to design a course experience so simple anyone could do it. And this fine gentleman validated that we were on the right track. That felt great.

Back then, we wanted nothing more than to make a simple, beautiful product that teachers and learners alike would love. We spent the next five years bootstrapping Pathwright from a side project into a team of people serving thousands of educators.

But, after launching Pathwright 2 in 2016, I slumped into dissatisfaction with our product. It’s not that it wasn’t working. In fact, people loved the changes we’d made. But I’d begun to fall into the Silicon Valley trap of thinking that somehow our little software app needed to “change the world.”

Now we’ve never fit the mold of a Silicon Valley startup. We turned down venture capital in favor of bootstrapping and have always been profitable because we’ve had to be. We've always run Pathwright more like an ordinary business. That isn’t to say we’re not ambitious, but we're not motivated by truckloads of money or fame. We're more interested in making a dent in the world for good while we can.

Despite this, I’d drifted towards the stereotypical Silicon Valley siren call that our product might just change the entire world. But the reality is that most businesses — and especially software businesses — aren’t going to change the world. And that’s ok. Software is merely a tool, after all.

We’re not hoodie-wearing heroes, we’re the craftspeople and tool makers. Our role in the story is more like Ollivander, Harry Potter’s wand maker, Batman’s assistant, Alfred, and Don Quixote’s horse.

Let’s get over ourselves. Sure, viewing our trade as techsmiths isn’t as glamorous but it is fulfilling and noble.

Once we stopped navel-gazing at our product and put ourselves in our proper place, we had the clarity to formulate our true purpose. Here’s what we came up with:

Our mission is to multiply the impact teachers make on the world.

This simple mission frees us from struggling to play the hero and focuses us only on helping the people who truly make a difference in the world: Teachers.

If you’ve got something to teach, then you’re the hero of our story. And if our Pathwright can cut down your busywork so you have more time to teach and give you tools that help you teach more personally and reach more people, then we’re multiplying the impact you already have. And that’s what changes the world.

If you'd like to design a course, we invite you to try out Pathwright for free.

You can also send questions, comments, or topic suggestions our way on Facebook, Twitter, or Instagram or email lydia@pathwright.com. We'd love to hear from you!

The web is in an awkward phase right now. We’re transitioning from an era where a website was simply a collection of linked pages to one where even using the term “page” to describe a particular screen is a giant oversimplification.

Blocks, Not Pages, Are the Future Of the Web

When I first started web development, the job was mostly . . .

FTP that baby up to your server and . . .

Boom; you’ve published to the internet. Let’s just say it’s rarely that simple anymore.

While it’s tempting to bemoan the loss of that simple early web, it’s important to realize that the early web was simple because the use cases were simple. The web was primarily an online index of documents that could link to each other.

The modern web is a mixture of complex interactions, responsive content, and social layers that make a document-centric approach an awkward paradigm that isn’t scaling well to user expectations or needs.

It’s a little known fact that the simple document-based approach to the web was not the desired outcome for the early-innovators who built the foundations for the web we know now.

Pioneers like Ted Nelson, Alan Kay, and Doug Engelbart pushed for ideas that go far beyond what we have today. They presented fantastic visions of a future where computing embraced its true digital and collaborative nature to become something entirely new and more powerful.

What we got instead was a bunch of digital documents in digital folders; it does the job, it’s familiar and comfortable, but we’ve lost a lot by taking that path.

⬅ The web we wanted  /  The web we got ➡

Documents and pages are the wrong construct for the modern web. I would argue the web should be built in blocks (or components if you will), not documents.

Blocks provide a different way of thinking about web content as a self-contained unit. Perhaps it’s helpful to visualize at a lego brick which you can build documents (or apps) with.

In the developer world we would call these “components” whereas content creators might call this "micro-content." For the sake of this article I’m referring to both of these concerns, among others, simply as a block.

I’ll explain what I mean and why this is a better approach for publishers, end users, and developers alike.

An open text document, which is where the web started, has no inherent meaning. Any added meaning has to be layered on through tags, meta information, or formatting. There have been many efforts to enrich textual content with more structured meaning over the years and most of these have fallen flat (the semantic web for example).

The problem is multi-faceted, but I think the root of the issue is that the meaning and structure is layered on after the fact rather than being core part of the creation process.

Blocks flip that idea on its head: you don’t markup content as being a heading, you create that content as a heading. That’s a subtle but profound difference.

Blocks provide a way to take discrete units of both content and function and put them together in different ways without sacrificing the integrity of the system.

Much effort has been spent trying do this with “native” web technology via complex CSS schemes (BEM, SMACKS etc.), XML, web components, etc. While some solutions are more elegant than others, these techniques try to force a modular, block-centric workflow on document-centric medium and the results are awkward and cumbersome at best.

This problems is largely solved with component-centric frameworks like React or Vue that make the components the first class citizen.

That said, these frameworks have to rely on complex tooling to get out of that document-centric paradigm and put components (blocks) at the top where they should have been all along.

Encapsulation is a principle used by programmers to make code more reusable and reliable for decades but it applies equally well to blocks.

Thinking of your content and UI as modular units and then actually developing them that way removes the dissonance of trying to develop block-based content with document-based tech and makes it much easier to ensure quality.

Our team has components we haven’t touched in years that are completely self-contained and Just Work™.

Blocks are structured enough to allow for a richer form of collaboration than a document can. Historically editors have had to “get out the red pen” or highlight, underline, and leave notes in the margin to give feedback on documents.

Imagine how much better it could be if feedback and reference tools were actually aware of the type of content referenced? For instance, leaving feedback on a video block might timestamp to exactly the spot the feedback was for. Checking the source of a quote could be done automatically in quote block.

Content editing tools are far more powerful when the structure and meaning of a piece of content is known from the beginning and not just layered on afterwards.

I could elaborate much more on all of this but this post is getting quite long so I’ll leave you with this:

As awkward as web development can be these days, I think the tides are turning and there is change in the wind. We’re moving toward something much better that can embrace the digital medium's true nature.

Right now we have to circumvent the document-centric nature of web development through tooling and component base frameworks like React (which is wonderful), but I’m optimistic these patterns will become more native to the web platform over time.

Some of the content creation tools of the future are being built right now using a blocks-centric approach so you can already experience the difference for yourself.

Here a few examples I’ve found built around the blocks concept that you can try today:

Notion: a block-based collaborative workspace for practically any type of content. Notion is probably the best example of the power of a block-based approach to collaborative content.

Pathwright Blocks: A block-based editor for interactive learning content. This is my company's first take on a block-based approach to learning-centric content.

Universe: An iOS app for creating web pages from your phone.

Qwilr: A block-based tool for creating sale pages, proposals and contracts.

Wordpress Gutenberg: The new Wordpress editor is betting heavily on a blocks-based approach to content publishing (a little awkwardly at this point IMO).

We’re only at the beginning of this shift. My hope is that we can all work together to build the web we’ve always wanted, one block at a time.

The moment a lecture turns to asking questions, exploring answers, critiquing, expanding, etc. is usually when the most engaged learning happens.

As social beings, we learn best in communities. The moment a lecture turns to asking questions, exploring answers, critiquing, expanding, etc. is usually when the most engaged learning happens. In fact, the best teachers use discussion to teach far more than they lecture.

I think education technology’s role now is to enable this type of rich discussion to happen anywhere and to make it frictionless. (This mirrors what the best tech does; it acts as a superpower or painkiller.)

Unfortunately most LMSs add friction to online discussion. Here’s the typical pattern in an LMS:

Student reviews the content of the assignment (a question, lecture, reading, etc.).

She clicks a link that takes them away from the content to a separate forum or discussion board.

Finally, she discusses what they just reviewed in that separate, new place.

Now how would that look in real life? Something like this . . .

“So do you think spreading the jelly to the edge really saved her life?”

“Stop! If you want to discuss this question, you’ll need to go into the discussion room across the hall.”

Everyone shuffles into the discussion room across the hall…

That’s absurd, right? It would completely break the flow of thought from content to discussion-based application. So why do we think that’s okay in an online environment?

At Pathwright, we don’t think that’s okay. That’s why we designed discussions to work in context, along with everything a student is learning.

This is about more than where discussion happens.

As I mentioned in my last rant about sidebars, interface design for online education is in its infancy. But one thing UI designers on education platforms can do better is to keep discussion at hand and in context.

At Pathwright, we don’t get everything right either. But we start by taking a design approach that begins with how great education happens in real life instead of taking the easier route of cobbling together existing design patterns like tacking on an online forum.

If you’d like to try out the difference for yourself, you can start creating an online course for free right now.

There are – and always will be – hundreds of features that we could build but haven't. If you’ve ever wondered about how we prioritize what to build, well…

Pathwright has many features already, and we launch new features or enhancements every 6 weeks. Even so, there are—and always will be—hundreds more features that we could build but haven't yet. 

If you’ve ever wondered about how we prioritize what to build, well . . . read on:

We love to hear suggestions for new features, so if you have one, please let us know. And just so you know what to expect, we'll respond in 1 of 3 ways:

1) That's on the roadmap. If your feature request is already on our roadmap, we'll confirm with two important qualifications: 

We usually can't confirm when a feature will be available (see "how we work").

Our roadmap is always subject to change (see "how we prioritize").

2) That's not on the roadmap. If we don't have plans to build it, we'll be up front about that.

3) That's an interesting suggestion! If we're not sure about it, we'll likely ask a few more questions and catalog the feature requests to consider later.

We work in 6-week cycles to complete 1-2 big features and a batch of smaller enhancements that are completable within 6 weeks.

We plan what to build next in between cycles. After each cycle, we have 2 planning weeks where we decide what roadmap features we’ll commit to for the next 6 weeks.

We pick which of the hundreds of features we could or should do at some point by . . . 

Selecting the highest impact features for all our educators that fit within our strategy and are within reach of our design and development resources during the next 6 weeks.

Prioritizing features that a partner funds and provides feedback and testing on when we can do so without impacting #1 significantly.

The primary users of Pathwright are the hundreds of thousands of students completing learning steps every day. None of these users pay us.

The primary users of Pathwright are the roughly 2 million learners completing steps every day. None of these users pay us.

Instead, they pay our customers who are made up of a much smaller group of school administrators, IT directors, and content creators from educational organizations of all sizes. (In fact, we have several customers who make way more money than we do.)

From a more conventional business perspective, it would make sense for us to prioritize designing primarily for the users who pay us first and then for the learners who don’t pay us, right?

That’s exactly what many of our competitors do, and it’s working for them, at least on business side of things. However, if you’ve ever used any of the more conventional LMSs (learning management systems) or marketing-oriented course platforms you’ve probably seen how this plays out: eventually, the product becomes 90% administrative actions, content authoring, and/or marketing tools, which is what 90% of the paying customers say they want. That leaves perhaps a measly 10% of features and polish focused on the actual learner experience (LX), which in contrast is where most 90% of the usage actually exists.

We take a different approach. Whenever we develop a new feature for Pathwright, we start with the learner experience first and then work our way back from there.

By starting with the learner experience we can:

Make the teacher’s job easier. Many of the jobs teachers have to do are not related to actually teaching. Reminding students about due dates, motivating them to catch up when they’re behind, and giving them a clear next step, are all things that Pathwright handles for teachers out of the box. Once curriculum is on Pathwright, a teacher can almost put it on “auto pilot” and focus their efforts on the more valuable things like one-on-one mentorship and feedback.

Reduce the support burden. We have schools with thousands of learners that have single digit support requests for an entire year. In fact we’ve had customers cancel their support system integrations with Pathwright simply because there wasn’t enough support to worry about. The LX design we put into our product saves a whole lot of time and money for our customers.

Avoid distorting the brand of our customers. It’s bizarre to me that many prestigious institutions and brands will use learning tools that look like they were designed a decade ago. Worse than that, the poor design often creates a negative first impression and a lot of frustration that gets transferred to the institution or teacher, not the software itself. At Pathwright we believe the learner experience should be clear, modern and beautiful so that it reflects the quality of teaching and guidance that our customers offer.

While the above approach may not be the most obvious business strategy, our team has been happy to grow slowly and steadily for years by putting the learner first every time.

There’s a commonality for designers, whether a product designer or a teacher designing a course. It’s this: Sometimes, even though you know what you want to accomplish, you don’t know how to get there.

This typically builds a lot of unnecessary pressure into the design process. Design isn’t ever easy, but there’s a simpler way to map the way forward if we’re willing to take a lesson from an unlikely source . . .

Bats use a technique called echolocation to map their surroundings at night when they can’t see. Basically, they make chirping sounds and listen for echoes off solid objects.

Because they receive so many echoes in response to their chirps, they have “to differentiate relevant information from signal clutter.” I learned that from this great SciToons video.

The video explains how bats avoid signal clutter like this:

To start, they send out low frequency chirps over a large range.

Then, listen for low intensity echoes from small prey (their goal).

Re-emit sound waves in the precise direction of their prey.

When both high and low frequency chirps return, the bat finds its prey and ignores all of the high intensity echoes.

I think bats can teach us something about designing a product or course here. When things seem hazy, it’s beneficial to spend more time listening to customers and learners and letting their feedback inform the next steps for your design.

Get feedback from a wide array of people.

Tune out the “signal clutter” of their feedback. (e.g. Feature add-ons that don’t align with the values/focus of the company.)

Articulate the most common, underlying problem that you can solve.

In the process, you may have to start ignoring the “high intensity” feedback in pursuit of the gems. Just because some feedback from a customer or learner is loudest in the group, doesn’t mean they speak on behalf of what’s best for the majority (e.g. A learner requesting a time change that’s an inconvenience for the rest of the class).

Whether you’re designing a product or you’re a teacher designing a course, you can use echolocation to map your way forward through the haze.

Naturally, we get asked why courses in Pathwright don’t include a sidebar. Fair question. I’ll share two reasons why I think it’s time for course designers to break up with their sidebars.

Why It’s Time for Course Designers to Break Up with 😈 Sidebars

If you’ve ever taken an online course, you’ve come across this interface design pattern. This sidebar + content pattern is used by almost all online course software:

Naturally, we get asked why courses in Pathwright don’t include a sidebar. Fair question. I’ll share two reasons why I think it’s time for course designers to break up with their sidebars.

Whenever we learn something new, our brain uses all our available mental energy on that task. We call this kind of mental energy “working memory.” Psychologists quantify how much working memory is required to learn a concept as “cognitive load.” Higher cognitive load = harder to learn. Here’s the formula:

Cognitive load = Innate load + Germane load +Extraneous load.

Now here’s what that means in plain english:

Innate load increases with the complexity of the concept itself. We could think of innate load as the “file size” for an app we’re installing into our brain (e.g., mixing cooking ingredients is small while deciphering a physics equation is big).

Germane load is how difficult it is to merge the new concept in with what we already know. It’s kind of like the processing power required to “install” that file into our brain.

Extraneous load is everything else distracting us from learning the concept.

As teachers, we can use smart course design techniques to subtract strain on our learners by reducing each load—that’s a good topic for another post. For now, here’s a very important fact to keep in mind about your online course:

Your learners are already in the most distracting place that’s ever existed: The Internet.

They’re only a tap, click, or notification away from everything other than what you’re teaching. Extraneous load is sky high.

With this in mind, Pathwright’s interface designers hunt down and kill extraneous load wherever it’s found. If it’s not essential, it gets axed. So even though course sidebars may be the cool kid everywhere else, they don’t make the cut here.

But isn’t that a little harsh? Can’t our learners just ignore the sidebar while they’re reading, watching, etc.? Sure they can, but that sidebar is still acting like the annoying kid whispering in the back of the class during a test. If your online course has a sidebar, it’s whispering to your learners:

😈 “Pssst. Is that quiz too hard right now? I got you. Why not check out something else for a little while?”

A lurking sidebar is an invitation to stop learning. It steals away your learner’s scarce cognitive load from your teaching. It’s a small thing, but the devil is in the details.

2) A course is more than organized content

“Dress for success.” “You are what you wear.” We know that how we dress says something about us to other people even when it’s unfair or inaccurate. Here’s what dressing up your course with a sidebar says about your course:

😈 “Let’s shop around. Check out this menu of shiny options over here. You can pick whatever you want, anytime.”

The problem here is that order matters in an effective course. Learning requires connecting past knowledge with new knowledge progressively. Give your learners an ever-present chance to skip around, and they’ll miss those essential connections.

😈 “It’s all about the content, baby. Just look at all this content I’ve got for you! It’s so good. I’m gonna keep it in your face all the time.”

But learning isn’t about content. It’s about absorbing, reflecting, practicing, observing, doing, reviewing, etc. — all actions connected in an intentionally designed sequence (or, ahem, a “path”). If an online course is dressed up like it’s all about the content, it’s easy to forget about following a path altogether.

Interface design for online education is in its infancy. We have a lot more work to do, and breaking up with course sidebars is just a small step.

Unfortunately, many good interface designers are slapping together popular UI patterns that work great for exploring an online store or blog without thinking about how those patterns impact learning.

At Pathwright, we don’t get everything right either. But we start by taking a design approach that begins with what’s best for you as a teacher and for your learners—not what’s expected or popular.

When I tell people about Pathwright, I often hear a version of “man, my university’s software sucks, we should use yours.”

Hating your LMS (Learning Management System) is not an uncommon sentiment. Google “[LMS name] sucks” for pretty much any mainstream LMS, and you’ll find outpourings of ire from students and teachers listing all the ways they’ve been screwed by these poorly designed platforms.

While I wish we could help students dealing with crappy LMSs, the problems with the Higher Ed-LMS market run deeper than poor software design.

Below are a few reason why bad LMSs end up at even the most prestigious institutions.

Most mainstream LMSs were designed with little thought given to the students’ experience. It doesn’t take a rocket scientist to figure this out (although it may take one to use the software). This seems like a bizarre choice from the outside since 80–90% of the users of an LMS are students, but it is intentional. Student experience isn’t a top priority to the big LMS vendors because the students are not the ones paying for the LMS!

LMSs are designed for the misinformed 💰people

Imagine a committee (when have committees ever made bad decisions?) composed of administrators, IT people, and the token student and/or teacher. For these committees, due diligence in LMS selection starts with a giant features list (one often found through a Google search or provided by fancy consultants). This list determines the “best” match for them.

I use quotes around “best” because the people helping them make this decision are often aggressive sales staff from LMS companies. As you might imagine, on the LMS side, this leads to an arms race of features— one that plays off the good intentions and fears of the committee.

The committee, with feature-FOMO, throws money at the problem. It’s the LMS that can check all the boxes on the list and that makes the most steakholders (this is a better way to spell it—you know it is)happy that takes the prize.

This leads to LMS software that is a rat’s nest of features that only “power users” can understand. Those features require conferences and time-sucking, on-site training for the primary users (students and teachers) to get any work done. The original committee might even regret their decision, but now they’re trapped by the contract—often a contract that lasts as long as 5 years (light-years in internet time). In the end, this is a losing game for everyone.

So how should universities pick an LMS? Start with the needs of your students and teachers. They are the primary users of the software and unless their needs are being met, you are making an expensive mistake. Below are a few tips for picking an LMS that will serve your school well:

Don’t fall into the money trap. Money won’t necessarily buy you the best software (repeat that 100 times). Also, signing a contract for any longer than one year makes no sense in the modern software world. Don’t do it!

Write a list of features you actually need by talking to the people who’ll actually use the software. You don’t need a pre-made check-sheet or consultant for this. Every university’s needs are different. This will take time and research (but you’re good at research!). The energy will be worth the mistakes it saves you from.

Remember, technology is just a tool. Software alone won’t turn bad teachers into good ones. And teachers are the key. Find software that helps them do their job better and then gets out of their way. They’re the ones helping students learn. And isn’t that why we’re all doing this anyway?

Thousands of teachers use Pathwright every day to design and teach courses to their team, class, or anyone in the world. If you’d like to design a course, we invite you to try out Pathwright for free. You’ve got nothing to lose!

Mark Johnson on Side Projects

We're Not Here to Change the World

Blocks, Not Pages, Are the Future Of the Web

LMS Forums Are Broken

What's On the Roadmap?

Why We Design for the Learner First

The Echolocation of Design

Designing on Purpose

Why Is Your School’s LMS So Bad?

Articles /

#Product Development

One killer email every other week.