Innovation Portfolio Management: Strategy Before Tools or Framework

Mike's Notes

Everything from Tristan Komer is deeply insightful. The same goes for Steve Blank, Alex Osterwalder, and Jason Cohen. I use them to figure out what to do.

Ajabbi aims to make money to provide a good service. All future profits will go to a yet-to-be-established non-profit foundation to fund open research, science communication, and support for the Pipi user community. Ajabbi has many moving parts: the Business Model Canvas and the Mission Model Canvas are useful tools.

Resources

References

  • The Real Startup Book (2nd edition, 2026) by Tristan Komer

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Kromatic
  • Home > Handbook > 

Last Updated

27/09/2026

Innovation Portfolio Management: Strategy Before Tools or Framework

By: Tristan Kromer
Kromatic: 09/07/2019

Tristan Kromer: Tristan Kromer is an innovation coach and the founder of Kromatic. He helps enterprise companies build innovation ecosystems and works with startups and intrapreneurs worldwide to create better products for real people. Editor of The Real Startup Book (2nd edition, 2026), a free field guide to 51 experiments for finding product/market fit. Speaker and longtime advocate for lean startup and innovation accounting methods, now focused on how AI changes (and does not change) the customer-discovery work that decides whether a startup lives.

Martin Kupp: Martin Kupp is an associate professor for entrepreneurship at ESCP Europe in Paris and a visiting professor at the ESMT European School of Management and Technology in Berlin. His work has appeared in California Management Review, MIT Sloan Management Review, Business Strategy Review, Info Journal, Financial Times, the Economist, the Economic Times of India and the Wall Street Journal.

...

Stop shopping for frameworks until you know what you're optimizing for

...

Quick Answer: An innovation portfolio without a clear strategy behind it is just innovation theatre. Before choosing any framework or tool — whether McKinsey’s Three Horizons, the Innovation Ambition Matrix, or Strategyzer’s Portfolio Map — we need to define our innovation strategy, understand our risk tolerance, and ensure alignment with senior leadership. Each tool is simply a lens that emphasizes different dimensions (resources, timing, risk, options), so as innovation managers, we should mix, match, or create our own frameworks optimized for the specific decisions we need to make.

...

Innovation portfolio by Martin Kupp & Tristan Kromer

Martin Kupp is an associate professor for entrepreneurship at ESCP Europe in Paris and a visiting professor at the ESMT European School of Management and Technology in Berlin. His work has appeared in California Management Review, MIT Sloan Management Review, Business Strategy Review, Info Journal, Financial Times, the Economist, the Economic Times of India and the Wall Street Journal.

Tristan Kromer works with innovation teams and leaders to create amazing products and build startup ecosystems. He has worked with companies from early stage startups with zero revenue to enterprise companies with >$1B USD revenue (Unilever, Swisscom, Salesforce, Fujitsu, LinkedIn). Newly appointed VPs of Innovation have been popping up in every company these days. While they are often given vague tasks such as “install the entrepreneurial mindset in the core business” and “look to the future,” managing the innovation portfolio is one of their most important responsibilities. To manage your innovation portfolio, you need to know what to optimize for.

What Is Innovation Portfolio Management?

Innovation Portfolio Management is the process of allocating finite resources into potentially infinite opportunity arenas and then into specific projects to capture a strategic objective. Decisions are not based on individual projects, but on an ideal mix of investments over arenas due to the uncertainty of innovation projects.

Why Bother? Isn’t Innovation Unpredictable?

While it is virtually impossible to predict the financial output of a highly transformational innovation at the very early stages, some projects are substantially less risky. There is a big difference between the transformational approach of moving financial transactions to blockchain and a core innovation of simply providing SMS updates on the status of the same financial transaction. No innovation is certain — they all represent different risk profiles. Just as a good retirement fund will spread its investment into high-, medium-, and low-risk categories, companies must decide where and how to allocate their resources in an ever-changing environment. By diversifying investments into many different bets instead of one big transformation project, managing our innovation portfolio can make the overall output more predictable. The primary goal of building innovation portfolios is to make the unpredictable more predictable.

It’s Not About the Tools

From the McKinsey Three Horizons model, to the Innovation Ambition approach used by Google, to the Strategyzer Innovation Portfolio, academics and consultancies alike are putting ever more tools on the market, each promising to solve the difficult task of managing innovation. A person with tools in his mindEven the word tool is confusing. What used to be a piece of paper presenting a framework or template is now called a tool by many companies and consultants. The innovation portfolio management software used to visualize all this information is now called a platform. The number of frameworks, tools, and platforms to manage innovation is growing almost as fast as the number of salespeople pitching them. 5 People with a laptop computer in their hands and their innovation manager.Before measuring the pros and cons of one tool versus another, an innovation manager needs to understand why they are building an innovation portfolio, and more importantly, what interdependencies need to be identified, monitored, and visualized. The right tool should not only provide a broad overview of the portfolio, but should also help the manager allocate resources, set priorities, and develop options for the future. In helping innovation managers visualize the portfolio, the right tool will force them to make decisions by making the need for decisions obvious. Ultimately it is up to the manager to say no to projects that would only distract the team and suck up resources. This requires strategy.

