Friday, November 28, 2025

A Bus Ride and the (At Least) 3x UX FAILs

© 2025 Peter N. M. Hansteen

Norway is digital to a fault. That is why attempting to buy the ticket for a bus ride can reveal a cascade of user experience (UX) failures.

Most days, I either take a half hour stroll to get to my main customer's offices, or work from home. But occasionally, I need to visit my employer's offices. On those days, I take the bus for an easy 20-ish minutes ride.


Note: This piece is also available without trackers but classic formatting only here.
This week, a few meetings and an internal session on UX Design were scheduled at my employer's site, so after my usual morning routine of making coffee, feeding the cat and going over overnight mail and news, I got ready to head out to the office.

On the way out the door, I opened the tickets app from our local bus company Skyss on my Android phone, selected the single ticket option, went on as usual to select Vipps as the payment method and cleared the authentication steps before locking and putting the phone away.

Some unrelated alert buzzed on the phone and had me unlock it again, only to see that the payment had failed with an Unknown error message.

I had been on the way out the door when the transaction was initiated, so I suspected that perhaps the network change from my home WiFi to Telia 5G had somehow disrupted connectivity. That would be a rare occurence, but has happened.

So I tried completing the transaction again, only to get the same result. After a couple of more tries, the bus turned up and I got on my way.

So yes, I had technically taken a bus ride without paying. That means I in principle owe Skyss something like NOK 41.32 and would be at risk of getting fined something like NOK 950 if caught by the ticket inspectors without a proof of payment.

No inspectors turned up, however, so my day went on to some customer work performed remotely from the office, meetings and finally the main item of the day which was a short, compact, intensive but also quite interesting and inspiring session on UX design work.

The UX session concluded, and we went on to some socializing over pizza and refreshments.

Then, naturally, came the time for my bus ride back home. Once more I tried to purchase a single ride ticket via the app, only to be presented with the exact same error.

Unknown error.
And no way to get any details on what the actual error was.

So I got on the bus, again without completing a transaction, so my debt to Skyss would now have roughly doubled, and again I ran the risk of getting fined, should the inspectors turn up.

At this point my main suspect for the source of the failure was the Vipps app.

For context, the Vipps smartphone app is very close to being the default payment method in Norway, even more so for transactions involving online payments. Any failures or problems of any kind involving the Vipps service are almost guaranteed to make headlines with strongly worded articles and aggressively ugly comment threads.

So when I got back home, I opened the Vipps app on my phone, only to find that instead of its usual transaction UI I was presented with a question about whether I was a politically exposed person, with the options to answer basically, "Yes", "I was one previously", and "No".

But no way to bypass the prompt and perform a payment or other transaction.

The answer was obvious, but once I entered the answer, I was only taken to a screen with a single option, Update, presumably to update the app to a newer version.

Pushing the Update button took me and my Android phone to the Play store entry for the Vipps app, which offered the option to Open the app or to install it on my Android tablet in addition to my phone.

Choosing to to Open the app only took me back to the same single-option Update screen, in a perfectly circular progession.

So after failing to find any other option, I ended up uninstalling, then reinstalling the Vipps app.

Which of course involves a completely new setup. Fortunately (or perhaps worryingly from a privacy perspective), the app managed to connect itself to my main bank account, inferred from my national ID number, which is a required bit of information in the sign-up process.

So UX fail #1 was in the Skyss app, where the developers had apparently trusted the Vipps app to either never fail or at least fail in some obvious way, so displaying any information from Vipps was deemed not necessary.

UX fail #2 would likely go to the developers of the Vipps app, who seem to have assumed that users will only ever interact with their system directly, never through a third party app that uses Vipps as the payment back end. Or perhaps the Skyss developers screwed up their app's API interaction with the Vipps app, possibly hooking in the app when they really should have been talking to the Vipps back end instead.

Finally, UX fail #3 goes clearly to the Vipps team, who appear to have failed to test the sequence of events that will be triggered by their Update button in the app. Whatever they did test apparently did not involve any recent-ish Android phone from those too-big-to-fail Koreans.

While an Internet greybeard like myself was able to figure out that the app needed to be dealt some minor violence, I can only imagine the utter puzzlement any less (Internet) digital native senior citizen of actually pretty much the same age as myself would have experienced when met with this exact scenario.

Bonus Track: Adobe Does This Too, With AI

For the developers I have just chided for not doing their jobs properly UX-wise, there might be some consolation in knowing that they are not alone in producing UX failures.

Returning readers will be aware that The Book of PF, 4th edition is coming soon (also here), and we have reached the time when the thing is in the last rounds of proofing.

For reasons probably best explained by the publishers' production team, the application we use for final proofing and related annotations is Adobe's Acrobat. A few years ago I decided that macOS is BSDish enough that I will use it quite a bit, so installing the no direct cost version of the app on a system within reach was a fairly painless excercise. As was the initial proofing round and an intermediate one.

Then when the PDF for the final proofing cycle arrived, and I loaded the two hundred and fifty-some pages PDF, I discovered that Acrobat had acquired an AI Assistant component.

When the progress indicator showed that the file was ready to display for my final proofing round, the Acrobat AI Assistant oh-so-helpfully prompted me with

This looks like a long document. Would you like to see a summary instead?

Granted, my use case here is possibly not the typical one for a user of the gratis version of Acrobat.

