The Prepared - Where it's at, and how I'm doing with it

Recently The Prepared, my weekly manufacturing newsletter, crossed 1000 subscribers. As a result of this (and because it's been on my mind for a few months), I wanted to post an update to the role that The Prepared plays in my life, and how I see it working in the future.

I'm going to cover three areas in this post. The first is about the actual execution of The Prepared - the time spent curating and creating the newsletter every week. The second is more operational, and covers the underlying infrastructure (and cost) required to make The Prepared happen. The third is on the impact that The Prepared has had on my own life and career - and, to the extent that I'm aware, the impact that it's had on my readers.

How The Prepared is made

The Prepared was spawned as a result of my own reading habits; its original purpose was to track and share the things that I felt might be important for me to know in the future. I read something like 50 articles per week. I don't have current stats, but in previous years that's worked out to between 4 and 5 million words per year, which at a speed of 273 words per minute (roughly my rate) averages to 5.5 hours of reading per week. Most of that happens on the subway, which I ride for roughly 5 hours per week (two half-hour commutes per day), and the rest happens in waiting rooms or while I'm on a plane taxiing around the airport (I can often blast through a backlog of reading while traveling). 

But reading is only part of it: Even after spending five or six hours a week reading and filtering down to a few dozen shareable links, I still need to actually compose the newsletter. This usually happens on weekends, and takes at least an hour or two. All in, I'd say that the average newsletter represents roughly seven hours of work - a commitment of over 250 hours per year.

I enjoy doing it, and a lot of the reading I'd do anyway. But it puts some pressure on my life - and I've spent a bit of time thinking about how that can be reduced. To start, I've asked Eric Weinhoffer - a subscriber to The Prepared - to curate the newsletter on a few occasions. I've been thinking of expanding my guest curation program, though I've been conservative about doing so. If you're interested in being a guest curator, let me know - I'll put you on my list.

Overhead & Infrastructure

The Prepared's stack goes Pocket -> IFTTT -> Gmail -> Mailchimp. For a long time, this whole process was free, but recently I've upgraded both my Pocket and Mailchimp accounts; the total annual cost of these is $344.99.

I've also put a bit of money into paid advertising. I bought ads on Twitter, Facebook, and Reddit, spending $40, $25, and $75 respectively. I did this as an experiment, to see who would sign up and how expensive it would be to expand The Prepared's reach. Of the three, I found Reddit to be a bit more effective - I got more referral traffic per dollar than Facebook, and longer session times as well (my Twitter ads were a leadgen campaign, which allowed users to sign up directly from the Twitter app; as a result it's a bit harder to compare results there). I'm not sure whether I'll continue to use ads to expand The Prepared's reach, but I'm glad to have seeded a few new users that I might not have been able to reach organically.

On the other side of the equation, I recently began soliciting donations for The Prepared. To date, I've received $76.25 from five readers, which averages out to about $0.07625 per reader. My hope is that I can bring in an average of $5 per reader in the second half of 2016 - an amount that seems ambitious, but not unrealistic. 

Speaking of which: If you read The Prepared, you should consider donating! As outlined above, it takes about 250 hours per year PLUS $344.99 in fixed costs per year. If you donate $5 per year, then that values my time composing and sending the newsletter at about $18/hr - a pretty fair wage, if you ask me.

Impact

It's a bit surprising to say, but somehow this weekly email - which I started without really wanting it to be a thing - has become one of my primary calling cards (the other big one is "the bin of broken dreams guy"). I get 3-5 emails about it every week; some are from people I knew before it started, but most are from folks who I probably would have never met otherwise. Usually one or two of these is a link submission, but many are just someone saying hi - something I never expected to happen. It feels great.

I've also developed a handful of significant relationships through The Prepared. I've met a few dozen subscribers in person, and have on many occasions turned to them for specific advice or expertise. I've also connected a few subscribers to each other, and on at least one occasion this has resulted in someone being hired for a job. 

Moving forward, I want to continue making The Prepared a way for people to connect and share ideas. Despite my slow rollout, I'm excited to have more people curate, and I want to find more ways to connect The Prepared's subscribers directly too. This probably means organizing meetups or drinks more often; I've also considered setting up an online meeting place.

The Prepared has taken up *way* more of my time than I could have ever anticipated, and has bought me more in return than I could have possibly hoped for. Here's to its continued expansion, and whatever the future brings.

Backlog

It's been more than a month since my last blog post. This is a result of a bunch of factors. Some of these are personal (it's summer, and I'm moving into a new place soon, and I've been conscious to maintain some personal time) and some of them are businessey and good (we've been *very* busy at nTop, including some big product updates), and some of which are more random (most of my projects are in holding patterns right now and there hasn't been much to update). 

Because I care, though, here's a quick recap of what I'm working on:

• A new run of Public Radios. I've got a few small speaker changes in my backlog, and we're still chugging away at a few circuit updates. 
• A printed lattice stem. I hope to have an update on this in the next week.
• An update on my printed seatpost testing. I got the failed parts back last week, and want to write up a short post on those results. I'm also still sitting on some parts that were HIP'd and treated by REM, and I'm planning on assembling and then testing one of those too.

Totally separately, I spent an hour today updating some drawings for the parts for the leather wallet I made a few years ago. I made them in order to explain how to repair the hand stitching on the wallets, but the drawing looks nice (I usually think drawings look nice) so I thought I'd post it here. 

View fullsize

So, there you have it. I should have some updates here on some of these things soon :)