Prerequisites for Innovation Portfolio Tools

Before choosing their tools, a surgeon knows exactly what they have to do and what they want to achieve. No one wants a surgeon just cutting away without a clear objective. The same is true for innovation managers and CEOs.A surgeon asking his patient if he's using his foot a lot. Innovation Strategy The first prerequisite of any innovation portfolio is that there is an actual innovation strategy. What is promoted inside the company as a strategy is often no more than an empty slogan like “Be the most innovative.” A viable strategy will tell you which projects belong in the portfolio and which do not.

Vision

Similarly, slogans such as “Unlock the innovation potential of digital transformation” are equally useless. This simply tells the company that anything with a mobile app will get approval while worthwhile cost-cutting measures and routine operations are out of favor. The strategy must clearly state what trends are impacting the business environment, where the tipping points are, and where the company wishes to position itself in the future. Are there technological, social, economic, or other trends? Are they predictable linear trends, or do they represent exponential changes that will appear very slowly, but will quickly reach a tipping point? Where does the company need to be positioned when the tipping point happens to make use of the opportunity?

Risk Tolerance

Does the company have a high tolerance for risk, and does it seek to transform the way all businesses in the industry operate? Does it have a low tolerance for risk, or does it operate in a very slow-to-change environment? Companies must understand their own vision for the future and their tolerance for risk, and use them to define the scope of their innovation ambition. Many companies state lofty ambitions but focus their entire rewards and performance reviews system on quarterly goals. This leads to focus only on core innovation. But what is core innovation other than the acceptance of the status quo? Without clear alignment, any attempt at strategic innovation portfolio management is useless.

Strategic Alignment & Communication

Developing and aligning the strategy with action requires good communication between innovation managers and senior management. Senior managers should be actively involved in the development of the innovation-portfolio approach to help innovation departments not only fund projects to some level of success, but to prevent them from being orphaned when no one from the C-suite is interested in adopting the project into the core business. — a company may start with a clear portfolio strategy and only discover during execution a better, emergent strategy that requires a pivot. It is during this iterative portfolio management process that innovation managers and executives discover the insight needed to continuously improve their company’s innovation potential.

Portfolios Are About Interdependencies

The underlying premise of developing and using an innovation portfolio lies in balancing key aspects of the business: resources, time, risk, options, and last (but not least) profitability. Each of these elements can serve as the main perspective of a dedicated portfolio approach, or implicitly integrated into an alternate approach. In the early days of innovation portfolios, one of the central concerns was whether the company or business unit would have enough resources to support all of the innovation efforts, and a number of innovation portfolios were developed that tried to better understand or predict the resources involved in new product development. In 1992, Wheelwright and Clark developed a tool for mapping five types of development projects: derivative, breakthrough, platform, R&D, and alliances and partnerships. Their initial observation was that many companies initiate too many projects and ultimately lack the resources to follow through, leading to high failure rates. Companies would have to understand the nature of their projects to be able to balance the necessary resources for different types of innovation. One of the weaknesses of this approach is centered around the “going concern” principle. In other words, infrastructure is maintained, even if it might soon be obsolete — so investments in some platforms, alliances, and R&D capacity may also become obsolete. Accepting that some projects or capabilities will eventually be stopped makes it necessary to “overbook” the innovation pipeline, much like an airline overbooks seats. Some people are bound to cancel, so the seats are kept full. But what is the right amount of overbooking? This is where timing and throughput become critical. Two people can only afford to buy a half of a car.

Only four years later, in 1996, McKinsey consultants Baghai, Coley, and White published their “Three Horizons of Growth” model, which distinguishes between the current core business, emerging growth businesses, and options for future staircases. 

McKinsey's chart, The Three Horizons of Growth.

While the main focus here is on the timeline, there is also a link to risk in the sense that Horizon 1 is close to the existing core business and therefore less risky, while Horizons 2 and 3 lie farther away from the core business, and are therefore inherently more risky. And given that disruption is happening faster than ever, hoping that disruption is always 5-10 years away seems itself a risky proposition.

In 2012, Bansi Nagji and Geoff Tuff wrote about the Innovation Ambition Matrix to facilitate conversations about portfolio management based on risk and scale of ambition. The matrix is based on mathematician H. Igor Ansoff’s classic diagram to help companies allocate funds among growth initiatives, but it replaces Ansoff’s binary choices of product and market (old versus new) with a range of values. In addition to providing an overview of all innovation initiatives (which all portfolio approaches aim to do), this matrix focuses on the overall ambition for the company’s innovation portfolio and thus its appetite for risk.

Diagram of Innovation Ambition Matrix.

Although time may be an implicit consideration—transformational initiatives are more likely to be long-term — this approach clearly focuses on risk. Companies typically use such a risk matrix to allocate resources based on their ambition and risk tolerance.