But I will award Adobe the UX fail #4 bonus prize here, a UX FAIL because AI, for failing utterly to consider that some people do, in fact, create long-ish documents and prefer to see them in the full.


A Bus Ride and the (At Least) 3x UX FAILs is © 2025 Peter N. M. Hansteen (published 2025-11-28)
You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

Friday, November 7, 2025

What is BSD? Come to a conference to find out!

© 2025 Peter N. M. Hansteen

What is BSD? It's where the Internet comes from!

Berkeley Software Distribution (BSD) is a family of computer operating systems derived from the software developed at the University of California at Berkeley from the late 1970s through the early 1990s.

You may or may not be aware that the BSD code still powers a lot of things, and we meet up regularly for conferences. More about conferences later, first a little history to set the context.

A short history of the BSD operating systems

The history of the BSD family of operating systems is to a large extent the history of the Internet itself. You may have heard of the time back in the 1980s when the likes of IBM and Digital were slugging it out in the corporate IT sphere and the US department of defence paid for experiments in distributed, device independent networking.

That's when a loosely organized group of hackers somewhat coordinated by researchers at University of California's Berkeley campus rose to prominence with "BSD Unix", which by a sequence of happy accidents became the home of the reference implementation of the TCP/IP internet protocols.

By the early 1990s, commercialization of the Internet had started, and the Berkeley Computer Science Research Group (CSRG) that had coordinated the efforts was set to be disbanded. In addition to the net itself, the main tangible product out of Berkeley was the Berkeley Software Distribution (BSD), often distributed on tapes in the mail but also available on the net itself, which had started as a collection of software for AT & T's Unix but had over the years been extended become a full featured Unix operating system.

Several different groups wanted BSD to go on even if the CSRG did not, and several things happened in fairly rapid succession:

  • Lynne and Bill Jolitz ported BSD to Intel x86 (actually 80386sx), creating 386BSD. This was chronicled in a series of articles in Dr Dobbs' Journal (also see a more condensed summary over at salon.com)
  • Next up, hackers started sharing improvements to the 386BSD code as "patchkits", eventually forming two separate groups that took the work further to form their projects: The FreeBSD group would be working on bringing the best possible BSD to PC-style hardware, while the NetBSD group's ambition was to make BSD run on any hardware they could get their hands on.
  • A group of former CSRG employees formed BSDi Inc. and marketed their product BSD/386 with among other things a contact phone number "1-800-ITS-UNIX". The activities of an actual corporation in turn triggered a lawsuit from the owners of the UNIX trademark over code copyrights.

The lawsuit was eventually settled -- only six files of several thousand in the tree were 'potentially encumbered' and had to be replaced, leaving both NetBSD and FreeBSD with a rush to replace the code which was at least in part fairly central to the virtual memory subsystem.

That episode was however just a temporary setback, and by 1996 we also had OpenBSD, which forked off the NetBSD code base and formed the third main member of the BSD family, with a stated purpose to focus on security and correct code. Finally in 2003, the DragonFly BSD project forked off the FreeBSD code and became the fourth member of the family of open source BSD operating systems.

Code from the BSDs is widely used in Internet infrastructure and in numerous not too obvious contexts. In fact, all devices with TCP/IP Internet capability ran some derivative of the BSD code until alternative implementations started appearing during the early 2000s.

The likely most popular BSD variant is Apple's macOS, which shares a huge amount of code with the FreeBSD project. Modern BSD systems include DragonFly BSD, FreeBSD, NetBSD, OpenBSD, and, by some counts, Apple's macOS.

BSD code continues to be the base, however largely unsung, of significant technology development wherever the Internet is relevant. And you can even meet developers and practitioners at regional conferences every year!

The annual, regional BSD conferences

Most of the time, the development of the BSD systems is done by developers working by themselves or in small groups, in locations all over all inhabited time zones. However, by the early 2000s, a number of individuals in the various BSD communities started seeing the need for in-person meetups.

In addition to some projects calling up developers for hackathons, pioneered by the OpenBSD project, or developer summits, groups of interested parties including individual users and organizations started meeting up for conferences. The main regularly arranged BSD conferences are,

  • AsiaBSDCon, March timeframe, alternates between Tokyo (JP) and Taipei (TW). AsiaBSDCon 2026 will be March 19-22, 2026 in Taipei, Taiwan.
  • BSDCan, Mid May to mid June, Ottawa (CA). BSDCan 2026 will be June 17-20 in Ottawa, Canada.
  • EuroBSDcon, September timeframe, each year in a new European city. EuroBSDCon 2026 will be September 10-13 in Brussels, Belgium.

All three conferences will welcome submissions for talks, tutorials and other types of sessions as well as general participation by people regardless of geographic or other origin.

For further information, browse the conference websites.

We hope to see you there at future events!

Further reading

Explaining BSD on the FreeBSD documentation site

What every IT person needs to know about OpenBSD (part 1) at the APNIC blog site, continued in part 2 and part 3

DragonFly BSD project website

FreeBSD project website

NetBSD project website

OpenBSD project website


Historic project art follows: Left to right: OpenBSD, FreeBSD and NetBSD

puffy with so long and thanks for all the fish FreeBSD mascot Beastie as drawn by Poul-Henning Kamp The original NetBSD logo