Everything to Gain from Thriving Southland

Mike's Notes

My notes from an all-day workshop organised for farmers, which I attended yesterday.

Resources

• https://www.thrivingsouthland.co.nz/everything-to-gain/
• https://www.blog.ajabbi.com/2025/11/workspaces-for-agriculture.html
• https://www.blog.ajabbi.com/2026/02/waimumu-field-days-background-to-ajabbi.html
• https://www.blog.ajabbi.com/2026/04/agents.html

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > Thriving Southland
• Home > Handbook > 

Last Updated

08/05/2026

Everything to Gain from Thriving Southland

By: Mike Peters

On a Sandy Beach: 07/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I attended the all-day workshop "Everything to Gain" on 6 May 2026, held at the Ascot Park Hotel in Invercargill, New Zealand. Organised by Thriving Southland.

It was a day full of informative speakers on the global agricultural market, attended mainly by working farmers.

I learned a great deal from the objective data presented and from chatting with the farmers at our table. Hard times are ahead.

Thinking visually while listening

I mentally ran the Workspaces for Agriculture, testing the model assumptions against what I learned.

I also did a brain dump by creating 12 A4 drawings and solving the problem with variables in the current Pipi Core buildout.

Lessons I learned

Shifting a working Pipi 9 from a laptop to a data centre led to several unexpected consequences.

I underestimated the impact of

• The naming, generation, and pub/sub of variables.
• Host environment.
• OS
• Java
• CFML Engine
• Needing to turn Pipi into 4 separate role-based editions, which then exposed some hidden problems.
• Adding a nest structure between Pipi and the host environment.
• The impact of all of the above when each engine can pub/sub and be both deterministic and probabilistic, with multiple copies of each engine, and many in different locations.
• Path length constraint in Windows vs Linux.

This very hard problem can only be solved by running a simulation of all 18 engines in parallel and watching the interaction. Lots of feedback loops.

Yesterday, a lot of progress was made visually, answering these questions. The variable-naming convention used for 12 months has held up, despite some earlier false flags.

• More work is needed on variable distribution rules (messaging) for automation.
• Global
• Local
• etc

Today I did another 8 drawings. They were of the Messaging Engine (msg) routing variables between the engines in both deterministic and probabilistic modes.

I will sleep on all this for a few days to see if anything else pops out, then commit it to code.

Tim Cook is Leaving. Good.

Mike's Notes

The key takeaway of this copied article.

"make products you’d be proud to use yourself."

Resources

• https://routerjockey.com/tim-cook-is-leaving-good/
• https://routerjockey.com/tools/
• https://www.blog.ajabbi.com/2026/02/my-fitbit-buzzed-and-i-understood.html
• https://www.blog.ajabbi.com/2025/03/the-rot-economy.html
• https://www.blog.ajabbi.com/2025/02/enshittification-tarpits-and-other.html

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
• Home > Handbook > 

Last Updated

05/05/2026

Tim Cook is Leaving. Good.

By: Tony Mattke 

Router Jockey: 27/04/2026

I’m Anthony Mattke, aka Tony. I’m a network engineer, infrastructure architect, and general-purpose technology geek located amidst the endless cornfields of north central Indiana. I’m a husband and father, and I hope to have superpowers one day. Seriously.

Your AirPods just connected to the wrong device. Again.

iMessage is taking twenty minutes to sync a message between your laptop and your phone sitting six inches apart. HomeKit forgot the kitchen lightbulb exists, and will remember it again in three hours like nothing happened. System Settings, which used to be one of the cleanest preferences UIs ever shipped, now feels like a bad Electron app pretending to be macOS.

These aren’t dramatic failures. They’re worse than dramatic failures. They’re daily proof that somewhere along the way, Apple stopped caring about the texture of using its own products.

This is Apple in 2026. And this is the Apple that Tim Cook built.

Cook announced his departure last week, and most of the coverage you’ll see is going to be a victory lap. A lot of it is earned. Apple is a three-trillion-dollar company. Services revenue is at record highs. Apple Silicon is one of the great hardware bets of the last decade. He took a company already at the top of its industry and made it bigger than the GDP of most countries.

So why am I glad he’s leaving? Because somewhere in all that growth, Apple stopped making products it was proud of.

What Steve Actually Said

There’s a passage in Walter Isaacson’s biography of Steve Jobs that gets quoted less than the famous ones. Jobs talked about how great companies die, and his theory was that the rot has nothing to do with competition or markets or innovation cycles. The rot starts when the salespeople end up running the company.

He named names. He pointed at IBM under John Akers. He pointed at Microsoft under Ballmer. He even pointed at the Sculley era of his own Apple as the cautionary tale. The phrase Jobs kept circling back to was that the people running these companies eventually “have no conception of a good product versus a bad product.” They can’t tell the difference. They can run a supply chain better than anyone alive, but they couldn’t tell you whether the radius on a button looks right.

That’s not a small criticism. That’s the founder of Apple, on the record, naming the disease and warning the company against catching it.

Then, in 2011, Apple promoted its head of operations to CEO.

I’m not saying Cook was a bad pick at the time. He was the right person to keep the trains running while everyone caught their breath after losing Steve. But fifteen years later it’s worth asking the question Steve himself would have asked. What kind of products are we shipping now?

The Tenet Cook Forgot

Of all the things Steve Jobs believed about Apple, one of them stands out as the most quietly violated under Cook: make products you’d be proud to use yourself.