A more recent approach, the 2017 Business Model Portfolio Map by Osterwalder and Pigneur, combines elements of the Innovation Ambition Matrix with a clear focus on business models. The Explore section on the left represents transformational projects that give way to more adjacent projects in the middle, while the Exploit section on the right represents the core or adjacencies that are ready for execution.

Explore and Exploit Business Model Portfolio Map. This model allows for adjacent projects to be compared to more transformational projects in terms of expected returns and “innovation risk,” which is another way of identifying the amount of validation a business model currently has. (An adjacent business model that only changes one element of the core business already has a high degree of validation.) so it’s not surprising that scholars like Rita McGrath focus on Arenas of opportunity. For McGrath, an arena is “a combination of a customer segment, an offer, and a place in which that offer is delivered.” Others may use different terms and talk about emerging trends or micro-battles, but McGrath’s main point is that these opportunities are transient and must be captured and exploited immediately. There is no sustainable, long-term advantage. As the consumer landscape shifts, companies can look for growing markets and invest more where the growth exists. McGrath developed a prescriptive portfolio approach based on understanding what type of options need to be developed in any given arena. For example, if a company is not well organized to address an arena and the market is unclear but the technology seems to already exist, then generating options by scouting existing companies is a viable path.

McGrath's portfolio.

Be Creative, Create Your Own!

The portfolio tool an innovation manager chooses serves as a lens through which they see the company’s innovation efforts, and will ultimately influence the decisions being made. So choosing the appropriate portfolio tool is a key part of the innovation manager’s job. This simple task can become increasingly complex as each executive demands that their viewpoint be included in the portfolio map. Some want to focus on a mix of projects leading to healthy returns in a certain timeframe, while others see disruption as more urgent and want to balance risk. New frameworks often attempt to combine one or more of these attributes.

The 4:3 Corporate Startup Portfolio framework by Dan Toma is exactly such a tool, combining the Three Horizons Model with the Innovation Ambition Matrix. Here, they have mapped out Alphabet’s innovation portfolio as an example.

Alphabet’s innovation portfolio.

Radar charts are another approach to combine several attributes, as they can compare different projects across multiple axes. Despite this flexibility, they tend to be difficult to use for a portfolio of more than a few dozen projects. They also don’t effectively show overall investment levels in any given area (although a cumulative radar chart can be used to this effect).

A radar chart.

A divided pie chart can roughly combine different Arenas of opportunity with either the Three Horizons Model or the Innovation Ambition Matrix. For example, the core business (Horizon 1) is the center of the pie chart while transformational (Horizon 3) is the outermost portion. The Arenas are represented by slices. This visually represents that there is more surface area in the outermost portion and thus more opportunity in transformational or Horizon Three projects. That’s simply due to the fact that there is more uncertainty and thus more possibilities. Those possibilities may collapse at some point, but the future generally has more options.

A pie chart.

There are additional options to represent investment by the size of the dot or the level of business model validation by color. But trying to make a visually impressive slideshow that represents everything at once can turn into a useless decision-making tool.


Pie Chart with Project Dots

Perhaps by now you’ve noticed that there is no right or wrong in portfolio management. You can and should create your own portfolio approach that takes your specific situation into account (or mix and match existing tools). You can choose what you want to focus on (resources, time, risk, options) and how you might integrate additional points of view.

Conclusion

Ultimately, innovation managers need to build frameworks that are useful for making decisions. They cannot be so complex that no one understands them, but they cannot be so simple as to remove rigorous thinking from the process. A good framework for building innovation portfolios should uncover where companies are overinvesting and where they are not investing. This transparency will allow executives to make coherent decisions on how to reallocate resources. Having multiple frameworks and dimensions to measure the portfolio is an absolute must. Managers should understand constraints and requirements in terms of resources, time frame, risk, and optionality, and how they fit into the overall strategy. Without that basis in strategy, any portfolio map is an academic waste of time at best, and innovation theatre at worst.

Lessons Learned:

  1. A portfolio framework without strategy is a performance, not a usable tool.
  2. Know what you are optimizing for (resources, timing, risk, options).
  3. Be creative: use existing tools, mix and match, and develop your own toolkit.

Special thanks to those who contributed early feedback to this post: Rob Aalders, Dan Toma, Franck Debane, Jorge Castellote, Esther Gons, Josh Berry, Chris Cannon, Megan Kennedy, Alexia van Schaardenburg.

Frequently Asked Questions

What is innovation portfolio management and why does it matter?

Innovation portfolio management is the process of allocating finite resources across opportunity arenas and specific projects to achieve strategic objectives. Rather than betting on individual projects, we diversify investments across different risk levels — much like a retirement fund — to make the inherently unpredictable nature of innovation more predictable and manageable overall.

What do I need before choosing an innovation portfolio tool?

Before selecting any tool, we need three prerequisites: a clearly defined innovation strategy (not just a slogan like “be the most innovative”), an honest understanding of our organization’s risk tolerance, and strong strategic alignment between innovation managers and senior leadership. Without these foundations, any portfolio map becomes innovation theatre rather than a useful decision-making instrument.

What are the main frameworks for innovation portfolio management?

