The Hello Machine

When I worked in telecommunications as an engineer (late 2000’s) Electronic Switching Systems had been pretty much taken over by software switching systems, but the hardware, closely coupled to that software, was still very much an important component.

While the call switching and routing was no longer achieved by thousands and thousands of hardware relays switching dedicated connections between each “phone line”, the hardware operated the same.

The installation process was pretty much the same as in this video, recorded in 1974. Pretty much everything done in this video was still being done 35+ years later.

The thousands and thousands of interconnecting cables connecting each hardware module were still needed. The teams of men (99% of my colleagues were men) were still needed to “dress” the cables. This jobhad been outsourced to “installation” companies who employed teams of men – usually a foreman (“gaffer”) and his team of often young fellas – would travel to each datacentre, stay for 5-6 days and carry out the installation of the hardware, the cables.

It was then the job of the “commissioning” engineer to manually check all the hardware and cables were correctly connected and seated. This was a laborious and tedious job which took days.

Then came the software commissioning – configuring the software manually building up thousand of commands line-by-line for the logical connections for the “telephone lines”, the call-tree rules for call switching and routing, what telephone connection to use for what type of call.

Once this was done, then loading the system configuration for the particular client network.

Wire wrapping a huge DSX frame with thousands of connections, by hand or with an electrical tool – took knowledge, a certain manual skill – nimble fingers, experience and attention to detail.

A DSX frame from the front
The same small DSX frame from behind where you had hundred of wire-wrapping posts, each needing to be wrapped manually.

At the time I didn’t fully appreciate the craftsmanship involved in the process – attention to detail and pride in their work the installation technicans had – and the sense of achievement you got when you had commissioned fully (either single handedly or more likely as part of a team) a huge piece of equipment.

The level human-computer interaction was pretty much as low as it could go (without going to machine langauge) – the commands executed by engineers was referred to collectively as “MML” – man-machine language.

Being “so close” to the actual hardware being able to see the blinking lights, the increase/decrease in the fan speeds – carrying people’s important telephone calls, SMS messages – gave a certain sense of awe.

Today the hardware is commercial-off-the-shelf computing servers like IBM Bladeservers. They’re essentially no different to a high-capacity webserver, mailserver, or router. The sense of awe is still there but it’s hidden in the software.

Instead of requiring separate teams of people for the installation, commissioning it’s now reduced to 1, maybe 2 people.

Amazon “purchase MP3 album” dark pattern?

This morning I was listening to some Divine Comedy while I was working. I realised I didn’t have the album in full, so I thought I’d buy it online in MP3 format.
Purely due to muscle memory I always go to Amazon. I really should get better a buying music from other places.

So I searched for the album. Up it popped, in CD format. That’s OK, I know I can choose MP3 format.

After 2-3 clicks I then realise I’m somewhere completely different and am being offered their streaming instead for Β£7.99. How did that happen. So I back track…
Is this a dark pattern?

In case you can’t see it: I click on the button labeled “MP3 Β£7.99” and am brought to a page where the “Streaming unimited” button is selected.

This happens repeatedly.

How do GRC users create a new flowgraph?

During the approaching GNU Radio streaming weekend, we’ll be doing some UX Design work.

The design challenge we’re going to tackle is the process for users to create a new GRC flowgraph.

I’ve created this short survey to get a better understanding of how GRC users currently create a new flowgraph, and the run it.

Practical advice for speakers at FOSDEM 2021 Open Source Design devroom

Here’s some practical advice for speakers at our Open Source Design devroom at FOSDEM 2021.

