That Feeling When…

You know that feeling when you realise you may be a little bit outside the design envelope for your gear? That.

I was on the Bianchi, my gravel bike, not my full-sus fat-tyre MTB, when I ran into a stretch of uncleared road. I thought it was just two corners' worth, but it turned out to be quite a bit more than that, and icy underneath the snow.

Not bad for the last ride of the year!

Tech and distribution

We are in the middle of an under-recognised moment of change in the way software is paid for and in what makes a software product successful or not. Let me lay out my reasoning for what this transition is, and what it will mean in the near future.

The Past

Once there was a market for software at all, the key to success was control of the distribution channels. This was the main chokepoint — or opportunity, depending on how you look at it — because most people accessed technology via their work, so controlling the corporate purchasing decision was crucial. Nobody was going to engage in BYOD, Shadow IT, or any of the other hobgoblins of command-and-control central IT departments in the days when you needed a forklift to bring your own device into the office, probably from a loading dock.

Today

The situation most people are familiar with these days is one in which the terms of the relationship I described above have everted, with platforms people chose for themselves becoming adopted as corporate standards. The breakout moment was probably when people started buying their own iPhones instead of corporate-issue Blackberries, or maybe it was MacBooks instead of boring Dells. The best current example would be Slack, which gets adopted for free by small teams, or perhaps even experienced first as the platform for a side project, in the same way that people might have used IRC a couple of decades ago.

In this market, developers are the new kingmakers, not purchasing departments that mainly work to get the thing developers already chose on better terms. The key to success if you want to sell to the enterprise therefore is controlling the hearts and minds of those developers.

The Future (Coming Fast)

While people are still fighting over the details of the present (and to be sure, while pockets of the past still exist here and there), the wave of the future is already building. Here's the short version: democratisation of tech means line-of-business people can focus on the job to be done and route around developers who just want to play with the latest cool tech toys.

Some of the enabling technologies are out there already. Here are some signs and portents:

Another example would be Slack, a great success for the earlier model, but one whose inherent nature will prevent it from being successful in the same way in this future. The modular architecture that makes techies love Slack (the integrations! the bots! the custom emojis!) actually slows down the non-techies who just need to get their jobs done. By contrast, Teams' integrated platform largely gets out of the way and lets them get on with it. The techies mutter and complain about the insufficient quality of each of the constituent modules, but the integrated platform is rapidly winning the market. In the words of Aaron Levie of Box, "Salesforce is blowing past traditional departmental boundaries" and selling directly to new users within their existing customer organisations.

In other words, Slack tried to kill email, but ended up becoming email — and as I wrote back in 2016, email has a long head start and is just generally much better at being email:

most would-be email killers are walled gardens, consisting of a service that is tightly integrated with its client app and does not allow third-party clients. This makes it much harder for innovation to happen, because there is only one provider, and they deliver only the functionality that they want and can build. If you want a feature to be added to Slack, you can’t build your own Slack client; you have to petition Slack to do it, and they choose whether to implement that feature or not.

In the end, Slack, like email, became a feature. This is why the real benefit for Salesforce in its acquisition of Slack is consolidation and the end of modular, piecemeal acquisitions of SaaS products by companies.

The Pendulum Swings

This change is part of a natural pendulum process, from integration to modularisation and back, but with the points of integration and modularisation changing. What is differentiating can be a module that is valuable in its own right, but once it becomes table stakes, the conversation moves up a level to the integrated platform that module is a part of.

Developers should not feel bad about no longer being in charge; the benefit is that they are also no longer on call to fix those things when they break. There will always be a role for developers, but in the same way that there is more to choosing a car than its horsepower or efficiency, other considerations come into play for business users when they are selecting a tool for their everyday use.

The new role for IT is to remain a part of the process, studying and advising, but ultimately it's the users who decide — as it should be.

The Long Way Round

I had the day off today, but the kids were all in school — so I jumped on my bike and went looking for some sun.

