All posts by Stephen Frein

Absurd Opinions

Interpersonal, ,

An absurd opinion is probably a misunderstood opinion.

If somebody whom you’ve known to be generally reasonable in the past suddenly takes up with some damn fool notion that nobody in their right mind would believe, then . . .

. . . you’ve misunderstood something about their position . Either you are incorrect about their stance, or they believe different facts than you do, and hence are drawing their conclusions from a different place than you are drawing your own. A simple misunderstanding of this type will be the case 999+ times out of a 1000. The fix is to go have a quick conversation with the person in question. That conversation is a pattern (a template solution for a common problem), and it will educate one or both of you very quickly. Wailing about the stupidity of the other person’s presumed opinion is an anti-pattern that wastes time and creates bad will.

Absurd opinions = misunderstandings to be surfaced and resolved. Bank on it. Act on it.

Setting Focus Without Interrupting User Typing

Code, User Interface, Web, , ,

Don’t set focus if the user has already been where you’re going to send them.

Many websites and web applications will set focus on page load, moving the cursor to some point at which it is presumed the user will want to start typing. This is especially common for search pages and login screens, and generally sensible in these contexts. However, developers should recognize that setting focus can be disruptive to users, and code intended to set focus should be made smart enough to detect when this would be inappropriate.

A blank login formAbove is an example of a typical login form, with fields for username and password. The designers of this site decided that they would set focus in the User Id field as soon as the page loaded, since most users are likely to want to login at this point. To do so, they implemented the following Javascript, called from the onLoad event of the <body> tag:

function setfocus(){
   if (document.forms[0]) {
     document.forms[0].elements[0].focus();
   }
}

In principle, this is a reasonable choice. However, the code is not sophisticated enough to take into account a plausible scenario. Sometimes, if the page takes a while to load, the login form will become visible and available to users before the full page renders and onLoad is fired. Let’s imagine a case in which a user named Steve with a password of password is logging in.

User enters usernameWe’ll assume that Steve begins to login before the page has completely loaded. He is able to type his full username into the appropriate field, and then tab to the password field, all before the page has finished and the onLoad can be fired. (For complex or otherwise slow sites, this is not implausible, even on a broadband connection. It has happened to me many times on the site in question.) He then starts typing out his password. Suddenly, while he is in the midst of typing the password, the page finishes and onLoad fires, with the called function dutifully setting focus back to the User Id field. He continues typing for a moment or two, not recognizing what has happened, and then realizes that half of his password is plainly visible in the User Id field, smashed onto the front of his username in an ungainly manner:

Setting focus during typing causes password to show up in wrong spot

While this is only a minor irritation from a usability perspective, it has potentially significant security implications if it happens while the wrong people are watching. A better way would be to make the code a litle more intelligent, and have it set focus only if the target field has not yet been altered by the user, along the lines of something like this:

function setFocus(){
 if (document.forms[0]) {
  if (document.forms[0].elements[0].value=='') {
   document .forms[0].elements[0].focus();
  }
 }
}

Of course, you might want to skip the home-grown Javascript and do this sort of thing in jQuery, but no matter how you roll it, the principle is the same – if the user has already started to enter text in a field, then don’t set focus there because of an onLoad event. You’re more likely to be interrupting than assisting.

The Worst UI Ever

User Interface,

The worst user interface you’ve ever seen . . .

The Worst UI Ever

It’s arcane. It’s insane. Tucked away inside of a bathroom in a Baltimore area federal building is the worst user interface I’ve ever seen. It happens to be the user interface for a door lock.

Some of the more tragicomic features of the design:

  • It utterly shatters the users’ expectations of how to lock a door
  • It utterly shatters the users’ expectations of how to use a light switch
  • I hope nobody with a visual impairment uses this bathroom
  • I hope nobody with low reading skills uses this bathroom
  • I hope no unobservant people use this bathroom
  • Easily anticipated user behavior (forgetting to turn off the switch) leads to a big problem (unusable bathroom)
  • If the problem occurs, the directions for how to resolve it will be locked inside the bathroom, safe from those who need them
  • The “Locked” position is designated with a sticker that is obviously soon to peel off

You can’t make this stuff up . . .

Do What Hurts. Now.

Improving, , , ,

Figure out what’s painful for you, and then go do that.