Seatposts, tested

Today I got word from EFBE that two of my EBM seatpost had been tested - and failed.

As-printed sample

Failed after 80,904 cycles of 1230N, per ISO 4210–9:2014, 4.5. Full details of the part's surface finish treatment here.

"Bling" sample

Failed after 70,770 cycles of 1230N, per ISO 4210–9:2014, 4.5.  Full details of the part's surface finish treatment here.

These are the as-printed and the "bling" samples (see this blog post for details); they failed after 80,904 and 70,770 fatigue cycles (at 1230N), respectively. As a result of their failure, I decided to not test the third "fatigue resist" part.

I'll write up a longer description of the results soon, but two thoughts here:

• These parts were *not* HIP treated - which might possibly have helped their fatigue resistance.
• It appears that some delamination occurred between the printed parts and the carbon fiber post, which makes me question whether the glueline itself was faulty. If so, it's possible that by improving my glue joint I could have relieved some stress from the printed part. Regardless, I will note that the glueup process was kind of a pain in the ass - and I'd like to redesign that anyway.

As it happens, I have three more of these parts on my desk now. They *were* HIP treated, and I intend to glue one of them up and send it for testing. It won't be a perfect 1:1 test (these parts were treated by REM Surface Engineering, through a different process than MicroTek uses), but the results will be interesting at the least :)

Onwards!

(Another iteration of my) Bike stem

This.

View fullsize

The lattices here were, obviously, designed in nTopology Element Free (which is free!). I happen to have done the mechanical design in Inventor, but the rendering was done in Fusion 360 (effectively free, and totally capable of doing the mechanical design as well). I separated face groups and remeshed surfaces in MeshMixer (free!), and very well could have done the booleans there too (I used netfabb).

^ I just think that's a bit remarkable.

Anyway, it's ready. Printed part (DMLS titanium) soon.

An industrial map

On a lark a week or two ago, I started putting locations of industrial stuff (factories, research centers, corporate headquarters, etc) on a custom Google Map. Many of these I've been to, on either public or private tours; others I hope to visit in the future.

If you know of somewhere that you think I should add, give a holler! I'd love to add more - especially if I can swing a tour :)

Being in New York

A few days ago I went to hear Ron Conway, Fred Wilson, and Michael Bloomberg speak about investing, entrepreneurship, and civic engagement. At a few moments during the event, the conversation turned to the current state of business (specifically startups) in New York City, a topic I've been thinking a lot about recently.

I feel passionately about working in New York. So much good work - across such a wide range of disciplines - has been and is being done here. And between the vast feeling of cross-pollination, and the fact that people come here specifically to do stuff of historic proportions - to make the most of their lives - is unlike anywhere else I've ever been (outside of urban China).