I did at least get out of the fog as soon as I started climbing out of the plain, but despite a couple of attempts, the sun never did quite make it through the overcast.

Why do I ride a gravel bike? Precisely so I can do rides like this, with a long on-road approach, and then a fun bit at the top.

To be honest around here I would have been much better off with proper fat mountain-bike tyres; the Kendas on my Bianchi are pretty good for what they are, but they weren’t quite up to literal rivers of snowmelt coming down the path I was trying to ride up — so I stopped for a quick photo op and a breather.

The long way down, back on tarmac.

This sort of thing is good for the soul — that, and the shower beer I allowed myself when I got home… Cheers!

Why The M1 Won't Kill The iPad Pro

Quick, it's happening again!

This is my third CPU architecture transition since I've been a Mac user. I started on the 68k, with the weedy 68020 in my first Mac LC. When Apple moved to PowerPC, I cajoled my parents into getting a 603e — still relatively weedy in the context of the dual 604s I got to play with at work, but a massive upgrade from the LC. By the time of the Intel transition I was out of the Apple fold — I couldn't afford one as a student, and later prioritised gaming and dual-booting with Linux.

However, when the MacBook Air launched — yes, the very first one, with the 11" screen, no ports, and no power — I spent my own money rather than use the massive corporate-issue Dell that was assigned to me. Since then I've never looked back; every work computer I've had since that tiny MacBook Air has been a MacBook. My personal computer is my iPad Pro, but I also have a 2nd-gen Mac mini1 which runs headless to take care of various things around the house. An upgrade to SSD and maxed-out 16 GB of RAM keeps it chugging away, nearly a decade in.

When Apple announced the new M1-based Macs, I was blown away like everyone else by the performance on offer. I was particularly relieved to see the M1 Mac mini in the line-up, not because I have any urgent need to upgrade, but just to know that it remains a product in Apple's line-up, for whenever I might need to upgrade in the future. In the same way, I'm not pushing for an early upgrade of my work-issued MacBook Pro, because one of the must-haves for me is support for multiple monitors. I'm assuming that will come with the rumoured 14" Pros that are more clearly differentiated from the Air, so that's what I'm waiting for there.

Most of the commentary is trying to differentiate between the new Air and Pro, and figuring out whether to replace an iMac Pro (or even a Mac Pro!) with the M1 Mac mini. Some, though, have gone the other way, comparing the new MacBook Air to the iPad Pro. The article's conclusion is that "Apple's M1 MacBook Air kills the iPad Pro for the rest of us", but I'm not so sure.

Over-reach

My iPad is a substantially different device from my MacBook, and it gets used for different things, even when I have both within arm's reach. Let's dig into those differences, because they are key to understanding what (I think) Apple's strategy will be for the Mx MacBook and the iPad Pro in the future.

Form Factor

All of the comparisons in that ZDNet article are comparing the big 12.9" iPad Pro to the 13" MacBook Air — which is fair enough on the MacBook side, since that's what Apple has announced so far. On the iPad side, though, most people have the smaller size — currently 11" — and that is the more meaningful basis for differentiation. We'll see whether that changes when and if Apple ever releases a successor to my beloved MacBook Air 11", or SWMBO's (just) MacBook 12", aka the MacBook Adorable — but for now, if you want an ultra-portable device without sacrificing power, the smaller iPad Pro still has an edge.

External Display

Seriously, who connects an external display to an iPad? AirPlay is far more relevant for that use case. Meanwhile, I'm actually more bothered about the fact that no M1 MacBook allows for more than one monitor to be connected.

Webcam

This is a long-standing weak point of the MacBook line, and it's going to be hard to remedy simply due to physics. A better webcam requires more depth, meaning a thicker cover around and behind the screen. Again, though, the use case matters: it's more important for the iPad to have a good built-in webcam, because a MacBook is more likely to have an external one for people who really do care about image quality, resting on top of that external monitor. People who use their MacBook for work care a lot less about image quality anyway, because they may well be looking at a shared document rather than headshots most of the time.

