McNelly: Change May Be Inevitable, but Some Design Changes Are Ill-Advised
Rob McNelly shares his thoughts on user experiences, both in tech and out in the world
Recently a user interface changed on software that I have used for many years. As I altered my muscle memory to accomplish once-simple tasks that I’d been doing for as long as I can remember, I wondered who reviewed these changes and whether, in some specific cases, they were even necessary. Certainly I’ve been through many interface changes over the years, and for the most part I was initially resistant. I suppose that’s a natural response, as we all regularly deal with this sort of thing in today’s world. However, with most of those prior instances, I quickly adjusted and found that my user experience really had been improved.
This sort of experience is not limited to tech. I thought similar things after a recent hotel stay. I spend a fair amount of time traveling for work and pleasure and have stayed in many places, but a shower door that only covered a portion of the shower area? That was an unwelcome first. Who thought that was necessary? Who reviewed those changes?
It wasn’t just me. I glanced at some of the hotel’s reviews and found numerous references to the bonkers bathroom layout:
“Whoever designed the bathroom did not have any sense! There is a half glass shower then it’s wide open. Water gets everywhere. It’s freezing!”
“Small quarter size shower door which allows for water everywhere. Also, the lights go out too fast. I was finishing my shower and the lights went out!!”
“The bathroom design is weird, a half window instead of a full guard or curtain for the shower/bathroom. The water gets everywhere on the floor. The shower head hangs from the ceiling and hangs low. You have to be around 5’10 or smaller, or you will be squatting to shower. The last thing about the bathroom is the light sensor shuts off too quickly or isn’t sensing unless you put your hand right in front of the sensor or the lights shut off, which is super annoying.”
Another issue with the hotel’s bathrooms was that the motion light always activated upon entering. So any middle of the night bathroom visit would trigger the lights at full blast, unless you made the effort to cover the sensor with duct tape.
I overheard guests complaining to the front desk and being reassured by the employees that changes would be made. My internal response to that was to imagine the redesign would get done in a snap if only hotel management were compelled to spend a night in those rooms. For that matter, did the designer of this bathroom ever have to try and use it?
Maybe it’s just me, but I see this as part of broader trend. There seems to be a tendency to implement ideas without conducting strenuous testing and seeking detailed feedback.
I recall Steve Jobs saying, “A lot of times people don’t know what they want until you show it to them. Start with the customer experience.” I understood what he meant with the transition from the Blackberry to the iPhone. I thought I wanted a physical keyboard, until I realized that I didn’t.
Of course, this isn’t always the case. Recently I came across a relevant comment about that Jobs quote: “Some executives read this and say, ‘I know better than the customer.’ Even when you’re good at what you do, it doesn’t mean you’re right about what people want.”
Whether it’s computers, buildings or anything else, design is complicated. And naturally, change is inevitable. Still, my hope is that with any design/redesign process, real thought is given to whether any specific change is necessary.
NIM Security Alert
IBM recently issued this bulletin about AIX vulnerabilities that can be exploited in NIM:
“Vulnerabilities in AIX could allow a remote attacker to execute arbitrary commands.
“Description (CVE-2024-56346): IBM AIX nimesis NIM master service could allow a remote attacker to execute arbitrary commands due to improper process controls.
“Description (CVE-2024-56347): IBM AIX nimsh service SSL/TLS protection mechanisms could allow a remote attacker to execute arbitrary commands due to improper process controls.
“To find out whether the affected filesets are installed on your systems, refer to the lslpp command found in AIX user’s guide.
“Example: lslpp -L | grep -i bos.sysmgt.nim.client
“IBM strongly recommends addressing the vulnerability now.
“AIX fixes are available. The AIX and VIOS fixes can be downloaded via https.”
IBM Withdrawing Access to ECuRep Directories
I’ve mentioned this previously, but as a reminder, it’s happening now:
“From Wednesday 2nd April 2025, IBM will initiate the gradual withdrawal of access, to ECuRep directories, using the following hostnames:
testcase.boulder.ibm.com
transfer.boulder.ibm.com
testcase-yellow.boulder.ibm.com
w3-transfer.boulder.ibm.com
“It will not be possible to upload to ECuRep directories during the time frames defined below. Access to upload to the directories will be restored outside these time frames.
1) On Wednesday 2nd and Thursday 3rd April 2025 from 8am EST to 12pm EST.
2) Between Monday 7th and Friday 11th April 2025 from 8am EST to 12pm EST.
3) On Monday 14th, Wednesday 16th and Friday 18th April from 8am EST to 4 pm EST
4) Access to upload to the Ecurep directories on the Testcase servers will be permanently disabled on Monday 21st April 2025.
“Description: Enhanced Customer Data Repository (ECuRep) provides the facility to exchange diagnostic data and is used, for example, when support specialists request that problem information, systems data, diagnostic data, etc. is sent to IBM.
“Currently data from Americas customers is uploaded into IBM ECuRep directories on testcase server using the following hostnames:
testcase.boulder.ibm.com
transfer.boulder.ibm.com
testcase-yellow.boulder.ibm.com
w3-transfer.boulder.ibm.com
“From 29th October 2024, uploads to ECuRep will be possible using the following hostnames:
www.ecurep.ibm.com (HTTPs)
ftps.ecurep.ibm.com (FTP over TLS)
sftp.ecurep.ibm.com (Secure FTP (SSH)
“From 10th March 2025 the use of the testcase server (testcase.boulder.ibm.com, transfer.boulder.ibm.com, testcase-yellow.boulder.ibm.com, w3-transfer.boulder.ibm.com hostnames) to upload data to IBM ECuRep directories, will be discontinued.”
Centralized Log Server Configuration; APAR on VIO Client I/O
* From IBM Support—Configure Rsyslog Server to Implement Client-Based Log Separation:
“This document explains how to configure centralized log server to store log messages which are forwarded from remote syslog/rsyslog clients, in client specific log files, in attempt to override the default behavior of accumulating log messages from different sources in one single log file.”
When I downloaded the package, I found myself on a site I didn’t recall using previously. Once I logged in, there were packages available including rsyslog, lsof, smb client, python, ntpv4, etc.
The doc explains how to get rsyslog working on the system. The link then explains how to update the /etc/rsyslog.conf file to get it to send logs from each machine to its own file.
* Also from Support—High Impact/Highly Pervasive APAR IJ53478 VIO client I/O may hang or fail:
Affected Domain: VIOS 4.1.1.0
Abstract: VIO client I/O may hang or fail
Description: On VIOS 4.1.1.0, VIO client I/O may hang, escalating to path loss and potential I/O failures. We have seen this mainly with Linux clients running high I/O workloads, including SAP HANA.