Key frameworks include Wheelwright and Clark’s resource-based project mapping, McKinsey’s Three Horizons of Growth model (focused on time), Nagji and Tuff’s Innovation Ambition Matrix (focused on risk), Osterwalder’s Business Model Portfolio Map, and McGrath’s Arenas of opportunity approach. Each emphasizes different dimensions — resources, timing, risk, or options — and we can mix and match them to fit our specific context.

Should I create my own innovation portfolio framework?

Yes. There’s no single right answer in innovation portfolio management. We should feel empowered to combine existing tools or build custom approaches that reflect our specific strategic situation. The key is ensuring the framework helps uncover where we’re overinvesting or underinvesting, while remaining simple enough to drive actual decisions rather than just creating impressive slideshows.

Why shouldn’t I focus on tools first when managing an innovation portfolio?

Tools are only lenses through which we view innovation efforts — they shape the decisions we make. If we start with tools before understanding what we’re optimizing for (resources, timing, risk, or options) and how those interdependencies relate to our strategy, we risk making decisions based on whatever the tool happens to highlight rather than what actually matters strategically.

htmx 4.0.0 has been released!

Mike's Notes

More details from Carson about htmx 4.0.

Resources

References

  • Hypermedia Controls: From Feral to Formal

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/09/2026

htmx 4.0.0 has been released!

By: Carson Gross
HTMX: 28/08/2026

Carson Gross: I am a programmer comfortable with both front-end & back-end development. I currently teach at Montana State University.

My primary technical interests are hypermedia and programming languages, but I’m comfortable working in most areas of enterprise systems.

...

Release announcement, 2026-08-28.

htmx 4.0.0 Release

The htmx team is very happy to announce the release of htmx 4.0.0! This is the culmination of 8 months of work (plus a game) and we are very happy with the results.

The idea of htmx 4 started to germinate when I decided to create fixi and, in doing so, got more familiar with the fetch() API and async programming in JavaScript. (htmx had always used XMLHttpRequest due to backwards compatibility issues.)

One chance evening I was contacted by Christian, who had some interesting ideas around streaming HTML that got me thinking that moving the internals to fetch() would simplify things for him and for the library in general.

After a bit of work I managed to get Michael and Alex on board, and we were off to the races.

Development has been very smooth. We started a port of fixi + the htmx test suite. Over time, we rediscovered why htmx did many of the things that it did and moved our new implementation closer and closer to the old one. At this point the behavioral differences between 2.x and 4.x are relatively small and where they do diverge we have made explicit choices that we feel will put htmx-based applications in a good spot for being 100-year web services

Note that we are not marking 4.0 as latest in NPM because we do not want to force-upgrade users who are relying on non-versioned CDN URLs for htmx. Instead, 2.x will remain latest and the 4.0 line will remain next until some point in early 2027. The website, however, will reference 4.0.

Major Changes

As mentioned above, htmx 4, from a user’s viewpoint, is almost identical to htmx 2. There are three major changes:

  • Attribute inheritance is now explicit by default rather than implicit by default (this is the biggest upgrade item)
  • The htmx event names have been standardized & cleaned up. Some advanced users may need to change the events they listen for.
  • History support now does not use localStorage by default (which was a cause of many support headaches). Most people won’t notice this at all.

Internally, we migrated from XMLHttpRequest to fetch() but that should be transparent for most users of htmx.

Attribute Inheritance

In htmx 2 many attributes were “inherited” by default. This allows you to place attributes on parent elements and their behavior will apply to child elements. This behavior, which came from the intercooler.js days, was inspired by CSS and, unsurprisingly, worked out about the same as CSS: powerful but difficult to understand at times.

In htmx 4 attributes are not inherited unless you explicitly say so by adding an :inherited after the attribute name:

<!-- htmx 2 -->
<div hx-confirm="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>
<!-- htmx 4 -->
<div hx-confirm:inherited="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>

This will be the largest upgrade burden in migrating from htmx 2 to htmx 4. To make things easier, we have provided a command line tool to find places you need to mark as inherited.

Note that attributes like hx-disinherit, etc. are no longer required and should be removed.

Events

The events triggered by htmx 2 had grown organically over the life of the library and were not particularly well organized, making it difficult to know exactly which event was fired when.

In htmx 4, all events now follow htmx:phase:action[:sub-action]:

htmx 2 htmx 4
htmx:beforeRequest htmx:before:request
htmx:afterRequest htmx:after:request
htmx:beforeSwap htmx:before:swap
htmx:afterSwap htmx:after:swap
htmx:configRequest htmx:config:request

In addition, the following changes were made:

  • Most error events collapse into htmx:error. HTTP error responses fire htmx:response:error.
  • The htmx:xhr:* events are removed. htmx 4 uses fetch().
  • The htmx:validation:* events are removed in favor of native browser form validation.

The full table is in What’s New in htmx 4.

The command line upgrade checker flags old event names in hx-on attributes and in your JavaScript where it can find them.

History