Not just sell. Not just ship. Use. Sit down at the Mac on a Tuesday night, put your AirPods in, fire off a Message, set up a HomeKit automation, and feel proud of every single one of those things working the way you wanted them to.

Today’s Apple doesn’t pass that test. And the failures aren’t dramatic ones. They’re the small, persistent, daily-friction kind that the founder used to personally drive teams to fix.

You know the list. The 2022 System Settings redesign managed to take a perfectly usable preferences app and ship it as something worse, then leave it that way for three OS releases and counting. Notifications have been re-architected three times in five years and still work inconsistently across iOS, iPadOS, and macOS. Mail rules have been broken since the Obama administration. The Photos library will quietly drop items, sync ghosts, and offer no diagnostics when something goes wrong. HomeKit loses devices the way a child loses socks. Spotlight returns stale results and pauses for seconds at a time on hardware that should make it instant.

Each one of these, on its own, is just a bug. Together, they’re a culture.

They survive because they don’t move metrics. They don’t reduce revenue. They don’t show up in the quarterly. But they’re exactly the kind of paper-cuts that would have annoyed Steve at 9pm on a Tuesday, and they would have been fixed by Wednesday morning.

That’s the difference. Steve used the products. Cook signs the budget.

Before Someone Says This Is Just Nostalgia

Yes, I know. Apple under Steve wasn’t perfect. MobileMe happened. Antennagate happened. The hockey-puck mouse happened. Plenty of bad calls happened. Nobody is arguing for some flawless golden age that didn’t actually exist.

The argument is about standards, not perfection. Old Apple shipped mistakes too, and it visibly hated them. The bad release, the launch-day disaster, the public mea culpa, the engineering re-org. The whole company would visibly recoil and try to do better.

Today’s Apple ships friction and treats it like background radiation. That’s not the same thing.

The Counter Argument (-ish)

Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras and better screens and better batteries. The hardware story under Cook is strong, and pretending otherwise would be silly.

But here’s the thing about hardware. You can grow it through operational discipline. You can squeeze a process node, you can negotiate a better deal with TSMC, you can lean on a thousand suppliers until they bend. That’s exactly the kind of work Cook is good at, and it’s exactly the kind of work that doesn’t require a product person at the top.

Software is different. Software lives or dies on judgment calls a thousand times a day. Should this preference go in this menu or that one? Should this notification fire silently or with a sound? Should this Bluetooth handoff be aggressive or conservative? Those decisions can’t be operationally optimized. They have to be made by someone who actually uses the thing and has an opinion. Cook is famously not that person.

And the rot follows that exact line. Apple’s hardware reviews are still glowing. Apple’s software reviews… are not. The number of “I’m switching to Linux” or “I’m switching back to Windows” essays from longtime Apple loyalists has gone from a trickle to something that should worry someone on Apple Park’s executive row.

The grumbling isn’t about features. It’s about the texture of using the products. Which is the thing Steve cared about most, and Cook seemingly cares about least.

The Era of *aaS

There’s a related thread here. Cook’s Apple has gradually rebuilt itself as a services company that happens to make hardware. iCloud subscriptions. Apple Music. Apple TV+. Apple Arcade. Apple Fitness+. Apple News+. Apple One. AppleCare+ tiers within tiers. The recurring monthly nudges that show up in apps that used to be one-and-done.

There’s a real argument that this was a defensive move, and it worked. The Services line is now bigger than the GDP of small nations. But there’s also a reason long-time Apple users are uneasy. The company that ran the iPod silhouette ad is now the company that nudges you to try Apple Fitness+ when you open the Watch app for an unrelated reason. The texture changed. The thing that made Apple feel different is, slowly, less different.

And here’s where it loops back to the bug list. When recurring revenue becomes the thing the company optimizes for, the tolerance for friction goes up. A slightly annoying subscription upsell is acceptable as long as the funnel still works. A weird Settings menu is acceptable as long as nobody actually leaves. That’s how product standards quietly erode. Not through one dramatic bad decision, but through a thousand tolerated ones.

Was that the right business call? Maybe. Was it the right product call? Different question. And it’s the question Steve would have asked.

Enter John Ternus

The honest read on Cook’s tenure: he was the right operations CEO for the post-Steve transition, and he stayed long enough to also become the wrong product CEO for the post-iPhone era. That’s not a damning legacy. It’s just a long career with two halves that needed different people.

So who’s getting handed the keys? John Ternus.

If you needed to pick someone inside Apple to course-correct away from the operations-CEO failure mode, Ternus is the right person on paper. He’s been SVP of Hardware Engineering for years. He came up working on the Mac, ran iPad development, and was a key player in the Apple Silicon transition. He’s the one Apple keeps putting on the keynote stage to talk about new hardware. By any honest read, he’s an engineer and a product person, not a salesperson, not an operator. That’s the pick Steve would have nodded at.

BUT…

The piece I just spent a thousand words complaining about isn’t a hardware problem. Apple’s hardware under Cook has been excellent. The thing that rotted is the software experience. The bug list. And Ternus, for all his strengths, has spent his career running hardware, not software. Whether his product instincts translate into fixing the software stack is the open question of his tenure.

The hopeful read is that an engineer-CEO will demand engineering rigor across the whole company, including from the software org that’s been getting away with shipping half-baked work for a decade. The cynical read is that hardware engineers and software engineers are different cultures, and you can lead one without knowing how to fix the other.