On a daily basis I look up and feel these pangs of energy, and wonder, and appreciation. I feel it talking to the Burmese cab driver bringing me back down North Conduit Ave from JFK. I feel it walking off the A/C train, and out through the old AT&T Long Lines headquarters, and onto Canal St and the morning in lower Manhattan. I feel it when I'm walking my dog around Bed Stuy at night and look up, through streetlights dappled by sycamores, to nod at someone smoking a joint on their stoop.

And I feel it in my work. As Bloomberg said this evening: If you want to make a business that serves the world, you need to go where the world is. And I believe that it is here more than anywhere that the many aspects of human life and work coexist best.

NYC has proven time and again that it's capable of spinning up and maturing fully fledged industries. And while many cities tend to go from one primary industry to another with little overlap, NYC somehow manages to grow and sustain many world-class operations at once. This is perhaps the most powerful part of working here: the ability to cross from industry to industry on a daily basis, and to develop long term relationships with people operating in totally different time scales.

I'm enriched by it. It's a world class place to work, and there's no better city to spend your life in.

Lattice design workflow in nTopology Element

Yesterday I recorded a quick demo of myself using nTopology Element Free, which shows how *shockingly* easy the software is to use :) Check it out!

In this video, Spencer Wright shows how to generate, edit, and apply variable thickness to a complex lattice structure in nTopology Element Free.

What manufacturing is

Last week Ben Thompson published a piece called "Everything as a Service." In it, he describes how Apple struggles with providing good software services to support its hardware products - and describes what he calls "the manufacturing model:"

Apple has arguably perfected the manufacturing model: most of the company’s corporate employees are employed in California in the design and marketing of iconic devices that are created in Chinese factories built and run to Apple’s exacting standards (including a substantial number of employees on site), and then transported all over the world to consumers eager for best-in-class smartphones, tablets, computers, and smartwatches.

I'm a big fan of Thompson's thinking and writing, and this piece provides a few very interesting insights into Apple's organizational structure. In the context of developing and distributing hardware products, however, I think Thompson's choice of words - "the manufacturing model" - is counterproductive and misleading.

I started thinking about this question a few weeks ago when prepping for my design for manufacturing workshop. It's something that's broadly misunderstood [citation needed] by people who haven't made a lot of things themselves, and one that I recommend you, dear reader, consider carefully as you're developing and distributing (or consuming and evaluating) hardware products.

Manufacturing is a thing that happens; you can literally go places and watch it. It's more than just converting raw materials into finished products; that's craft, which existed before the industrial revolution and continues today. Manufacturing implies scale, and some degree of division of labor, and a degree of uniformity in the finished products. I think this can be summed up as:

Manufacturing is people, doing physical things, again and again, in a repeatable way.

Apple relies on manufacturing, but their business model is more accurately described as "selling hardware products at a profit." Some of those hardware products are made by job shops which have the same business model as Apple has (Apple specifies the hardware product they want to buy, and the supplier sells them those products at some per-unit price). I'd also guess that many of Apple's suppliers sell them manufacturing services instead - billing on a per hour basis or otherwise. Either way, just saying "this company makes money by transferring ownership of a piece of hardware" tells you little about their organizational structure - and even less about their business model.

If you want to get good at manufacturing, do the same thing over and over again and try to improve the repeatability and cost structure of what you're doing. But don't confuse that with developing a business model - it does both things a disservice to do so.

Teardown: Nerf N-Strike Jolt Blaster

Last week I led a bunch of NYC hardware folks through a design for manufacturing exercise in which we tore down inexpensive consumer hardware and tried to understand how they had been engineered for manufacturability. It was fun seeing a range of things be taken apart, and I wanted to do the exercise myself here.

I chose my favorite product of the night: A Nerf N-Strike Jolt Blaster, sold on Amazon for a whopping $5.99. 

Note that I discarded the packaging before taking my camera out. It was very simple - a piece of printed cardboard, a thermoformed plastic sheet, and two pieces of clear tape.