History support has always been included in htmx, allowing you to implement back-button aware actions with simple attributes. In htmx 2, a cache in localStorage was used to snapshot pages for restoration. Unfortunately a large source of issues was that this snapshot could include DOM mutations by 3rd party JavaScript libraries. When the page was restored, those mutations remained but the underlying JavaScript logic was not.

htmx 4 does not cache pages in localStorage. On back navigation htmx re-fetches the page and swaps it into <body>, or into the [hx-history-elt] element if one is present. This allows 3rd party JavaScript libraries to “just work” in most cases and, with good request caching, is very fast.

If you want local caching instead, we now ship a very complete hx-history-cache extension that restores history from sessionStorage and is designed to integrate well with scripting solutions like Alpine.js, etc.

New Features

There are two big new features in htmx 4, both of which we are really excited about:

Morph Swaps

We now support morphing swaps out of the box with htmx. I created idiomorph and nearly included it in htmx 2.x but decided against it. In htmx 4, Michael has done great work improving on that algorithm and integrating it seamlessly into htmx.

<hx-partial>

Another major new feature is the <hx-partial> tag. This tag is similar to out-of-band swaps, but is much clearer when you want to do something beyond just replacing a single element with a new version of itself:

<hx-partial hx-target="#messages" hx-swap="beforeend">
    <div>New message</div>
</hx-partial>
<hx-partial hx-target="#count">
    <span>5</span>
</hx-partial>

Extensions

Much of the excitement in htmx 4 is in the extensions. Switching to fetch() internally let us rethink how extensions can and should work, and sparked the creation (and recreation) of many new extensions, for example:

  • hx-preload - preload content (e.g. on mouseover) to speed requests up
  • hx-download - native, fetch-based file downloads
  • hx-alpine-compat - smooths over compatibility issues between htmx and Alpine.js
  • hx-history-cache - caches history in sessionStorage, provides Alpine.js compatibility

Additionally, there are three new or updated streaming HTML extensions:

  • hx-sse streams over text/event-stream.
  • hx-ws streams and sends over WebSockets.
  • hx-multipart streams over multipart/mixed

Finally, we decided it was time to try our hand at our own small front-end scripting solution that tightly integrates with htmx. hx-live is inspired by Alpine.js, jQuery and hyperscript, and makes front end scripting pleasant and fun. It even supports what we are calling DOM-based, HATEOAS-friendly reactivity.

There is a new htmax.js bundle in the distribution which packages htmx with the most popular of these in a single file if you don’t want to think about which ones you want to pick.

Upgrading

For a complete upgrade guide see What’s New in htmx 4.

As mentioned earlier, we are providing an upgrade tool to help you:

$ npx htmx.org@4.0.0 upgrade-check -- ./templates

File extensions: .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb, .hbs
Use --ext to add more (e.g. --ext .vue --ext .svelte)

Scanning 1 file(s)...

Found 8 issue(s) in 1 of 1 file(s).

  • templates/index.html:1: [inheritance] hx-headers needs :inherited suffix (descendant on line 3 has hx-delete) (this looks like a CSRF token; without :inherited the header does not reach child elements and the server rejects the request)
  • templates/index.html:2: [inheritance] hx-target needs :inherited suffix (descendant on line 3 has hx-delete)
  • templates/index.html:2: [inheritance] hx-confirm needs :inherited suffix (descendant on line 3 has hx-delete)
  • templates/index.html:3: [renamed-attr] hx-disable -> rename to hx-ignore (hx-disable now means 'disable during request')
  • templates/index.html:4: [removed-attr] hx-vars is removed -> use hx-vals with js: prefix
  • templates/index.html:4: [removed-attr] hx-prompt is removed -> load the hx-prompt extension to keep the same syntax
  • templates/index.html:9: [old-event] old event name "htmx:afterRequest" -> "htmx:after:request"
  • templates/index.html:9: [old-api] htmx.addClass() is removed -> use element.classList.add()

We are also shipping an agent skill to assist in upgrading

Installing

htmx 4.0 can be installed via a package manager referencing version 4.0.0, or can be linked via a CDN:

<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>

or Downloaded

LLMs

Like it or not, a lot of people are using LLMs and we are providing the following skills files for LLMs:

  • htmx-guidance - core htmx skills for developing with htmx 4
  • htmx-debugging - diagnosing htmx issues during dev
  • htmx-extension-authoring - writing and debugging htmx 4 extensions
  • htmx-upgrade-from-htmx2 - migrating a codebase from htmx 2.x to 4.x

(Let’s leave aside if releasing a new version of a library in the LLM era is a good or bad thing!)

Conclusion

We hope you enjoy htmx 4. htmx 2 will continue to be supported indefinitely so don’t feel any pressure to upgrade.

I’d like to thank the following people for all their help with this release:

  • Michael West - Incredible teammate & grug-brained developer
  • Christian Tanul - Inspired htmx 4 & led the streaming & live extensions
  • Alex Petros - For keeping the ship on an even keel
  • Stephen Mitchell - The genius behind the game
  • Stu Kennedy - Our WebSockets expert
  • André Ahlert Jr. - Providing IDE & Editor Support
  • Dien Hoa Truong - For kicking the tires on early htmx 4 and helping fix many bugs