I’m cautiously in the hopeful camp. The fact that Apple chose a builder over another finance type or another operations type says they noticed the thing this article is about. That’s not nothing.

But the proof is going to be in the next macOS release. Does System Settings get rebuilt? Does AirPods routing finally stabilize? Does Mail get a rewrite? Do notifications get a coherent strategy across all four operating systems? If yes, this was the right pick. If we get another year of shiny new features with five new bugs and zero fixes for the old ones, then Apple just rearranged the deck chairs.

Because that’s what made Apple. The rest is supply chain.

So yes. Tim Cook is leaving. Good. And John Ternus is taking the keys at exactly the moment Apple needs to remember what it was supposed to be.

Realworld AI Coding Agent Exercise

Mike's Notes

An open-source version of Virtuoso will be installed in the data centre to explore possibilities. Kingsley Uyi Idehen's articles are all fascinating. I first came across him via the Ontology Forum.

The original post on LinkedIn has more links.

Resources

• https://www.linkedin.com/pulse/realworld-ai-coding-agent-exercise-kingsley-uyi-idehen-pxdic/
• http://www.openlinksw.com/
• https://www.openlinksw.com/data/screencasts/new-fct-demo-1.mp4
• https://linkeddata.uriburner.com/fct/facet.vsp
• https://www.linkedin.com/pulse/building-llm-wikis-turn-any-document-url-living-queryable-idehen-u4zue/

References

• Reference

Repository

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

Last Updated

08/04/2026

Realworld AI Coding Agent Exercise

By: Kingsley Uyi Idehen

LinkedIn: 07/02/2026

Founder & CEO at OpenLink Software | Driving GenAI-Based AI Agents | Harmonising Disparate Data Spaces (Databases, Knowledge Bases/Graphs, and File System Documents).

This post explains how I used Claude Code (Pro level, powered by Opus 4.5) and Mistral Vibe (whenever Claude Code rate limits kicked in) to modernize the aesthetics of our uniquely powerful faceted search and browsing interface for knowledge graph exploration—essentially giving the UI around the core engine a facelift.

At OpenLink Software, we strongly believe that LLM-powered AI Agents are exactly the right tools for tackling this long-standing challenge—provided the RDF-based knowledge graph runs on a platform that isn’t constrained by dataset size. In other words, one that scales naturally in linear fashion—such as our Virtuoso multi-model platform for managing data spaces spanning databases, knowledge bases, filesystems, and APIs.

Situation Analysis

As with many aspects of RDF (Resource Description Framework), challenges in tooling creation often stem from general misunderstandings about the framework itself. RDF-based knowledge graph representation is one such area, and linear visualization is another.

In the case of linear visualization, the goal is to present the description of an entity of interest (the subject) along with its associated attributes—i.e., predicate–object pairings that express attribute names and values.

Compounding the difficulty is the fact that, although faceted search UI/UX patterns have long served as the conceptual foundation, implementing them at the scale typical of RDF-based knowledge graphs remains extremely challenging. This challenge is further amplified by the complexity of delivering such interfaces in HTML leveraging CSS and JavaScript.

Virtuoso's Faceted Search & Browsing System Workings

Fundamentally, this system allows you to perform text search, attribute-name lookup, or entity-identifier–based exploration across one or more knowledge graphs hosted in a Virtuoso instance. It provides a property-sheet–style interface that presents entities (subjects) alongside their associated attributes (relationship predicates) and values (objects).

Thanks to Linked Data principles, hyperlink-based denotation of entities, attributes, and values (optionally) creates a Web of data. This enables the same “click and explore” experience—also known as the follow-your-nose exploration pattern—that users enjoy when interacting with web pages through a browser.

Old System

Here are screenshots depicting the UI/UX for a simple search sequence along the following lines:

• Text Search Input: Virtuoso.

• Initial matches presented in a list, sorted by text score and entity rank (think: page rank for data).

• Add filters by attributes such as "type" (rdf:type) and "name" (schema:name) where the name value is "Virtuoso".

• Click on item from the result to obtain a description of Virtuoso via the entity description property sheet based page.

New System

Original resource: New Virtuoso Faceted Browser Showcase Screencast

Here's the same demonstration sequence, but experienced via the revamped UI/UX.

• Text Search Input: Virtuoso.

• Initial matches presented in a list, sorted by text score and entity rank (think: page rank for data).

• Add filters by attributes such as "type" (rdf:type) and "name" (schema:name) where the name value is "Virtuoso".

• Click on item from the result to obtain a description of Virtuoso via the entity description property sheet based page.

Additional Notable Faceted Search & Browsing Features

These include the following:

1. Handling the fact that lots of attributes (thousands+) could be associated with an entity sources for a massive collection of source knowledge graphs during the filtering stage via a sticky scrollable paging control
2. Handling the fact that a select entity description can also comprise lots of attributes (thousands+) via a stickly scrollable paging control
3. Spreadsheet-like table (with resizable, moveable, and sort enabling columns) for handling query results from filtering or when presenting entity descriptions
4. Ability to export the description of an entity in a variety of formats (JSON-LD, RDF-Turtle, RDF-XML, N-Triples, RDF/JSON, CSV, etc)
5. Permalinking for sharing interaction state e.g., a filter page or entity description page
6. Ability to reveal underling SPARQL query that drives filtering
7. Metadata that provides information on source named graph(s) from which attributes and values have been sourced for an entity description by way of entity (subject) or value (object) role in the source graph triples
8. Metadata that automatically identifies explicit (via owl:sameAs attribute values) coreferences (via values of attributes that are uniquely identifying i.e., inverse-functional e.g., email addresses or any other attribute with the inverse-functional designation in a loaded ontology)
9. Settings for enabling or disabling reasoning and inference informed by built-in or custom inference rules