You’re a distance running coach. You need to figure out what one of your athletes needs to improve. There are many different kinds of workouts you could use, but these all boil down into roughly three flavors:

  • long, slow runs
  • shorter, faster tempo runs
  • the high intensity bursts of an interval workout

So, how do you know which to emphasize for a particular runner? It’s actually fairly simple – you ask the runner what kind of workout they hate the most. Their answer is your answer. In my case, I love long, slow runs, and hate interval workouts. Not surprisingly, I can run for a fairly long time, but I’m not very fast. I need to do more interval workouts.

People gravitate toward their comfort zones, and avoid their pain points. The pain points are typically the areas in which they are weakest and least comfortable. Like many pains, pains born of weakness are cyclical and self-reinforcing. As people avoid their pain points, they become even worse at doing the thing that brings the pain, thereby making it all the more painful, and increasingly less likely to be something that they’ll want to tackle.

Your pain points are probably the things making you the weakest – the things that are holding you back. If you want to be stronger, one of the best things you can do is to break the cycle of pain. You need to go do the thing that you fear the most, which is likely the thing that hobbles your performance the most. Your dread is your compass for success.

I sought out a difficult conversation today. I was afraid of it, and could have avoided it. The weekend was coming up, and I knew I could have run out the clock on the afternoon without confronting it. Yet, I also knew that it was the thing I needed – my workplace interval workout. If I had hidden from it, I would have felt weaker, and the underlying problem would have grown for lack of tending, making it much harder to tackle on Monday / Tuesday / whenever I couldn’t avoid it any longer. So, I made the conversation happen. It hurt some, and I got a little bruised, but I made my lot better by confronting it, and built my confidence that I could handle the thing of which I was (and still am, but less) afraid.

Know what scares you? Then go.

Mainframes Aren’t on the Internet

Learning, ,

History and culture make it surprisingly hard to find good information about mainframe development on the web.

I manage a team of software developers, and it’s an eclectic bunch. Among the folks currently under my purview are web developers, client-server developers, and a fair number of people doing mainframe work in the old-school batch processing style, using COBOL, REXX, and the whole nine yards.

I’m often struck by the differences between the culture of the mainframers (I’ll resist abbreviating them as the MFers) and the culture of, say, the web developers. Both groups get the job done, but they prosecute their work in very different ways.

I can’t remember the last time I wrote some code by following a book. The average web developer knows enough Google-fu to look up almost any low-level fact or code snippet they need online. The average mainframer, however, goes to the bookshelf first, or to another programmer, at least in my shop. Using the web to search for solutions doesn’t even seem to be part of their regular toolkit. Rather, web searches are an exotic choice, something they try when other options have been exhausted. One of my mainframe guys used the web to get some snippet of COBOL a couple of years back, and the experience became a story for him – something that he recounts occasionally with a who’d-have-thunk tone of surprise in his voice.

I wondered why this might be, until I had occasion to do some web research for a mainframe issue, and realized that the amount of mainframe knowledge resident on the web is amazingly thin. There is certainly quality info to be had from IBM and sites like http://theamericanprogrammer.com/, and you can seek out expert advice in the discussion forums hosted by http://ibmmainframes.com/, among others. However, in total, there are really only a handful of quality locations for mainframe know-how that go beyond the “Fred throws up a page full of links” variety.

The other day, I had a question concerning batch ACIDs. An ACID (short for Accessor Id) is mainframe parlance for an account. When you log on to a mainframe, you supply your password and ACID, which is basically a username. Once authenticated, you get access to TSO/ISPF (assuming an IBM system), which is your vehicle for interacting with the OS in a synchronous fashion. From there, you navigate through screens (panels) and issue various commands. To tell the mainframe to do anything substantial, such as run a program that processes data files, you will execute a batch job. After you submit (initiate) the job, it goes off and runs on its own. You have tools to check whether it is running, but you don’t actually hear from it until it finishes, at which point you will receive a notification from the OS (if you asked for one) that it has either completed successfully or abended (errored out). A so-called “batch ACID” is an account under which only batch processes run – you can think of it as being like an account that gets used by an application instead of a user. In a given environment, specific user ACIDs will have the permissions needed to kick off jobs that execute under the authority of a given batch ACID.