Upgrade Music

Wouldn’t be an htmx update without upgrade music:

htmx 4.0: a Fetch-Based Rewrite, Built-In Morphing Swaps, and Explicit Attribute Inheritance

Mike's Notes

Excellent news.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ
  • Home > Handbook > 

Last Updated

25/09/2026

htmx 4.0: a Fetch-Based Rewrite, Built-In Morphing Swaps, and Explicit Attribute Inheritance

By: Daniel Curtis
InfoQ: 18/09/2026

Daniel Curtis: Daniel Curtis is a UI Development Manager at Griffiths Waite, a software consultancy based in Birmingham, UK. He leads front-end engineering efforts with a strong focus on delivering innovative enterprise solutions using TypeScript across the stack. Daniel is passionate about modern web architecture, developer experience, and the use of AI to both support software delivery and solve real customer problems within products.

...

The htmx team has released htmx 4.0.0, the first major version of the hypermedia library since 2.0 arrived in 2024, landing after eight months of work and skipping version 3 entirely. Creator Carson Gross, who had promised there would never be an htmx 3, summed up the leap to InfoWorld in a one word quote: "Oops."

htmx has swapped its long serving XMLHttpRequest transport for the modern fetch() API, a rewrite that unlocks native streaming while keeping the script around 14KB. For most developers the familiar hx-get and hx-post attributes behave exactly as before, but the move enables the two features the team is most excited about, which is built in morphing swaps powered by idiomorph, which preserve DOM state such as input focus during updates, and a new hx-partial tag that lets one response cleanly update several targets, a tidier take on out of band swaps.

Attribute inheritance is now explicit, so parent attributes reach children only when marked with an :inherited suffix:

<div hx-confirm:inherited="Are you sure?">
 <button hx-delete="/item/1">Delete</button>
</div>

A detailed DEV Community write up warns this is the trap to watch, because an hx-headers attribute passing a CSRF token to child elements silently stops working without :inherited and the server begins rejecting requests with a 403 while nothing looks broken.

Event names have also been standardised to a htmx:phase:action pattern, so htmx:afterRequest becomes htmx:after:request, and history no longer snapshots the DOM into localStorage, instead refetching pages so third party scripts just work.

A Hacker News thread passed 700 points, with developers praising the Go, SQLite and htmx stack and how well AI assistants handle it, one noting that Claude "understands it and does it well", and the r/htmx release post drew over 300 upvotes.

Elsewhere a .NET and Angular developer argued htmx forces you to mix presentation with business logic and another agreed and said their team is moving back to React.

htmx 4.0 ships under npm's next tag rather than latest, so nobody on an unversioned CDN link is force upgraded, and 2.x stays supported indefinitely. The team provides a command line checker that flags inheritance issues, renamed attributes and old events:

npx htmx.org@4.0.0 upgrade-check -- ./templates

Beyond inheritance changes, there is also a new 60 second request timeout and a number of attribute renames, such as hx-disable becoming hx-ignore. These changes need applying with care. A full What's New in htmx 4 guide is available, and dedicated skills files for LLM assisted upgrades.

htmx is an open source library that adds AJAX, CSS transitions, WebSockets and server sent events directly to HTML through attributes, letting developers build modern interfaces with minimal JavaScript. It remains a flagship of the hypermedia movement, popular with Django, Go and Rails backends where server rendered HTML meets low client side complexity.

Accordion Icons: Which Signifiers Work Best?

Mike's Notes

Excellent NN Group article on Accordion Icons: What works and what doesn't.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NN/g Newsletter
  • Home > Handbook > 

Last Updated

24/09/2026

Accordion Icons: Which Signifiers Work Best?

By: Page Laubheimer and Raluca Budiu
NN/g Newsletter: 23/08/2020

Page Laubheimer: Page Laubheimer is a former NN/G employee who worked on research, teaching, leadership, and design thought leadership. His expertise focused on web applications, AI, and projects in complex domains. His many research findings and recommendations were also informed by his background in library and information science, and his work often involved information architecture, navigation design, taxonomy construction, and ontology management.

Raluca Budiu: Raluca Budiu is Senior Director, Data Strategy, at Nielsen Norman Group, where she uses her data-analysis expertise to drive strategic decisions. She also serves as editor for the articles published on NNgroup.com. Raluca has coauthored many NN/g reports, as well as the book Mobile Usability. She holds a Ph.D. from Carnegie Mellon University.

...

Summary:

The caret icon most clearly indicated to users that it would open an accordion in place, rather than linking directly to a new page.

For good reasons, accordions are a popular UI element today: on mobile, they are an essential tool because they collapse content and make page length manageable, but even on desktop, they mitigate visual complexity and allow users to focus on the content most relevant for the task at hand (and are particularly appropriate in complex applications).

A question that is often asked in both our Mobile UX and Application Design classes is: which icon should we use to best signal that content will expand in place? In other words, what’s the best signifier for accordions?