The Refactoring Process

I achieved this very difficult refactoring task, alongside my other daily duties, by prompting Claude Code and Mistral. Claude Code (using the Opus 4.5 model) handled most of the heavy refactoring and planning work through the initial working ports.

I brought Mistral on board once rate limits kicked in, which became an important part of the experiment—namely, determining what’s possible with the Pro edition of Claude Code.

That said, Mistral also impressed me to the point where I see it as the closest rival to Claude Code in the battle for coding agent market dominance. Its CLI aesthetics and assistance mode are top-notch.

Live Demonstration Instances

URIBurner

This is a live Virtuoso instance since 2008 functioning as a Linked Data utility showcase and bridge to the massive Linked Open Data Cloud Knowledge Graph collective.

1. Text Search: Virtuoso
2. Entity Types associated with text pattern: Virtuoso
3. Attribute Filtering on Type, Name, and Value: Virtuoso Universal Server (Row Store & Cluster Server Edition)
4. Selected Entity Description Page

Conclusion

Software development is evolving before our eyes. True power now comes from pairing capable AI Agents with human expertise—letting judgment guide automation, producing dependable outcomes, and delivering real-world value. The age of AI isn’t just about smarter tools; it’s about amplifying what humans do best.

Why So Many Info Tips Are Bad (and How to Make Them Better)

Mike's Notes

Another excellent article from Kate Kaplan that I can use to configure the CMS Engine (cms).

Resources

• https://www.nngroup.com/articles/info-tips-bad/
• https://www.nngroup.com/articles/tooltip-guidelines/
• https://www.nngroup.com/books/digital-icons-that-work/
• https://www.nngroup.com/articles/gestalt-proximity/
• https://www.nngroup.com/articles/microcontent-how-to-write-headlines-page-titles-and-subject-lines/
• https://www.nngroup.com/articles/interaction-cost-definition/
• https://www.nngroup.com/articles/deceptive-patterns/

References

• Reference

Repository

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

Last Updated

23/03/2026

Why So Many Info Tips Are Bad (and How to Make Them Better)

By: Kate Kaplan

The NN/g Newsletter: 23/01/2026

Kate Kaplan specializes in applying human-centered design and research practices to enterprise UX challenges. With over 15 years in UX, Kate has extensive experience in both conducting research and helping teams understand and apply user insights to overall business strategy.

Summary:

Information tips can clarify complex UIs, but they should not hide essential information, trigger redundant information, or disrupt the current workflow.

Information tips — those helpful little messages triggered by tapping or hovering over a question mark (?) or info (i) icon — can help users make faster decisions and increase the understandability of UI elements. But in practice, they’re often overused, misapplied, or bloated with unnecessary content. When info tips hide essential instructions or bury users in redundant explanations, they create confusion rather than clarity.

In This Article:

• What Is an Info Tip?
• Representing Info Tips in User Interfaces
• The Problem with Info Tips
• Pitfalls of Bad Info Tips
• Pitfall #2: Hiding Critical, Task-Assistive Information
• Pitfall #3: Interrupting the Task Flow

What Is an Info Tip?

An information (info) tip is a brief, contextual message designed to offer supplemental information about a specific interface element or step in a workflow.

It’s typically activated by hovering over or clicking on a small icon — often a lowercase i or a question mark — and is attached to a specific element within the interface (e.g., a text field, icon, button, label).

✅ An example of a useful info tip from the Ease Employment Benefits Portal: Clicking on the ? icon reveals a concise explanation about why specific data is collected and how it’s used.

Info tips can be revealed through two primary patterns:

• Tooltips, which appear on mouse- or keyboard-hover gestures within desktop sites
• Popup tips, which are similar to tooltips, but are triggered by clicking or tapping an element’s associated icon

Both types serve the same core purpose: providing extra context to those who need additional clarification or guidance without overwhelming the interface with text.

Representing Info Tips in User Interfaces

The i Icon: General Information

The encircled lowercase i icon is broadly understood to indicate optional, helpful information.

In our icon-related research, participants interpreted the i icon primarily as representing an option for “more information” and expected it to reveal supplemental information such as:

• Definitions
• Additional details or brief explanations
• Promotional terms

This makes the i icon a good fit for general information or nice-to-know guidance, but not urgent or error-related content. It is a solid choice for representing info tips that support user understanding without interrupting flow.

The ? Icon: Help and Support

The encircled question-mark icon (?) is also used frequently to trigger info tips. In our research, it was more strongly associated with help and support than with general supplemental information.

People expected this icon to lead to:

• FAQs
• Customer-support contact information
• Help content or tutorials

However, when placed directly next to a specific interface element (such as the form field label in the example above) the ? icon is also an effective trigger for contextual help about a specific element. The key is proximity: When the icon is close to what it refers to, users interpret the help as local and relevant, rather than global or generic.

The Problem with Info Tips

Unfortunately, info tips are often abused as band aids in the interface, used to:

• Cram in explanations that should’ve been designed into the UI
• Hide critical instructions in the name of a “clean” interface
• Offload poor labeling or UX copywriting onto the user