The blaster (I guess I'll use "blaster" here instead of "gun," though it seems a bit silly) comes with two darts. I took those apart first. They're made of two parts: a piece of cut-to-length blue foam tubing and a piece of molded orange and white rubber. They're glued together, probably with cyanoacrylate aka crazy glue - everything in the blaster seemed to be glued together with CA.

Next I removed the four screws at the base of the handle. These were the only screws in the entire product, and they're installed directly into the molded plastic body so no nuts are needed.

Next I removed the two rubber parts on the plunger, which had a light coating of lubricant on it. First there was an o-ring, and then there was a molded button-shaped part which was installed underneath a rivet.

With the rubber parts off, I pried the rivet (which had a barbed shaft and was pressed into the end of the orange plunger handle) out of the assembly. 

Next I removed three orange parts off of the barrel of the blaster. These appeared to be completely cosmetic.

Next I removed the blue plastic cap off of the back of the blaster. This has little false screws (colored blue as well), and was glued into the blaster body pretty securely. Behind it was a light gauge spring and the dart drive mechanism itself.

Lastly, I pressed the trigger pivot pin out of the blaster's body. I used the cap from a small brass container I made a few years ago to hold the blaster off of the vise jaw, and a torx driver bit to push the pin through the blaster body.

Here's the entire product disassembled:

View fullsize

The whole blaster has 24 individual parts, plus packaging. The full BOM would have 21 parts on it, plus cyanoacrylate glue and two pieces of tape. It's possible that the screws and trigger pin come off the shelf (and conceivable that the o-ring and possibly the springs do too, though I suspect they're custom), but everything else would require a significant amount of custom tooling. I count about 25 individual assembly steps required to put the whole product together. Oh - and a few of the parts are painted, too.

All of this costs $5.99.

I think this is pretty incredible.

Element Free

When I joined nTopology, our flagship CAD software - Element - was in closed beta. I had used it myself over the fall, and was impressed at how quick and easy it was to generate variable lattice structures. But the GUI was often confusing and many of the core functions were still very much prototypes.

Today, I'm proud to announce that nTopology has released its first public product - Element Free. We've spent a ton of time on this over the past four months, and have both streamlined the workflow and improved the core design tools needed to design and edit complex lattice structures. 

We'll be working hard to integrate more features into Element Free over the coming months - and will be releasing a Pro version this summer. Head over to the nTopology Product page to download the software yourself!

Coherence

This photo is of a conference table in Alcoa's headquarters:

View fullsize

If it's not clear, this little inlay is made from aluminum. Which is pretty rad, considering that Alcoa is an aluminum company.

As a project manager, I'm all about choosing the right tool for the job. But I'm also all about using the tools that are available to me in the most effective ways. This table didn't need an aluminum inlay, but the aluminum inlay that Alcoa gave it worked pretty damn well.

Reflections on three weeks of speaking

I've given versions of the same talk three times over the past three weeks, and wanted to take a moment to note (mostly for myself) some observations I've had about both my own presentation and public speaking in general. 

First, I'm pleasantly surprised at how little nervousness I've felt. I've done a bit of public speaking in the past year or two, and in former lives have held jobs that required me to do somewhat better than commanding a room, but the past month's events have been less personal and had a higher chance of impacting my career - and still I've gone into them feeling more or less comfortable. Certainly some portion of this is my familiarity with the subject matter (my talk is not entirely a review of things I've written about on my blog, but there's a lot of overlap), but I dare say that I might also be growing into myself a bit. I recognize that this is kind of a weird thing to say of oneself, but I'm pretty sure it's at least partially true.

I think some part of my degree of comfort has to do with the fact that I've found a way of balancing my own deeply held philosophy with the fact that I'm selling something that speaks to that philosophy. This has been a long time coming, and probably deserves more than I can grant it here, so I'll leave it at that and move on.

I will note, however, that the entire experience of speaking at an event is noticeably more exhausting than simply attending. I suppose this is self evident, but presenting your work & thoughts is de facto an invitation for people to ask questions of you (and present their own work & thoughts one-on-one), and responding to that attention takes considerably energy. That's not to say that I don't enjoy it; indeed, eliciting a response is the primary reason to speak publicly in the first place. But it drains me a bit too - and I'll admit that I still haven't followed up on all of the business cards I've collected this month.