What's Missing

A surprising omission from the list of differences between MacBook and iPad is the operating system. iOS — or rather, iPadOS — is a big differentiator here, because it affects everything about how these devices are actually used. This is the same mistake as we see in those older PC reviews that only compared the hardware specs of Macs to Wintel devices, missing out entirely on the differentiation that came from running macOS as opposed to Windows.

Confusion

I think the confusion arises from the Magic Keyboard, and how it makes the iPad Pro look like a laptop. This is the foundational error in this list of recommendations to improve the iPad Pro.

Adopt a landscape-first mindset. Rotate the Apple logo on the back and move the iPad’s front-facing camera on the side beneath the Apple Pencil charger to better reflect how most people actually use their iPad Pros.

No! Absolutely not! I use my iPad in portrait mode a lot more than I use it in landscape! Does it bug me that the Apple is rotated when I'm using it with the keyboard? Sure, a little bit — but by definition, I can't see it while I'm doing that.

Release a new keyboard + trackpad case accessory that allows the iPad to be used in tablet mode without removing it from the case.

Now this one I can stand behind: I still miss my origami keyboard case for my iPad Pro, which sadly broke. You could even rotate the Apple logo on the case, while leaving the one on the device in its proper orientation, if you really wanted to.

The reason I still miss that origami case is that I didn't replace it when it broke, thinking I would soon be upgrading my iPad Pro, and I would get a new keyboard case for the new-style flat-edge case. Then Apple did not refresh the iPad Pro line this year, so I still have my 10.5" model.

I do wonder whether this could be the reason why the iPad Pro didn't get updated when the new iPad and iPad Air did. That is, could there be an even better one coming, that differentiates more clearly against the M1 MacBook Air?

Then again, Apple may be getting ready to release a convergent device: a fold-over, touch- & Pencil-enabled MacBook. They would never tell us, so we'll just have to wait and see, credit cards at the ready.


  1. Yes, that really is how you're supposed to capitalise it. No, really

Hipster Bike Downtown

In my last bike post introducing the Bianchi, I mentioned that I had turned my previous steed into a single-speed city runabout. Well, today I was out running an errand astride said hipster conveyance, so I thought I’d get a pic of it too.

I love how the conversion turned out. The flat bars are raised up by flipping the stem upside-down, so it’s actually a pretty comfortable thing to ride. It’s also still a very light bike, with its carbon fork and all, so it’s nippy and manoeuvrable around town. The old Campagnolo drive train was completely shot, and these days a gravel bike frame that won’t take disk brakes is basically unsaleable, so this is a better fate for my old Rat — even if it does mean that I now own more bicycles than the rest of the family out together!

Appropriately enough for such a bike, what I was doing out and about was buying fresh-ground coffee from my coffee roaster. The shop is a couple of streets back from the square in the photo, but they have a century-old roaster, and when it’s running you can smell the coffee clear to the square!

Say Comma Again, I Dare You

For my sins, I have been working with CSV files in Excel again — and it's giving me an aneurysm, as usual.

If you haven't had the (dis)pleasure, here's how the Import wizard works in Excel. You do File > Import, and choose CSV — so far so good:

Now, make careful note of the explanation: "Text files that contain comma-separated values".

Here is where the insanity begins: the wizard somehow decides that my text is not actually comma-delimited, as per the description above, but fixed-width:

I have no idea how the wizard arrives at this conclusion, because it does it for every single CSV file I have ever fed it.

Having reassured the wizard that no, I really do want my text delimited by characters such as, oh for instance commas because this is a file of comma-separated values — guess what the default character is that the wizard suggests?

Sure. Tabs. Not commas, for the file of (once again) comma-separated values. Tabs.

Now this might look like yet another minor annoyance, merely the latest in a series of papercuts that we have to deal with when we work with computers — but it's also a particularly egregious example of why people hate computers so much.

Three Reasons Why This Is a UX Disaster