Info tips are not a catch-all solution for decluttering the interface by sweeping essential content into a hidden layer. Nor should they be used to bury large amounts of information that disrupt users’ flow when revealed — what we call the “jump scare” scenario, where a user expects a quick tip but gets an entire modal or screen takeover instead.

But info tips aren’t inherently bad. When well-implemented, they offer concise, helpful, and contextual information that improves usability without cluttering the interface.

Well-crafted info tips can:

• Clarify jargon or technical terms
• Explain why specific data is requested
• Guide users to locate needed information
• Reassure users about data usage

However, a good rule of thumb is to assume that most users will never see the info tip. Those who do have extra motivation for seeking them out are confused, stuck, or need clarification or reassurance. That’s why info tips should deliver clear, in-the-moment guidance that directly supports the user's immediate task.

Pitfalls of Bad Info Tips

Info-tip misuse generally falls into three categories:

• Wasting users’ time: Displaying obvious, redundant, or irrelevant information
• Hiding critical information: Burying essential guidance or constraints most users will need upfront
• Interrupting the task flow: Using intrusive patterns such as modals or overlays that take users away from the task at hand

Pitfall #1: Wasting Users’ Time

Every info-tip interaction — even just that one small click or hover — incurs a small but real interaction cost. Redundant or obvious tips waste users’ time and undermine trust.

Don’t use info tips for:

1. Marketing fluff
2. Restating visible content or instructions
3. Reexplaining the obvious

Info-tip icons like the i or ? signal to users that something might be unclear or needs elaboration. When they instead reveal generic marketing fluff, users can feel misled and frustrated.

❌ Doodle.com: The info tip displays marketing information (The quickest way for two people to meet) to further sell the Schedule 1:1s feature.

Info tips also waste time when they restate what’s already perfectly clear in the interface. These tips give the illusion that additional explanation exists, but deliver only repetition.

❌ State.gov: Clicking the i icon next to the City of Birth form field triggers the message: Enter the city of your birth. These tips simply repeat what's already on the screen, making users feel like there's more to learn when there isn’t.

❌ In this example, a ? icon next to Paper Type appears promising. Users might expect guidance on how to choose between options like Satin, Gloss, or Uncoated. Instead, it produces an obvious, unhelpful message: Choose your preferred paper type from the options below.

Pitfall #2: Hiding Critical, Task-Assistive Information

Info tips should not be used to bury essential instructions, constraints, or legal disclaimers. Doing so turns important guidance into a game of hide-and-seek and could even be a deceptive pattern in some cases.

Avoid putting in info tips:

• Constraints or rules
• Form-field limitations (e.g., character limits)
• Legal agreements or disclaimers
• Complex instructions or explanations

Complex instructions that help users make decisions should be visible, not hidden in a tip. People need to reference these explanations while completing tasks, not break their flow or current view to search for guidance.

❌ U.S. Find a Grave Index: These complex explanations for proceeding with a simple task are too overwhelming for an info tip. If a task truly requires this much upfront guidance, the information should be integrated directly into the interface, where it’s always visible and easy to reference.

Instead of hiding complex instructions in an info tip, it’s more effective to display key information at the primary level of the interface. When users must weigh multiple options or make nuanced choices, surfacing that guidance upfront enables quick comparison without disrupting task flow.

✅ Microsoft Test and Learn: The design provides clear, inline explanations for the various output types (Result Grid, Trend Chart, and Category Impact) without requiring multiple clicks or hovers to reveal. This approach helps users compare outputs and quickly make an informed decision without having to hunt down hidden descriptions.

Additionally, any constraints, rules, or limitations for inputs should be displayed on the primary level.

❌ USPS.com: The form field hides character constraints within an info tip. This information should be displayed on the primary level. If the form fails due to unseen constraints, users are left frustrated and rework is required.

Pitfall #3: Interrupting the Task Flow

People expect clicking an information icon to reveal brief, helpful messages that they can reference in the context of their current workflow — not modal windows or full-page takeovers of walls of text.

Don’t surprise users with:

• Overly complex, verbose content
• Modals or overlays that block their task
• New pages that take them away from the workflow

When possible, ensure that info tips are displayed inline or adjacent to the relevant element. Obscuring the current step or view of the interface makes it harder for users to connect the guidance with the task at hand.

❌ CapitalOne mobile site: Clicking the i icon next to About payment options replaces the current view with several explanations of the different amount options. While the information is useful, the pattern disconnects users from the content they need to reference while comparing options.

Modals and full-page overlays are jarring when used for info tips. Keeping the guidance adjacent to the element it supports allows users to maintain context and better understand the relevance of the information.

❌ GSA.gov (1 of 2): Users are likely to expect that clicking the i icon next to First & Last Day of Travel will reveal a brief definition of the term as defined in the travel policy.

❌ GSA.gov (2 of 2): Instead, clicking the icon triggers a darkened overlay that obscures the workflow and a surprising modal dialog at the top of the page.

Even more disruptive is launching an entirely new page from what appears to be a simple info-tip icon. This approach not only obscures the context but also forces users to abandon their task.

❌ Nextdoor.com (1 of 2): The site displays a ? icon next to the Sign-in code field label. Users are likely to expect that clicking the icon will display a brief description of what a signin code is or where to find it.

❌ Nextdoor.com (2 of 2): Instead, clicking the ? icon next to the Sign-in code field launches a new page containing a full explanation of two-step verification. The information about where to find the signin code is buried within the verbose content.