We decided to investigate this question as part of a bigger study of navigation and subnavigation on mobile. We looked at several possible icons as signifiers for accordions:

  • Caret (or downward-facing arrow)
  • Plus
  • Right-facing arrow
  • No icon at all

There are some subtle differences in what these icons are commonly used to represent — while the caret and plus icons are typically meant to indicate that an accordion will open, designers have used the right-facing arrow icon to signal two different actions: either staying on the same page and expanding content, or visiting a different page. Also, after expansion, the caret will typically twist (maybe in a nice quick animation), and a plus sign will turn into a minus, to become a signifier for the reverse action of collapsing the newly expanded content.

Jennair: Accordion signaled by caret icon

Bolé Road Textiles: accordion signaled by plus icon

Ferrari: accordion signaled by arrow icon

Braun: accordion with no signifier icon

We performed a quantitative study to find out which of these icons is the most effective at signaling that it will open an accordion.

In This Article:

  • Methodology
  • Where Participants Tap
  • What Participants Expect to Happen
  • Key Findings
  • Design Recommendations
  • Summary

Methodology

Materials. We decided to study the accordions in the context of mobile navigation so we created 11 prototypes of mobile websites, each in a different type of industry — clothing ecommerce, big-box retail, auto parts, finance, news, local government, higher education, DIY home projects, consumer-goods reviews, healthcare, and travel. The prototypes were not interactive; they were simple mockups with the menu already open and a list of categories visible on the screen, to ensure that we were only measuring the interaction with the accordions, as opposed to users’ efforts to locate the menus, look at homepage content, and so forth.

For each prototype, we created a task that involved finding information in one of the accordions visible in the prototype. For example, on a prototype of a consumer-goods review website, the task was “Find reviews of dishwashers.”

We also created 5 different variations for each prototype; each variation used one of 4 possible icons (an arrow, a caret, a plus, a foil) or no icon. We created a foil icon (that had not been used before for accordions) in order to see whether the type of icon mattered at all or the presence of an icon next to the accordion name was enough to signal an accordion (but the icon itself did not matter).

The icons tested in this study included a downward-facing caret, a right-facing arrow, a plus, a nonsense foil icon (used as a control for comparison), or a blank space. The icons were randomly assigned for each task, meaning that participants saw a random assortment and order of these five icons.

An example of one of the prototypes, shown in all 5 icon variations

We placed the accordion icon to the right of its associated label, close to the edge of the screen and right aligned. (We acknowledge that another possible position is to the left of the label — our results may not generalize to that placement.)

As the length of the text labels might impact where users look or click, we ensured that label lengths in each prototype were distributed equally and that the “correct” answer for each task (i.e. the menu option that was likely to be chosen by users) was of a different length in each prototype. 

We also ran several pilot studies to ensure that the task success rate was high (over 90%) and that people would be able to easily identify the “correct” menu category that had to be selected in order to complete each task. After each pilot study we refined the task phrasing and labels in the menu. Thus, effectively, we ran several usability studies on our prototypes’ information architecture before we collected the quantitative data. This process ensured that figuring out the right category was relatively trivial for most participants — as our study goal was to test the accordion signifiers, not the difficulty of finding the information in the tasks we gave users.

Participants. Our study had 136 participants.  All participants saw instances of all the different icons (in different prototypes, and in different order).

Procedure. The test was conducted on UserZoom as a series of first-click tasks, administered on mobile devices. All participants were shown one version of each of the 11 prototypes and the associated task in a random order. After the participants indicated where they would tap to find the answer, they had to answer a multiple-choice question asking what they expected to happen (going directly to a new page, seeing additional menu options on the same page, or something else). 

We collected data on:

  • Tap location: Where the participant tapped (directly on the text label, directly on the icon, in the space in-between the label and the icon, or anywhere else on the prototype)
  • Participants’ expectations: The response to the post-task question about expectations (going directly to a new page, seeing an additional list of links on the same page, or something else)

Where Participants Tap

Taps outside the area associated with the accordion were relatively few (5–8%), and most taps fell either on the label or on the icon associated with the accordions (and not on the space in between the two).

Participants were equally likely to tap on either the text label or the icon, except for the caret icon, where there was a statistically significant tendency to tap on the icon over the text label. When no icon was present, users were much more likely to tap on the text label than the empty space where an icon would normally be.

An ANOVA on the data for when users tapped on the text label found a significant effect of icon type both when participants or prototypes were treated as the random factor. Pairwise contrasts indicated that the no-icon condition was significantly different than all other conditions.  In particular, there was a higher chance to tap on the label when no icon was present — a finding that is not surprising at all since the “icon area” was just empty space in this condition (we just tracked if people tapped on the place where an icon would normally be), but an important reminder that users typically choose to interact with obvious signifiers.

For none of the icon conditions was there a statistically significant tendency to tap on the icon more than on the label except for the caret (p<0.01) —  in other words, when the accordion was signaled by a caret, people tended to tap more on the icon than on the label. For all other icons (arrow, foil, plus), there was no statistically significant preference for the icon.

What Participants Expect to Happen