Lastly: I've also seen quite a few other folks speak publicly over the past month (conferences are conferences, after all), and I can't help but wonder what I would think of my own talk. If anyone out there has seen me speak recently and has feedback, send it along :)

Seatposts assembled

Before I send these three seatposts out for testing, a quick update:

The seatpost heads (which I wrote a detailed post on a few months ago) are now glued to carbon fiber posts. I also added a thin carbon fiber disc to the top of each of the posts, so that water can't get into the bike's seat tube. The whole thing was assembled using 3M DP420 epoxy.

These are headed back to EFBE this week, where they'll go through the same ISO test as my seatmast topper was subjected to. More details soon!

Point modifiers

Just a quick update to yesterday's post - here are some screenshots showing a little bit of how I'm controlling thickness on my lattice stem.

Our variable thickening algorithm allows the user to input minimum and maximum beam diameters. If a beam isn't within the range of any point modifiers, then it's thickened to the minimum value. If it's within range, then its thickness is determined by the falloff curve of the modifier that it's within range of. If it's within range of multiple point modifiers, then the greater thickness value is used.

As you can see above, the Modifier Editor allows the user to preview the effect that the modifiers will have on a part; blue means that a region is not within range of a modifier (and will be the minimum thickness), and red means that it's within range (and the maximum thickness will be applied). We allow you to preview this on any mesh in your project. Here I'm looking at a variably thickened lattice, but generally I'd start with a uniform thickness lattice and then play around from there.

The big change in the design yesterday was adding point modifiers in four locations: On either side of the handle bar clamp, and on the top and bottom of the steerer clamp. These modifiers have steep cosine falloff curves, meaning that they have a big effect on a relatively small region of the part. I've controlled the range and falloff so that just the beams on the edges of those surfaces are affected.

I also have point modifiers at all of the bolt holes, and a few that control thickness on the rest of the clamp surfaces, and then two point modifiers that make the transition from the clamp surfaces to the center of the extension a bit more gradual.

We've been thinking a bit more about how to develop modifiers in the future - stay tuned!

Stem update

A friend asked me yesterday what was going on with my lattice bike stem design, and after telling him that it's been on the back burner I played with it a bit and made some real (if subtle) improvements. 

First, I should note here that I'm *not* worrying about overhanging faces. That's mostly because I'm working at nTopology to break down manufacturability of lattices into its component parts, and am tabling all of my DFM concerns until I have real data to back them up. In addition, I'm focusing on using variable thickening to maximum effect right now. I've used variable thickening a lot in the past, but the next software update of nTopology Element pushes it even more into the forefront, and I want to dogfood myself a little before we release it into the public :)

I don't have screenshots of the whole process, but this part was designed in much the same method that I was using last fall. I used Inventor to make a design space, and Meshmixer to generate surfaces to grow a lattice on. Then I used Element to:

1. Create a surface lattice with beams at every edge in the Meshmixer model
2. Create a volumetric lattice (based on a hex prism cell shape) inside the part
3. Merge the two lattices by snapping nodes on the volumetric lattice to nearby nodes on the surface lattice
4. Creating attractor modifiers at locations that I know I'll need more thickness in my lattice, e.g. mechanical features
5. Applying variable thickness to the lattice based on those modifiers
6. Refining the resulting mesh & reintroducing mechanical features via Booleans

The trickiest thing by far here is setting the attractor modifiers to the right range & falloff. I've got three things going on here:

• Bolt holes. These need to be maximum thickness (1.5mm) to accept threads and distribute the load from the bolts.
• Clamp surfaces. Where the stem clamps to the steer tube and handlebar, the part needs to have relatively high surface area. All lattice beams should lay on the surface itself, and thickness should be high as well.
• Mechanical stress. I haven't done a full analysis of this part, but in general stress will be concentrated near the clamp surfaces and will be lower in the middle of the part.

Clearly this blog post would be more effective if I ran through every attractor one-by-one and explained how editing them changed the resulting structure, but we'll have to forego that for now. Suffice it to say that the part above weighs 105g and has roughly the mass distribution I was looking for; I'll update with more details soon :)

Termites, not tornadoes

Again, from The Mythical Man-Month - emphasis mine:

When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes; and the schedule has slipped imperceptibly but inexorably. Indeed, major calamities are easier to handle; one responds with major force, radical reorganization, the invention of new approaches. The whole team rises to the occasion. 

But the day-by-day slippage is harder to recognize, harder to prevent, harder to make up. Yesterday a key man was sick, and a meeting couldn't be held. Today the machines are all down, because lightning struck the building's power transformer. Tomorrow the disk routines won't start testing, because the first disk is a week late from the factory. Snow, jury duty, family problems, emergency meetings with customers, executive audits — the list goes on and on. Each one only postpones some activity by a half-day or a day. And the schedule slips, one day at a time.

No small slips

Also from The Mythical Man-Month:

Let us consider an example. Suppose a task is estimated at 12 man-months and assigned to three men for four months, and that there are measurable mileposts A, B, C, D, which are scheduled to fall at the end of each month. Now suppose the first milepost is not reached until two months have elapsed. What are the alternatives facing the manager?

...

3. Reschedule. I like the advice given by P. Fagg, an experienced hardware engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.

If you need to reschedule, take responsibility - and make sure you only need to reschedule once. 

This book is good.

Conceptual Integrity

I'm reading The Mythical Man-Month, and this section jumped out at me hard. Emphasis is mine:

Most European cathedrals show differences in plan or architectural style between parts built in different generations by different builders. The later builders were tempted to ''improve'' upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of
God.

Against these, the architectural unity of Reims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.

Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

It's not that I don't like Chartres; indeed, there's something incredible about projects that outlive their original intent. But when it comes to the most compelling products & systems in my life, I find conceptual integrity to be a *really* powerful force.

See also: the last section in One type of swing, etc.

New TPR designs/drawings

Made some updates to the models for The Public Radio this weekend. Included:

• Made a full assembly model of the antenna. I had never done this previously, instead opting to let our suppliers make drawings. No more of that.
• Fully updated our speaker model to allow for easier mechanical assembly and thru hole mounting to the PCB. This has been in the works for a while, but I needed to remodel the basket fully - and rethink the way that the lid screws work. I also renamed the speaker "Ground up speaker." You know, because of the fact that we're redesigning it from the ground up.
• Added PEM nuts to the assembly (it was hex nuts before). I also adjusted the full screw stack so that it's fully supported throughout the assembly.
• Remodeled the knob to be metric. ISO FTW! (Also note that the drawings are all on A4 paper :)
• Did some basic housekeeping on the model, renaming and reorganizing elements to make maintenance easier.

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

I also did a bit of work to the EagleCAD - mostly just updating the speaker hole locations & sizes. Zach has done a bunch more work on this over the past few months; I'm mostly just dealing with mechanical interfaces here.

View fullsize

More on this soon, I hope :)

Exploration and explanation

Apropos of Displaced in space or time, and just generally along the lines of what I spend a *lot* of time thinking about these days, a few thoughts on Michael Nielsen's recent post titled Toward an exploratory medium for mathematics. Note that my comments are largely placed in the field of CAD, while Nielsen is talking about math; hopefully the result isn't overly confusing.

Nielsen begins by separating out exploration from explanation:

Many experimental cognitive media are intended as explanations... By contrast, the prototype medium we'll develop is intended as part of an open-ended environment for exploration and discovery. Of course, exploration and discovery is a very different process to explanation, and so requires a different kind of medium.

I've touched on the explanatory aspects of CAD in the past (see in particular Computer aided design), but I had never really considered the dichotomy between exploration and explanation in such stark terms. This is partly a result of the fact that most CAD software has documentation built right into it. I've spent a *lot* of time using CAD tools to document parts in both 2D (multi-view PDFs) and 3D (STEP, STL, etc), and have had long conversations with engineers who swear up and down that design tools that don't make documentation easy aren't worth the time of day. 

My inclination is to think that the future will be increasingly integrated - in other words, that the divide between exploration and explanation is antiquated. But perhaps it's more useful to consider the many ways that (multifunctional CAD systems notwithstanding) these two aspects of engineering really have very little overlap. After all, my own CAD software has distinctly different interfaces for the two activities, and the way that I interact with the design interface is very different from the way my manufacturing partners will interact with my design explanations. Perhaps these activities could split even further; I see no a priori reason that this would be harmful at all.