Conclusion: Use Info Tips Wisely

Info tips can enhance clarity when they offer just-in-time, supplemental guidance within the context of the current workflow.

Do:

• Use info tips for supplemental content
• Keep them short, contextual, and easy to dismiss
• Represent them with familiar icons (i or ?)
• Assume users who activate them need quick, in-the-moment guidance

Don’t:

• Hide essential or frequently needed information
• Use info tips as a crutch for poor labeling or dense layouts
• Trigger popups or overlays that hijack the user’s focus or flow

When thoughtfully implemented, info tips reduce confusion and increase user confidence. But they should always serve the user’s goals, not the designer's desire to declutter at all costs.

Design in code, get praise

Mike's Notes

Using this method for the upcoming workspace testing. Design is done in Pipi, not Figma. IMO, Figma is over-hyped.

Resources

• https://adamsilver.io/
• https://www.youtube.com/@adamsilverhq
• https://formdesignpatterns.com/
• https://www.smashingmagazine.com/2018/10/form-design-patterns-release/
• https://www.smashingmagazine.com/printed-books/form-design-patterns/
• https://www.smashingmagazine.com/provide/eBooks/form-design-patterns-excerpt.pdf
• https://prototype-kit.service.gov.uk/docs/
• http://gov.uk/
• https://www.gov.uk/service-manual/design
• https://prototypekitcourse.com
• https://www.blog.ajabbi.com/2023/12/uk-government-design-system.html

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > Adam Silver
• Home > Handbook > 

Last Updated

12/03/2026

Design in code, get praise

By: Adam Silver

Adam Silver: 19/01/2026

Adam Silver is an interaction designer with over 15 years experience working on the web for a range of companies including Tesco, BBC, Just Eat, Financial Times, the Department for Work and Pensions and others.

He’s particularly interested in inclusive design and design systems and writes about this on his blog and popular design publications such as A List Apart. This isn’t his first book either: he previously wrote Maintainable CSS, a book about crafting maintainable UIs with CSS.

This week I demoed some flows I’d been redesigning to a room full of product managers and stakeholders.

The programme I’m on is huge. We’re redesigning a highly complex, enterprise-grade, case-working system.

There are many feature teams, each with their own product manager. I’ve been on the programme for 6 months now but it’s so big I’ve not met many of them.

The meeting was meant to present the before/after of the redesigns to show what it looks like to just use the simple and accessible patterns from the GOV.UK Design System and a few of my own, encouraging other feature teams to reuse them.

It did that.

But it also did something else, something I didn’t really expect:

Toward the end of the meeting, the conversation veered off.

There were comments and questions about the tool I'd used to create and demo the designs:

“I love the way this demos new concepts.”

“The prototype really helps you to understand the user journey”

“It’s been so helpful for our developers to show them how something actually works”

Most designers use Figma, but I had created an HTML prototype using the GOV.UK Prototype Kit.

Don’t get me wrong, Figma has its place but at the end of the day:

Figma can only produce pictures of software.

Not actual software.

Actual software is alive.

• It moves
• It adapts
• It errors
• It loads
• It responds

Figma might be useful to design in.

But it’s not good to design “out”.

By that I mean:

When you present your designs with Figma, you’re not interacting with the product you’re designing.

You’re interacting with the software you used to design.

As a result:

1. It’s slow and jarring. Your audience has to watch you stop, scroll, pan and zoom around Figma between each step.
2. It may not do your design justice. Your audience is focused on you navigating Figma rather than experiencing your design.
3. It may hide problems. You’ll probably jump between screens and miss important details - realistic data, micro interactions, transitions, loading states, error states and edge cases.

Designing in code and demoing in the browser forces you - or at least encourages you - to confront these things.

For my demo, instead of just sharing screens:

1. I opened the browser and typed in the URL
2. I signed into the case-working system
3. I landed on the overview page which showed me my priority tasks
4. I made the screen smaller to show two instances of the app side by side
5. I clicked “Cases” in the primary menu to go to the case list
6. I searched, filtered and sorted the list to find a particular case
7. I filled out a complex multi-step form flow with conditional logic

In other words, I went through the entire end-to-end journey and interacted with the prototype just like real users would.

This allowed my audience of product managers to free up their mental energy and instead focus on understanding the design intention and potential gaps.

That’s 100x harder to do with Figma.

After the meeting, I received a lot of positive feedback which is great because I love praise.

One product manager actually suggested I help train some of the other designers on the programme who are less familiar with the Prototype Kit.

But she also pointed out that it would probably take up too much of my time.

Luckily, I’ve been preparing for this moment for 2 years. I told her:

I have a course that teaches designers how to use the GOV.UK Prototype Kit to unlock the many benefits of prototyping in code.

If you’d like to learn how to use the Prototype Kit and unlock those benefits — including a little unexpected praise when you present at your next show and tell:

​https://prototypekitcourse.com​

Cheers,

Adam

How Intel Gave Stephen Hawking a Voice

Mike's Notes

I hope that Pipi CMS can provide an AAC (picture language) interface as one of its accessibility options.

…we have a moral duty to remove the barriers to participation, and to invest sufficient funding and expertise to unlock the vast potential of people with disabilities. - Stephen Hawking

Resources