A computer should never ask the user a question to which it can work out the answer. It should have sane defaults, that work for most users most of the time. Finally, it should implement the user's inputs faithfully.

This wizard falls down on all three fronts:
1) It's a CSV file, you should know it's going to be comma-separated; why are you asking me?
2) Given that it's a CSV, the default should be to import the contents as comma-separated values, not tab-separated. Maybe have an Options button somewhere for weird edge cases, but the default flow if the user hits OK on every screen should make sense for the most usual case of a CSV file containing comma-separated data.
3) Gaslighting the user like this on every screen is just not acceptable. I feel like I'm trying to figure out how to avoid signing up to a junk mailing list, not using an ostensibly professional-grade, market-validated piece of software.

If you're writing even a simple program, at some point you're going to have to figure out inputs and what to do with them. Please, I implore you: do better than Microsoft.

Gravel Bike In Its Natural Habitat


My old gravel bike — an original Cinelli Racing Rats set — had eaten its Campagnolo running gear, so I was due a new bike anyway. Then the government announced a fund to support alternative forms of transportation, effectively price support for bikes, so I dived in. I ordered this Bianchi Via Nirone 7 gravel bike in July and it didn't arrive until mid-November, so only just in time for the subsidy cut-off date! Then what with one thing and another, this was the first time I actually got to take it out, but I am very happy with both look and feel.

The one aspect that is not 100% spot on is that the wheels feel disproportionately heavy. I'm not sure whether this is the Kenda tyres — I've only ever seen the brand on e-bikes, where weight is not the primary consideration — or the wheels, which are generic. Maybe I'll look out for a discounted wheelset in the new year sales and try my go-to Schwalbe Marathons on them, and see what that does for me.

And the Cinelli? Oh, it's still part of the family; I swapped the worn-out Campy drivetrain for a fixed-gear setup, put straight bars and flat pedals on it, and now it's my hipster city runabout. I'll get a pic of that on our next expedition.

Three Car Garage

Here’s a fun little game: the perfect three car garage, but with a twist compared to the last time I played the "dream garage" game: one car has to be from the year of your birth, one from the year you first got your driver’s license, and one from the current day.

Here’s my line-up; what’s yours?

1980: Porsche 911 SC (Super Carrera)

I’d want to do a bit of work on this one: I’m not a fan of those hooded headlights, the stance is all wrong by today’s standards, and the bumpers would have to go as well. The main ingredients are all present and correct though, with a three-litre aluminium engine block, a five-speed gearbox, and those classic Fuchs wheels.

It turns out, there is not a huge amount of choice in 1980, falling in between the hangover from the 70s oil crisis and the coming over-the-top 80s, but you can never go wrong with a 911.

1998: Lamborghini Diablo SV

There’s a bit more choice in 1998, and in fact a couple of perfectly acceptable alternatives would be the Ferrari F355 or the Lotus Elise S1 — but with the 911 to play the role of the serious car, a Diablo is the biggest and baddest toy out there. It’s having a bit of a moment too, with a Diablo being wrecked during filming for Top Gear.

1998 is actually another gap year, as I just miss the Bugatti EB110, my all-time favourite supercar, while the likes of the Ferrari 360 are yet to come, but I wouldn’t feel too left out with a Diablo. I mean, take a look:

Current day: Audi RS6

Yes, same as last time, what of it? All of the power, all of the practicality, no compromise whatsoever — as long as you can afford the quite substantial cost, that is.

Here’s another video, with another Top Gear connection:

Yes, I think I could live with those three…

Next step: Competition!

An extension to this game is to find competition cars from those same three years.

1980: Fiat Abarth 131

Gotta have that Alitalia livery! Or alternatively, I’d be tempted to build one out kaido-racer style. The silhouette is not too dissimilar from an 80s Nissan Skyline… Imagine a 131, dropped on tiny gumball wheels, with even more over-the-top aero, one of the headlights replaced with a hole to let radiator hoses through, and so on. Japanese-Italian fusion done right, to avenge the insult of the Alfa Romeo Arna!