1. FOSDEM organisers recommend using OBS to record and edit your talk video. This how-to gives useful advice. (https://dev.to/erikaheidi/how-to-use-obs-studio-to-record-or-stream-live-presentations-474j)

2. We recommend you recording and editing the video as soon as possible.

3. Don’t overload your slides. Make sure everything is readable when scaled down slightly. The 1280×720 video you send in might or might not be scaled down to fit onto a FOSDEM template!

4. Make sure your video presentation fits into your 20 minute assigned timeslot with room to spare for questions and answers. FOSDEM 2021 works on a strict broadcast schedule. The FOSDEM systems will ruthlessly cut you off at the end of your timeslot!

The Open Source Design group recommends you talk for 15 minutes and leave 5 minutes for questions and answers.

5. You must upload your talk video yourself to the FOSDEM system – we will send this to you in the coming days.

Your recording video format must follow these technical requirements:

resolution: 1280×720
frame rate: 25 fps
video codec: h264 video codec, main profile
video bitrate: <= 2Mbit/s
audio codec: aac audio codec
audio sample rate: 48 KHz mono
audio bitrate: 128 Kbit/s
media container: whatever is easiest for you

Helpful tip –

When you upload the video, the FOSDEM upload system will verify that your video file meets the above constraints. If it doesn’t, the video will be transcoded first, but this will take longer.

If you have issues with the video upload we recommend first comparing video details with the above requirements. If you need help, you can ask your Devroom Point of Contact.

What languages do Cloudron users speak?

The objective of this quick survey is to get some understanding of what languages are spoken by Cloudron users. You can find out more about translation work in this forum link.

The data gathered will be shared on the Cloudron forum.

NB: This survey has been created by Bernard Tyers, a Cloudron user. I am not professionally affiliated with Cloudron in anyway.

Making a Python virtual environment on OS X

OS: Mac OS X Catalina 10.5.6
Python version: 3.9 (most up-to-date at this time and installed like this)
Package to install: guinness (Good things come to those who wait)

This is a reminder to myself on how to do create a virtenv.

pip3 install virtualenv
mkdir guinness
cd guinness
/Users/bernard/Library/Python/3.8/bin/virtualenv guinness
guinness/bin/activate
pip3 install guinness

### deactivate virtual environment
(guinness) bernard@machine guinness % deactivate

Installing Python on Mac OS X Catalina

(This is a reminder to myself, and maybe a help for someone else who might be in the same situation as me. The purpose was to be able to lint documentation I’m trying to update for the pip project work.)

This applies to installing “the latest” Python on Mac OS X 10.15.6.

I’ve used this helpful How-TO. Everything worked until the very end where brew couldn’t create a necessary directory:

Permission denied @ dir_s_mkdir - /usr/local/Frameworks

(no idea why!)

==> Summary
🍺  /usr/local/Cellar/openssl@1.1/1.1.1h: 8,067 files, 18.5MB
==> Installing python@3.9
==> ./configure --prefix=/usr/local/Cellar/python@3.9/3.9.0_1 --enable-ipv6 --datarootdir=/usr/local/Cellar/python@3.9/3.9.0_1/share --datadir
==> make
==> make install PYTHONAPPSDIR=/usr/local/Cellar/python@3.9/3.9.0_1
==> make frameworkinstallextras PYTHONAPPSDIR=/usr/local/Cellar/python@3.9/3.9.0_1/share/python@3.9
Error: An unexpected error occurred during the `brew link` step
The formula built, but is not symlinked into /usr/local
Permission denied @ dir_s_mkdir - /usr/local/Frameworks
Error: Permission denied @ dir_s_mkdir - /usr/local/Frameworks

I reran install python and got:

bernard@computer-number-6 ~ % brew install python 
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/cask).
==> Updated Casks
geekbench

Warning: python@3.9 3.9.0_1 is already installed, it's just not linked
You can use `brew link python@3.9` to link this version.

Solution (hack?)

The solution was to create the /usr/local/Framworks directory manually:

bernard@computer-number-6 ~ % sudo mkdir /usr/local/Frameworks

Then change the owner and group to mirror other directories (bernard:admin)

bernard@computer-number-6 ~ % sudo chown bernard /usr/local/Frameworks 
bernard@computer-number-6 ~ % sudo chgrp admin /usr/local/Frameworks
bernard@computer-number-6 ~ % ls -la /usr/local/                  
total 0
drwxr-xr-x   17 root     wheel   544 11 Nov 12:01 .
drwxr-xr-x@  11 root     wheel   352 12 Dec  2019 ..
-rw-r--r--    1 root     wheel     0 18 Sep  2019 .com.apple.installer.keep
drwxrwxr-x    3 bernard  admin    96  1 Apr  2019 Caskroom
drwxrwxr-x   63 bernard  admin  2016 11 Nov 11:39 Cellar
drwxr-xr-x    2 bernard  admin    64 11 Nov 12:01 Frameworks