• https://www.wired.com/2015/01/intel-gave-stephen-hawking-voice/
• https://www.vitrx.co.uk/the-technology-that-allowed-stephen-hawking-to-communicate/
• https://github.com/intel/acat
• https://theconversation.com/the-technology-that-gave-stephen-hawking-a-voice-should-be-accessible-to-all-who-need-it-93418
• https://www.bbc.com/news/technology-33991887

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subject > Accessibility
• Home > Handbook > 

Last Updated

05/02/2026

How Intel Gave Stephen Hawking a Voice

By: João Medeiros

Wired: 13/01/2015

João Medeiros is Features Director for Wired magazine. He was born in Portugal, and came to the UK at eighteen. He has a PhD in theoretical physics at Imperial College. He has written widely for publications including The Economist, GQ and Nature.

Stephen Hawking first met Gordon Moore, the cofounder of Intel, at a conference in 1997. Moore noticed that Hawking’s computer, which he used to communicate, had an AMD processor and asked him if he preferred instead a “real computer” with an Intel micro-processor. Intel has been providing Hawking with customized PCs and technical support since then, replacing his computer every two years.

Stephen Hawking

Wired January 2015, Relates to special feature on Stephen Hawking, Hawking sits in his personalised special electric wheelchair, text in foreground from him screenMarco Grob/WIRED UK

Interview

There is a 17-minute interview behind the paywall.

---

Other Notes

The "Equalizer" is a 1980s computer program developed by Words Plus CEO Walter Woltosz to help his mother-in-law, who had ALS. It enabled Professor Stephen Hawking to communicate by selecting letters, words, and phrases on an Apple II computer via a hand switch, later upgraded to a cheek-switch sensor. 

Key Details of the Equalizer:

• Purpose: Developed to assist patients with ALS who lost the ability to speak and write.
• Usage: Hawking utilized this software, later integrated onto his wheelchair, to produce up to 15 words per minute.
• Operation: The user interface allowed for selecting words from a database or spelling them out, which were then converted to speech using a Speech Plus CallText 5010 synthesizer.
• Development: Walter Woltosz co-founded Words Plus in 1981 and created the software to provide a voice for those with communication disabilities. 

---

Stephen Hawking and the Technology that allowed him to continue his research18/03/2018

Stephen Hawking, who sought to explain the origins of the universe, the mysteries of black holes and the prospect of time travel, died today aged 76. Hawkings body was ravaged by the wasting motor neurone disease (ALS) he developed age 21 and spent most of his life confined to his wheelchair.

Hawking’s incredible mind probed the very limits of human understanding both in the vastness of space and in the sub-molecular world of quantum theory, which he claimed could predict what happens at the beginning and end of time.

In his 2013 memoir “My Brief History” he explained how at first he “felt it was very unfair” and often questioned “why should this happen to me.” With time and technology, he went from concern that his life was over and his potential never realised to now, 50 years later, feeling quietly satisfied with his life and achievements.

How Intel gave Hawking his voice.

In 1986, aged 44, Hawking lost his voice to save his life after an attack of pneumonia. For a while, he used a spelling card to communicate, patiently indicating letters and forming words by raising his eyebrows. Although this gave Hawkings the ability to communicate the process was slow. From then on, he spoke through a computer synthesiser on the arm of his wheelchair.

A chance encounter with Gordon Moore, the co-founder of Intel, at a conference in 1997 led to a relationship that would see Intel providing Hawking with customised PCs and technical support, replacing his computer every 2 years.

Martin King, a physicist who had been working with Hawking on a new communication system, contacted a California-based company called Words Plus, whose computer program Equalizer allowed the user to select words and commands on a computer using a hand clicker. Words Plus CEO Walter Woltosz had created a earlier version of the speech equalizer to her help his mother-in-law who also suffered from ALS.

Equalizer first ran on an Apple II computer linked to a speech synthesizer made by a company called Speech Plus. This system was then adapted by David Mason, the engineer husband of one of Hawking’s nurses, to a portable system that could be mounted on one of the arms of a wheelchair. With this new system, Hawking was able to communicate at a rate of 15 words per minute.

However, the nerve that allowed him to move his thumbs kept degrading. By 2008, Hawking’s hand was too weak to use the clicker. His graduate assistant at the time then devised a switching device called the “cheek switch.” Attached to his glasses, it could detect, via a low infrared beam, when Hawking tensed his cheek muscle. Since then, Hawking has achieved the feat of writing emails, browsing the internet, writing books and speaking using only one muscle. Although this system worked it was still slow… enter SwiftKey. With SwiftKey integrated, the system could learn from Hawking and predict the characters and words he planned to type next based on historical patterns, with this data funnelled through to his speech synthesiser. SwiftKey has also tapped Hawking’s historical works to help it more accurately predict his next words in this bespoke version of the software.

The technology that enabled Stephen Hawking to speak.

As you might expect, it is not just one piece of equipment that is involved here. Many technologies combined to allow Hawking to communicate.

• Lenovo Yoga 260 provided by Lenovo and Intel, Intel® Core™ i7-6600U CPU
• 512GB Solid-State Drive
• Windows 10
• ACAT interface software provided by Intel

Speech Synthesisers (3 copies):

• Manufacturer – Speech Plus (Incorporated 1988, Mountain View, CA)
• Model – CallText 5010
• Speaker and amplifier provided by Sound Research
• Permobil F3 wheelchair provided by Permobil

It is undoubtedly the incredible technology that enabled Hawking to speak again that gave him the hope and drive to continue with his work. Hawking was an Ambassador of Science and showed us what determination looks like.

What happened to Stephen Hawking?