So, back to the question I had – one of the sys admin types (system programmers, in mainframe parlance) wrote to say that he was changing the passwords for a list of batch ACIDs, and wanted to know if this would screw up anything my team had running in production. I, for one, didn’t know that batch ACIDs could even have passwords (not all batch ACIDs do), and so my response was to make a noise that approximated how Scooby Doo would respond if somebody asked him to explain the Central Limit Theorem. Apparently, since my team wasn’t hard-coding passwords for batch ACIDs in our JCL (Job Control Language – the commands that tell the OS how to run batch jobs), our production stuff wouldn’t get hosed, but I was unsettled by the recognition that I obviously knew very little about the z/OS security model and how batch ACIDs actually work.

So, I decided to do a little research on batch ACIDs. Being a simple man of simple mind, I am driven to simple tools, and so I pounded batch ACID into Google. Huh? As of this writing, none of the first-page results have anything to do with the subject in which I’m interested. Instead, I’m seeing links to DJ software and plant amino acids and industrial waste and a host of other things I don’t really want to see. Go ahead and try it yourself. (If this page shows up in the results, then you have to give me a pass on that.) Well, since that didn’t work, I guess I should try it with quotes. Now at least I get one relevant hit – an article that deals with security for batch ACIDs, but doesn’t really do much to explain what these are.

The thing is, “batch ACID” seems like a pretty specific term to me. I don’t think the mainframe world has much competition in the use of this phrase, unless you count Timothy Leary’s party preparation guides. So, I’m pretty surprised that the searches I attempted weren’t more fruitful.

Earlier, I said a batch ACID is more or less like an account used by an application. I wondered what would happen if I tried to search for application account. Offhand, I’d have guessed that I wouldn’t do so well – this phrase would seemingly cross into many more domains than batch acid (think of all the people who fill out applications for accounts that having nothing to do with information systems), and it doesn’t even corner the market in its niche, since there are comparable variants such as service account in common use.

Yet, lo and behold, if I run a search for application account, I get a few hits that cover exactly what I mean. Further, if I use quotes, I do a little better. Even though batch acid is such a unique phrase and application account is dirt-common, the former yields little search gold while the latter pans out right away.

We could repeat this with other examples. Finding info about mainframe topics, error messages, and the like through a search engine is often a frustrating process. No doubt, the info about batch ACID security that I wanted to find is buried in an IBM Redbook somewhere (these are posted online), and nobody should moan about having to look though a few pages of results to find germane content, but I think that this example is illustrative of my basic point that mainframe info is pretty tough to find on the web, at least relative to many other technologies in wide use today. (Contray to semi-popular belief, mainframes are in fairly wide use.)

There are many ways to explain this – obviously, the heyday of batch mainframe processing and associated technologies preceded the widespread use of the Internet, and so the web missed the “sweet spot” period for classic mainframe technologies. However, many boutique technologies see only a fraction of the market share enjoyed by legacy-style mainframe techniques, and yet these technologies are easy to research on the web. Mainframe stuff isn’t on the web in any amount even vaguely proportional to its actual usage, or so I contend. This is not only a function of history, but of culture as well, and it will remain the case as long as mainframe pros adhere to the default search chain of book / body / broadband when they need info or care to share it with others.

CAVEAT LECTOR: Please don’t rely on my description of a batch ACID for anything important. I’ve related the nature of ACIDs and batch processing as I understand these, but I’m sure a knowledgable party could find many faults in my explanation. I’d like to direct you to a good link where you can learn more, but I’m still looking for that myself . . .

Lotus Notes – Emails Disappeared

Tips,

Try shift + F9 to rebuild your view index if your Lotus Notes emails mysteriously vanish.

I’m stuck with Lotus Notes as my email client at my day job, and one morning I found that a number of my Inbox messages (documents, in Notes parlance) had inexplicably disappeared. New mail was showing up fine, but some five thousand messages had simply vanished. I tried the usual common sense things, such as toggling the View All / View Unread options, checking the Trash, and restarting Notes, but all to no avail. I was stumped, and worried that my mail might have gone the way of the dodo.

Then, I got some great tech support from headquarters, and learned that the index for my views of the database were simply in need of a re-build. You can press Shift and F9 (at the same time) to rebuild a view index. After I did this, my messages magically reappeared.

(Thanks to Sonja Houze for her consummately professional assistance.)