And finally run the brew link command from above:

bernard@computer-number-6 ~ % brew link python@3.9            
Linking /usr/local/Cellar/python@3.9/3.9.0_1... 5 symlinks created
bernard@computer-number-6 ~ %

And then I could start what I wanted to actually do. πŸ™‚

Creating rapid CLI prototypes with cli-output

I’m working on the usability of pip (the official Python package manager) at the moment.

This short blogpost isn’t about how to design CLIs. It is about creating rapid prototypes with this tool – part “look at this useful tool, part “thank you Pradyun” part feature request list. πŸ™‚

Update

After putting together the feature request list below, Pradyun’s already updated cli-output with request 1 and 2 below. Reusable blocks, or repeatable blocks are a bit more work.

Prototyping CLIs

Prototyping commandline interfaces, for the non-developer, is not easy. While we have countless interface prototyping tools for graphical UIs, unless you can write code (Python, HTML/JS, etc), when it comes to commandline user interfaces, there’s little available.

One thing I have struggled with so far is being able to prototype commandline interfaces that look “real enough”, without it taking “a lot” of time.

I’ve tried making stop-motion videos, describing it in long verbose explanations, doing paper prototypes, but none of the work. A CLI is essentially an interactive scrolling text-only interface. Without that “motion” it is very difficult to prototype, without coding skills.

Pradyun Gedam, one of the pip maintainers, put together a nice tool to prototype commandline interfaces. It is essentially simulating a CLI in HTML and JS. Easy when you know how.

It allows you to do nice things like this:

prototyping commandline interfaces with cli-output

Feature list

1. Being able to include comments. Done!

As a CLI UX designer, I want to be able to write comments (which won’t show up in the cli output), so that I can include human-readable explanation or annotation in the output.

Things to think about: can I use common characters like `#`, `>` if they are going to be printed in a cli output? πŸ€”

2. Being able to easily repeat a large block

As a CLI UX designer, I want to be able to build output on previously drawn elements, so that it saves time.

I need to add a video here to show what I mean.

3. Being able to share the URL of a cli output prototype.

This would help so that I could share them in PRs, etc.

As a CLI UX designer, I want a weblink for each cli prototype I create, so that I can share them with people (in GH issues, users, etc).

Things to think about: I think using something like a pastbin unique URL (which allows editing) would be nice. I think something like how hastepin does URLs would be good.

4. Having the output scroll up like in a real terminal Done!

I need to add a video here to explain more.

5. Having reusable elements

As a CLI UX designer, I want to be have a number of elements I can use, so that I don’t need to build them from scratch each time.

Things to think about: It’d be nice to be able to reuse elements (for example a spinner) instead of having to redraw each `-`, `\`, `|`, `/` each time. For example, like you’ve created the spinner here. https://hackmd.io/@pradyunsg/HyyYzk5Lv

What elements? I think a spinner, and simple progress bar would be a great start.

Thanks!

Anyway, thank you Pradyun for what you’ve done so far. πŸ™πŸΎ

If you are a UX designer and you need to make quick CLI prototypes, I suggest you have a look.

A Python community announcement about our pip work

Sumana Harihareswara the pip PM put together a video for the Python community to tell them about our UX work on pip, the package manager.

Initially I was thinking “I hate seeing my face on video, I hate hearing my voice. This better not have ukelele music. I hate those kinds of videos.”

I liked the explanation she gave for wanting to do it – ‘so Python community, and users can see the human faces behind pip, that we’re real people’.
We often forget (me included) that, for the moment, it’s still humans that make most software.

I think the video turned out well, and people seem to like it.

Post categories

Posts archive

    Bernard Tyers, Proudly powered by WordPress.