Anyway, onward. Again, Nielsen - now talking specifically about the exploratory side of mathematics:

What we'd ideally like is a medium supporting what we will call semi-concrete reasoning. It would simultaneously provide: (1) the ability to compute concretely, to apply constraints, and to make inferences, i.e., all the benefits we expect a digital computer to apply... and (2) the benefits of paper-and-pencil, notably the flexibility to explore and make inferences about impossible worlds. As we've seen, there is tension between these two requirements. Yet is is highly desirable that both be satisfied simultaneously if we are to build a powerful exploratory medium for doing mathematics. That is true not just in the medium I have described, but in any exploratory medium.

I'll just pause here to say that this idea of "semi-concrete reasoning" is fantastic. Humans are quite capable of holding conflicting values at the same time; if computers are to be our partners in design, they'll need to do some analog of the same.

Instead of using our medium's data model to represent mathematical reality, we can instead use the medium's data model to represent the user's current state of mathematical knowledge. This makes sense, since in an exploratory medium we are not trying to describe what is true – by assumption, we don't know that, and are trying to figure it out – but rather what the user currently knows, and how to best support further inference.

Having adopted this point of view, user interface operations correspond to changes in the user's state of mathematical knowledge, and thus also make changes in the medium's model of that state. There is no problem with inconsistency, because the medium's job is only to model the user's current state of knowledge, and that state of knowledge may well be inconsistent. In a sense, we're actually asking the computer to do less, at least in some ways, by ignoring constraints. And that makes for a more powerful medium.

On this point, I agree that inconsistency itself isn't an issue at all - so long as it's made explicit to the user at all times. If a design fails to meet my needs for, say, manufacturability, then I should have some way of knowing that immediately - whether or not I choose to deal with it now or ever. Again, Nielsen:

Ideally, an exploratory medium would help the user make inferences, give the user control over how these inferences are made, and make it easy for the user to understand and track the chain of reasoning.

Yes.

Using the medium to support only a single stage of inference has several benefits. It naturally makes the chain of inference legible, since it mirrors the way we do inference with paper-and-pencil, every step made explicit, while nonetheless reducing tedious computational work, and helping the user understand what inferences are possible. It's also natural psychologically, since the user is already thinking in terms of these relationships, having defined the objects this way. Finally, and perhaps most importantly, it limits the scope of the interface design problem, since we need not design separate interfaces for the unlimited(!) number of possible inferences. Rather, for every interface operation generating a mathematical object, we need to design a corresponding interface to propagate changes. That's a challenging but finite design problem. Indeed, in the worst case, a “completely manual” interface like that presented earlier may in general be used.

With that said, one could imagine media which perform multiple stages of inference in a single step, such as our medium modifying ss in response to changes in the tangent. Designing such a medium would be much more challenging, since potentially many more relationships are involved (meaning more interfaces need to be exposed to the user), and it is also substantially harder to make the chain of reasoning legible to the user.

Even with the simplification of doing single-step inference, there are still many challenging design problems to be solved. Most obviously, we've left open the problem of designing interfaces to support these single stages of inference. In general, solving this interface design problem is an open-ended empirical and psychological question. It's an empirical question insofar as different modes of inference may be useful in different mathematical proofs. And it is a psychological question, insofar as different interfaces may be more or less natural for the user. Every kind of relationship possible in the medium will require its own interface, and thus present a new design challenge. The simplest way to meet that challenge is to use a default-to-manual-editing strategy, mirroring paper-and-pencil.

I recognize that this is a somewhat long quote, but I think it's really critical. To paraphrase: Designing a UI that allows for multidimensional problems is *hard,* and it's hard for human users to glean actionable information from multidimensional data. 

Instead, we should break UIs up into discrete steps, allowing users to visualize and understand relationships piecewise. This means more individual UI modalities need to be designed, but by defaulting to manual editing strategies - which are damn good (viz. paper and pencil) to start with - even that task becomes manageable.

There's a lot here; I recommend reading the original post in its entirety.