To analyze the responses to the post-task question (regarding expectations to stay on the page) we defined the new-page expectation as a binary variable quantifying  whether participants expected to stay on the same page (0) or go to a new page (1). A rate of over 50% for a particular signifier indicates that overall people expected to go to a new page. For an accordion, where we want to convey that the page won’t change, the rate should ideally be under 50%.

None of the standard-icon rates were significantly different from 50%, indicating that there was no strong expectation related to them — people did not necessarily expect to stay on the page or leave the page. With the foil and the no-icon conditions, however, there was a significant expectation that people will leave the page.

For the standard signifiers (caret, plus, and arrow), there was no strong expectation to leave the page (as the rate of new-page expectation is not significantly different than 50%, p >0.05).  Among all the standard signifiers, the caret has a significantly stronger expectation to stay on the page than the foil (p<0.05) or the no-icon condition (p <0.05) and the plus is significantly better than the foil (p<0.05), but not than the no-icon condition. The arrow is not statistically different than the foil or no-icon conditions, suggesting that this icon should not be used for accordions.

Key Findings

Our hypothesis was that having no icon would cause users to expect that tapping on the menu item would take them directly to a new page, and this hypothesis held up in our study. Likewise, the foil icon was presumed to not have any association for users with opening an accordion, and this also held up.

Then, we compared users’ reported expectations of the caret, plus, and arrow icons to the foil or no icon, as a test of whether or not they were superior signifiers for an accordion. We also looked at whether people tend to tap the label or the icon for these different signifiers, under the assumption that, if indeed there is a strong tendency to tap only on one of them, we could, perhaps, separate the functionality of the two (a la split buttons).

  • For accordion patterns, people tend to tap fairly equally on the icon and on the label for most standard icons. The only exception is the caret, where people tend to tap somewhat more on the icon, but still 29% of the taps fall on the label. This suggests it’s not safe to use split buttons for accordions — where the text label links directly to a landing page, but the icon opens the accordion.
  • Making up new icons for accordion signifiers or using no signifiers at all is not a good idea as they violate users’ expectations (which are that they will be taken to a new page).
  • None of the standard signifiers have a strong association with staying on the page. That being said:
    • Using a caret is definitely better than using no icon at all or a random icon in terms of conveying the expectation to stay on the page (and open an accordion).
    • Using an arrow or a plus is not better than using no signifier at all.

  • When no icon was present, users tended to tap on the text label, rather than the empty space in that row. While an obvious finding, this is more evidence that users tend to interact with strong, clear signifiers.
  • Interestingly, using a right-facing arrow icon (as opposed to a plus or caret) was NOT significantly associated with an expectation of going directly to a new page.  While many designers might think that an arrow icon implies “go directly to a page” whereas the same icon pointing down implies “open an accordion here on the page” that was not supported in our data.

Design Recommendations

  • If using accordions in your mobile menus, the caret appears to be the safest icon choice.
  • Do not have icons and text labels link to different actions (i.e. label directly to page, icon opening an accordion).  Our study findings further support our previous recommendations that you should not use split buttons for accordions. Our study showed that users tapped fairly equally on both the text label and the icon and did not expect them to do different things.
  • Decide if your menu items will either open a submenu accordion or go directly to a category-overview page.  If you choose to have your menu items link directly to a landing page, do not use a right-aligned icon.

Summary

Users tend to click fairly equally on both the accordion icon and the accordion label, so avoid dissociating those by assigning them different functionalities.  Use a caret icon to designate an accordion, whether on desktop or mobile — our study found that of the standard set of icons used in this context, only the caret performed better than either no icon or a nonsense icon at indicating that than it was an accordion.

Ajabbi mission sign-up

Mike's Notes

While visiting Christchurch recently, I met with people who would like to help with Ajabbi's mission in the future. People in other countries have also reached out.

If this is you, please use this Google Form as a simple first step. Then we'll contact you individually by email to set up a follow-up chat in person, by phone, or by video call in English.

If you want to get free early access to Pipi to help with testing and give feedback, go here.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > Ajabbi > Mission

Last Updated

23/09/2026

Ajabbi mission sign-up

By: Mike Peters
On a Sandy Beach: 22/09/2026

Mike invented and designed Pipi and founded Ajabbi.

Ajabbi is a bootstrapped, mission-led organisation with no investors, with all future profits going to a yet-to-be-established non-profit foundation to fund open research, science communication and support open source and the Pipi user community.

Pipi is designed to help make massive enterprise systems for socially useful critical infrastructure self-managing. Over time, it will extend to many platforms, in many human languages and writing systems.

There will be many ways to participate in Ajabbi, including but not limited to;

  • Volunteers
  • Visitors
  • Contractors
  • Interns
  • Staff
  • Research grantees

Ajabbi will need all kinds of people, with many different skills, from many countries. Pipi systems are novel, non-LLM, and we expect to solve unexpected hard problems by working as a team and just figuring it out. The work will be important, very difficult and interesting.

To register your interest, use the Google Form below. You can share this link with others. Everyone is welcome.