1998: Mercedes-Benz CLK GTR

Okay, this is a Straßenversion, because by 1998 race-car decals were getting pretty ugly, but still, look at it.

Current day: ???

To be honest I’ve fallen off the bandwagon of following motorsports, so I don’t have an entry here. If forced I would probably go with whatever James Glickenhaus is building, but it’s all getting a bit too silly for me to get much emotional involvement.

Serving Two Causes

My current gig involves making comparisons between different products. It’s mostly interesting, and helps me understand better what the use cases are for all of these products — not just how they are built, but why. That double layer of analysis is what takes most of the work, because those two aspects — the how and the why — are never, ever documented in the same place. I spend a lot of time trawling through product docs and cross-comparing them to blogs, press reports, and most annoying of all, recorded videos.

Fundamentally, most reviews or evaluations tend to focus either on how well a product delivers its promised capabilities, or on how well it serves its users’ purposes. Those are not at all the same thing! A mismatch here is how you get products that are known to be powerful, but not user-friendly.

One frequent dichotomy is between designing to serve power users versus novices. It is very very hard to serve both groups well! The handholding and signposting that people require when they are new to a product, and perhaps even to the entire domain, is liable to be perceived as clutter that gets in the way of what more experienced users already know how to achieve. The ultimate example is between graphical and command-line interfaces: the sorts of pithy incantations that can be condensed into a dozen keystrokes at a shell prompt might take whole minutes of clicking, dragging, and selecting from menus in the GUI. On the other hand, if you don’t know those commands already, the windows, menus, and breadcrumbs, perhaps combined with judicious use of contextual help, give a much more discoverable route to the functionality.

Ideally, what you want to do is serve both user populations equally well: surprise and delight new users at first contact, but keep on making them happy and productive once they’re on board.

Two Tribes Go To War: Dev and Ops

There are two forces that are always tugging IT in different directions: stability, maintainability, and solid foundations (historically, this has been called Ops), versus ease of building and agility (this one is Dev). Business needs both, which is why Gartner came up with the idea of "bimodal IT" to describe the difference between these two approaches.

For more on this topic, listen to Episode Ten of Roll For Enterprise, digging into how come "legacy" became a dirty word in IT.

The problem, and the reason for a lot of the pushback on the mere idea of bimodal IT, is that most measurement frameworks only evaluate against one of the two axes. This is how we get to the failure modes of bimodal: the cool kids playing with new tech, and boring, uncool legacy tech in a forgotten corner.

Technologies can be successful while concentrating only on stability or only on agility, depending on target market; think of how successful Windows was in the 95-98-ME era despite tragic levels of instability, or for a more positive example, look at something like QNX quietly running nuclear reactors. However, in most cases it’s best to deliver at least some modicum of both stability and agility.

It’s About Time

Another factor to bear in mind is the different timescales that are in play. The lifetime of services can be short, in which case it’s okay to iterate rapidly & obsolesce equally rapidly — or more pithily, "move fast and break things", without slowing down to update the docs. On the other hand, the lifecycle of users can be long, if you treat them right at first contact. This is why it’s so important to strike a balance between onboarding new users quickly and servicing existing ones. If you turn off new users to please existing power users, you’ll regret it quickly; by definition, there are more potential users out there than existing ones. The precise balance point to aim for depends on what percentage of the total addressable user base already adopted your service, but there will always be new or more casual users who can benefit from helpful features, as long as they don’t get in the way of people who already know what they’re doing.

There’s no easy way to resolve the tension between agility and stability, speed of development and ease of maintainability, or power-user features and helpful onboarding. All I can suggest is to try to keep both in mind, because I have seen entire products sunk by an excessive focus on one or the other. If you do decide to focus your efforts on one side of the balance, that may still be fine — just as long as you’re conscious of what you’re giving up.


🖼️ Photos by MILKOVÍ and Aron Visuals on Unsplash