Stephen Hawking died on March 14, 2018, aged 76. In itself, an incredible achievement, but Stephen did much more than simply survive for 76 years. His life was an inspiration to so many people. Interestingly, he didn’t believe in God or the afterlife. He called heaven “a fairy story.”

In his final, posthumous book “Brief Answers to the Big Questions.” he wrote “there is no God”. and “no one directs the universe.” He had disputed the existence of God for many years before his death.

he wrote, “The question is: Is the way the universe began chosen by God for reasons we can’t understand, or was it determined by a law of science? I believe the second,”

Hawking believed that “spontaneous creation” was the reason for existence, writing “it is not necessary to invoke God to light the blue touch paper and set the universe going.”

He will be remembered for many years.

Modular software design

Mike's Notes

A good, clear explanation of modular system design by Chris Loy.

Resources

• https://chrisloy.dev/post/2025/01/24/modular-software-design

References

• Reference

Repository

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

Last Updated

25/01/2026

Modular software design

By: Chris Loy

Chris Loy: 24/01/2025

Hey, I'm Chris. Nice to meet you!

I spend my professional life writing code, training machine learning models, building software products and running tech teams. I'm a startup founder with a successful exit, and in my career I've been CTO, a developer and a data scientist. I've worked at companies big and small, mentored junior engineers and data scientists from across Europe, and served as an advisor for some companies. Throughout my career I have been lucky enough to work with and hire some amazingly smart people.

This is my website, where I write about tech, data and AI, as well as some of my other interests and hobbies. Those include music and photography, and I also use this site to document the books I read..

Whenever people ask me about my philosophy for building software, top of my list is always to say that I am a proponent of modular design. To explain what I mean by that, it is first necessary to understand a few of the fundamental theories that underpin how I view software engineering as a discipline, and then we can explore how those come together in a philosophy of modularity.

Systems

Software engineering is a discipline for the design and implementation of complex systems of interacting elements. If a program is intended to serve a single purpose by completing just one task, that task can be broken down into smaller tasks, which can themselves be broken down further and further.

The result of conceptually atomising monolithic operations is a network of interdependent operations that comprise the wider system. The boundaries of this system are wide and varied - how data is written and read from hardware devices, communication of information between geographically separated networks, even the knowledge and opinions of humans interacting with websites or smartphone apps. Whatever we are building, our control extends only partway through the network.

Systems thinking is the embracing of the vastness and complexity of all the moving parts that influence the operation of software. The challenges we face therefore come from the limits of our own capacity for comprehension.

Abstraction

To address this complexity, the primary philosophical tool in the software engineer’s belt is abstraction. To abstract something is to hide its complexity by defining only the way that it interacts with the world around it, and to deliberately behave in a way that ignores the inner workings of the thing.

This is the fundamental thought process in software development, first articulated by Dijkstra in his essay “The Humble Programmer”. The central thesis of that essay, written in the 1970s before the invention of the microprocessor, was that as programmers we are developing systems too complex to hold fully within our mind all at once. At the time, this was a unique and forward-thinking insight - today it is obvious.

Abstraction teaches us that software engineering is a philosophical discipline - one in which our goal is to enhance our ability to reason about complex systems by effectively abstracting away complexities that lie outside our immediate sphere of interest. Components that are behind or within the components we directly interact with are ignored - only the immediate effect on us is relevant.

Encapsulation

To make this kind of abstraction possible, it is necessary that components within the system encapsulate their complexity such that others can abstract it away when interacting with them.

This concept is often talked about within the domain of object-oriented design - a discipline that is perhaps less fashionable than it once was, but still underpins much of the fundamental way in which software is best built. The core idea is that a component should encapsulate its functionality and only present what it does to the outside world, not how it does it. It is not necessary to understand what happens to the engine of a car when you depress the accelerator pedal - only to know that it goes faster.

In normal language, we would call the surface of encapsulated functionality an interface, but our industry loves three letter acronyms, and so we universally tend to use the clunky term Application Programming Interface for this, or API for short.

Recursion

Recursion is a simple-to-explain, difficult-to-grasp context from mathematics that is all over software design. The simple explanation is that it is just the concept of a system in which components can be self-referential within their category. To give an example, I have two parents, and each of them had two parents, and so on. The “and so on” in this sentence is the recursion. This one very simple relationship belies a hugely complex tree of connections - my family tree, in this case.

Through this lens, there are no limits to encapsulation, where each layer of abstraction can be nested within arbitrary other layers of abstraction. Components encapsulate components, recursively. A component has many components within it, each of which has many more. And so on.

The ability to zoom into the right layer of abstraction within this tree of complexity is how we accomplish the task of writing software. By well defining interfaces around components, by abstracting the details of how they work and instead just understanding what they do, and by navigating through a recursive tree of components, we are able to reason about the behaviour of our system at all levels of abstraction.

Modularity

What then, is modular software design? Well, it is an acceptance of the above philosophy, and an embracing of the implications, specifically in thinking about how systems evolve over time. For me, this fundamentally comes down to designing systems such that you maximise your ability to effect change through adding, moving or replacing components, rather than modifying existing ones. This motivation comes from the hard-earned experience that modifying working software is hard, but replacing or adding software can be easy if your setup is optimised for it.

By thinking of systems as networks of interconnected and nested components, and adopting a strategy of ensuring all of those components have well defined interfaces at each layer of abstraction, we build software that is flexible, resilient and easy to reason about.