Tag: software development

More Lessons In UI Design

2 comments
notebook beside the iphone on table
Photo by picjumbo.com on Pexels.com

When I work on UI design for applications I build at work, I try to make it so that the system won’t allow users to make mistakes. I don’t show fields that aren’t absolutely necessary, or options within those fields that aren’t needed for some important function in the context of what is being done. I try to make it as intuitive as possible, and though I always write documentation and help text for the systems, I try to design the UI to be self-explanatory. I put a lot of effort into this. I’ll use a recent experience to tell you why.

Our school system uses a Qualtrics app for health screening. Every morning, I get a notification–one for each of our three kids–with a link to complete the health screener. The health screener itself has eight yes/no questions that you have to answer. You tap a long Yes or No bar below each question. When selecting an option, it turns blue. It doesn’t matter which option you select, the selected option turns blue. At then end of the screen, you advance to the next page, where you verify that you’ve answered all the questions truthfully. After that, you get to a page with a green checkmark, indicating your child has cleared the health screener for school that day.

I’m up early and it is my job to do the screeners for the kids. I tap those “No” buttons 120 times a week, week in and week out. And yet, twice now–most recently yesterday morning–instead of a green checkmark, I’ve had a red X of death. Somehow, I accidentally answered a question “Yes” instead of “No.” This is annoying. It means I have to wait for the school to open, call the school, explain that I’m an idiot and accidentally selected the wrong option, and could they please correct this. Twice, this has happened to me.

The thing is, I am not an idiot. The Qualtrics application, for reasons that pass comprehension, allows users to make silly mistakes. An application–especially a health screener like this one–should never allow for mistakes like this. How could these mistakes me avoided? I can think of two easy ways:

  1. When answering the 8 questions on the first page, if you tap No, response turns green instead of blue. Green is good. If you tap Yes, the response turns red instead of blue. Red is bad. This is a quick visual cue to indicate how you answered the questions. If you see red, and didn’t mean to answer a question Yes, you can quickly correct it and watch it change green.
  2. On the second page, where you verify that your answers are true, it might be nice to display a recap of your answered, again, with Yes highlighted red and No highlighted green. Another simple check before you submit your responses.

If the Qualtrics application implemented even one of these two simple features, I’m certain that I would not have made any mistakes this year. Keep in mind, It’s not quite the middle of October. There has been, say 25 school days, which means 75 opportunities to fill out this screener. My success rate is therefore 97%. That sounds high, but given I have to fill this out for three kids each day, it also means that I can expect to make this mistake between 10 and 14 more times this school year. And I can’t imagine I am the only one making these mistakes. Which means a whole lot of frustrated parents, and a whole lot of time school administrators have to invest in correcting mistakes that parents make, when all of this can be resolved by any of the suggestions I’ve made above.

Why wouldn’t Qualtrics make this change? One reason does come to mind: Perhaps the thinking is that if “Yes” answers are flagged (e.g. “Yes, my child is awaiting the results of a COVID test”), it will discourage people from answering the questions honestly. I’m not sure I agree with this, but I could see it. Instead, the tool makes it confusing for sleepy, overworked parents to ensure they are selecting the correct options.

This is why I spend a lot of time thinking about the design and use of the UIs that I build in applications I make in my day job. I don’t want others to experience the unnecessary frustrations I have with software. I know how it makes you feel.

Did you enjoy this post?
If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!

Follow Jamie Todd Rubin on WordPress.com

Please Insert Disk 9: The Ease of Software Installations

No comments

Today is the 20th anniversary of the 9/11 attacks. I wanted to acknowledge this here. Each year, on the morning of 9/11, I pull out my diary from the days immediately before and after and read through it. I still can’t watch the footage on TV. I don’t have anything original to add to all that’s been written about 9/11 these last 20 years. I know that there will be many, many things written today. We all mourn 9/11 in our own ways, and for those who have mourned, and need a respite from what can be a traumatic day of 9/11 posts and news items, I wanted to have a post people could come read that isn’t about 9/11 at all. But I wanted to acknowledge it here. As I said at the end of my diary entry on 9/11/21, “I simply can’t believe this.” I still can’t.

floppy-disk-computer-163161.png
Photo by Pixabay on Pexels.com

I had a problem with my work laptop late last week. I use a MacBook Pro, and I run Parallels for Windows and database development. This has worked well for me for years, and I’ve never had a problem before, but on Thursday evening, Parallels crashes and the image corrupted. While my laptop is backed up, the Parallels image is not. I didn’t lose any data because data is not stored locally, but I needed to bring my laptop into the office to have the image reinstalled. When I got my laptop back, I had a clean Windows install, which meant going through the process of installing Visual Studio, Microsoft SQL Server Management Studio, and RedGate. This has been a time-consuming procedure in the past.

I chose to perform the installations in the evening with the thought that by morning, everything would be ready. After all, it was several gigabytes of installation files. I got the installers for the latest stable release of Visual Studio Enterprise, and SSMS, and began the installation process. It turned out to be far quicker and easier than the last time I had to do a full installation. After an hour or so, all of the software was installed.

Next, I had to configure SSMS to connect to the servers I wanted, but I thought instead that I’d give Azure Data Studio a try instead. This, too, seemed surprisingly easy to setup. Within a short period of time, I was able to connect to the servers I wanted; I was able to connect to git repos from directly in ADS, something I’d had to use RedGate for with SSMS; and I had access to Jupyter notebooks, which was an added bonus.

During this process, I noticed that both Visual Studio and Azure Data Studio now have native Mac versions. So I installed those on my Mac. Those installations were even easier (The architecture of a Mac piece of software is entirely self-contained within a “package” file that represents the application.) I then pulled the git repo for the big software project my team is working and to see if it would compile cleanly on my Mac. It did! It is now looking like I need to rely less and less on the Parallels instance.

Later, reflecting on how easy the installation was, I realized just how far software installations had come in the years I’ve been working with computers. The first install I did, when I was 11 years old, was for my Commodore VIC-20. I installed a Hangman program from the tape drive that was attached to my computer. Tape drives, in my experience, are notoriously unreliable. It often took several frustrating attempts to get the program loaded, and once it was loaded, I no longer felt like playing.

In the early years of college, I remember installing WordPerfect from 5-1/2 inch floppy disks. By my senior year in college, I’d moved to the far superior (in my opinion) Word 5.5 for DOS, which took a small stack of 3-1/2 inch floppy disks to install.

When I first started at my job, Visual Basic 3.0 required 3 installation disks. You had to put one in the drive, wait until that part of the installation had completed, then switch to the next. By the time the late 1990s rolled around, Visual Basic 6.0 came on a CD-ROM.

I can remember installations of Microsoft Office that took 12 or more disks–in some instances 20 disks, if memory serves. You couldn’t start the installer and walk away because you had to change each disk as it finished loading. Anyone who used computers in that era remembers the frequent messages “Please insert disk 9.” And heaven help you if one of the disks failed to work halfway through the installation.

It is possible that I imagined, back in 1995 or 1996, how wonderful it would be to simply be able to install the software you wanted without need of a disk. Just answer a few brief questions and BAM! the software was there on your machine, ready to use. This was just the kind of daydream I could see having, while sitting in someone’s office, waiting for Disk 9 to finish so that I could put in Disk 10, and wondering if the installation would be finished by lunchtime.

Today, my daydream is the standard. Want a piece of software? In most cases, click or tap the Install button from an App Store and it loads on your device within seconds. In some cases, as in installing Visual Studio, you have to download the software directly from the website. But the process is still far easier than it was 25 years ago. You rarely have to worry about configuration files, or which type of processor you are using; the installers figure this all out for you. If you are missing a critical system component, the installers know that, too, and will grab and install the necessary software. Then, too, the software will keep itself updated, which saves a ton of time in the long run.

Installing software used to be a real headache, but it has become so easy these days that I hardly even notice it. It is one of those things about technology that I simply take for granted, forgetting how different it used to be when I was starting out. Twenty years ago, software was still fairly difficult and time-consuming to install. Installations have come a long way. It makes me wonder, what will software installations look like twenty year from now?

Did you enjoy this post?
If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!

Follow Jamie Todd Rubin on WordPress.com

A Developer’s Logbook

No comments

Working scientists use logbooks to record their work so that they can (a) reproduce results, and (b) establish priority in discoveries. As a working developer, I use a logbook, too, which also serves two primary purposes: (a) capture what I did during the day (sometimes in order to reproduce things), and (b) as an index to more detailed notes for specific things.

My logbook had evolved over the years. It’s present incarnation is a text (markdown) file in Obsidian. For work, I use Obsidian’s Daily Note feature for my logbook. I have one logbook “page” for each day. I have this logbook page open on one screen at all times. Usually my Obsidian window is split with my logbook on the left and other notes files on the right. Here is what a typical screen looks like:

My screen with my logbook and other notes open in Obsidian

Yesterday I mentioned how I was in crunch time for a software system my team has been building for the last 13 months. We go-live on Monday and we are preparing for roll out. We are in what I call the “junk drawer” phase of the project. I think of it like moving houses. All of the big furniture had been moved and all that is left is the stuff in the closets and junk drawers. That’s where we are. Yesterday, my workday started at 7am and ended at 12:30 am (this morning!). Here is my logbook entry for yesterday:

Yesterday's page from my logbook

Those of you who spend your days making software are probably familiar with the pattern of these last few days before roll out. Those who aren’t can at least get a little glimpse of what these days are like for me.

As you can see from the logbook, I finally got to bed around 1 am (about 4 hours later than normal) and I was up before six this morning so that I could get in my morning walk before taking my girls to school and writing this post.

Now it’s back to where I left off yesterday. I have a new blank “page” open in my logbook and I’m ready to fill it.

All I Can See Are Flaws

No comments

On Monday we will roll out a software system that my team has been building for the last thirteen months. In nearly 27 years with the company, this is the software that I am most proud of. It is a system that coordinates new hires, people who are changing jobs or transferring locations, and people who are separating. It involves integration with many other systems, but it really does save people a lot of time over what they do today and it smooths the process for a person starting at the company on their first day, or leaving on their last.

It occurred to me that there is something even more remarkable about this piece of software. The very first meeting I had on this project was back on February 3, 2020–before everything began to shut down due to the pandemic. The first of what was ultimately 37 requirements meetings was held on April 21, 2020. The meeting, while involving people from all over the company and across most of our locations, was done remotely at this point. And since then, we haven’t had a single in-person meeting on the project. The entire software system was built remotely, with people working from home. Of course remotely-built software is nothing new in the open source world. But I think this could be a first for my company. And I’m really proud of the result.

That said, I am in a mode that is probably familiar to many software designers and project managers on the eve of releasing a product you have been working on for so long: all I can see are flaws.

I have a long punch-list of things that I am trying to get done between now and Monday and they all seem to be flaws in the system. These are not fundamental design or structure problems. This is more like a spot on the windshield that you missed while cleaning it. But it is all I can seem to see at the moment. I am so happy with what we have done with this system that I want it to be perfect when it goes live on Monday. And anyone who has ever used a computer knows that no software is perfect.

Still, I think it is useful that my brain is only seeing flaws at the moment. It allows me to focus on those things that matter, and not worry about the stuff that is already in done and ready to go. It means that every day, the system is getting a little bit better.

I was incredibly lucky on this project. I had a great development and testing team. It has been one of the best things about working where I work that I get to work with some of the smartest people I’ve ever met. I learn from them every day, and I have been really impressed with how well our core team has worked remotely over the last 13 months. I’ve lost count of the number of “co-programming” sessions we’ve had that have worked out so well.

We’re in that final push now. This past weekend was the third weekend in a row that I’ve worked. Yesterday, I put in 11 hours, and I couldn’t sleep much last night because the stuff I have to get done was running through my head. So I was up before 5 am this morning to get started and maybe quiet my mind a bit. Four more days, and one more weekend to do, and the system will be live and in the wild. I am feeling unusually optimistic about this system–which is why I am glad that at the moment, all I can see are flaws. I think that will help to ensure we release the best possible system we can come Monday.

Plotting Software, Pantsing Stories

No comments
A screenshot of some code I've been writing
Some code I’ve been writing

I just completed a demo1 for software that me and my team have been working on for nearly a year. It isn’t quite done yet—we still have a few months of work left, but it feels good to get to the point where you have something to show. Indeed, it’s not that different from getting a story out into the world.

When it comes to writing (when I can even manage to write these days) I am “pantser” as opposed to a plotter. That is, I don’t plan out my stories in detail. I have an idea of where the story is going, and I figure out how to get there as I write. Sometimes, I end up somewhere else entirely.

With software, I am the complete opposite. Over the decades I’ve worked on increasingly more complex software and I’ve found that my brain doesn’t have the capacity to build it without plotting it out first. I hadn’t really considered it much until now, but I suppose that designing software is a lot like outlining a story. You start with the high level goals and requirements; you identify the tools you can use to meet those requirements; and then you figure out how everything will fit together to make a cohesive and self-consistent thing.

The day-to-day work is writing code, small fragments, akin to scenes in a story or novel. Often you write something that gets the job done but isn’t particularly elegant, so you rewrite it and rewrite until it purrs. The world fades around me when I get into this mode, my focus is completely on the task at hand, and an 8- or 9-hour day can fly by in what seems like the blink of an eye. This happens when writing, too, but I can’t consistently write for 8- or 9-hours the way I can work on code.

I often had the impression (from comments I’ve heard in various places and times) that non-writers think that writing is easy. I find it difficult, and I’m fairly worn out if I manage to writer for more than 2 hours. Writing code is equally difficult, but I come away from these long stretches in what I call a “code-coma.” It’s hard to re-engage with the world around me, and I have to ease back in.

When I have something on the page that works, I’ll review it, often out of context of the rest of the piece (often because “the rest of the piece” doesn’t exist yet). I’ll find typos here and there, little misspellings, or autocorrects that don’t work. Same thing when writing code. Punctuation is just as important and I can stare at a small piece of code for an hour wondering why isn’t working, only to realize I was missing a semi-colon somewhere.

Sometimes, you get pretty far along in a story only to realize that you’ve uncovered a major hole in the plot. This happens with software, too, but it happens less frequently for me these days because I “outline” the software and try to eliminate plot holes in the design before we actually start building the thing. Still, other things may trigger major changes forcing rework.

When I think a story is ready (always after the second draft, never after the first) I’ll send it out for critique by fellow writers. It’s no different with code. We sit down for code reviews where it becomes our job to ask each other (and ourselves) tough questions about the choices we made. These are both incredibly useful and incredibly disheartening. Code is always improved in these reviews, but I find it disheartening that I couldn’t think of some of the elegant ways my colleagues suggested for improvement in the first place.

(In the movie business, I think the information that comes out code reviews would be akin to “notes.”)

The draft of a story that goes to the editor might be considered a beta (or a golden master) in the software world. It is almost good enough for the world, but subject matter experts (editors, copy editors, publicity people) will look at it and offer some final polishing suggestions.

Finally, the book or story is out in the world! Hurray! And of course, the first slew of reader comments, and reviews start coming in. They are all pointing out the typo on page 5. How did anyone miss that?

It’s really no different than the day the software you’ve been working on for a year or two goes live. You’ve run millions of unit tests. You’ve demo it, you’ve made it as easy to use as possible. And 2 hours after it goes out, someone finds a bug that should have been caught 6 months ago.

I think the biggest difference between creating software and creating stories is that with a story, more often than not, you have something to hold in your hands, the product of your long hours of labor. It might be a printed manuscript. It might be a copy of the magazine the story appeared in. It might be a book. It always gratifying, on those rare occasions when it’s happened to me, when someone hands me one of these things and asks for an autograph.

With software, there’s nothing to hold, nothing you can grasp in your hands that represent all the blood, sweat and tears that went into its creation. It’s probably for the best. In thirty years of making software, no one, not a single person, has ever asked me for an autograph. If they did, I’d be a loss: there’s nothing on which to sign my name.

  1. Which explains why this post is coming out at nearly 7pm instead of much earlier in the day ↩

What is a Project Manager?

5 comments

Finally, I have come across what I consider to be the best definition of a project manager that I have ever seen. I have written in the past about how I dread getting asked that question, “What do you do?” because (a) it is hard to describe what a project manager does without (b) making it sound like a made-up job.

Reading Ed Catmull’s book, Creativity, Inc., this morning, I came across what I consider the best definition of a project manager—one that describes what I do clearly and accurately—but cast in terms of Hollywood production managers. Catmull writes:

Production managers are the people who keep track of the endless details that ensure that a movie is delivered on time and on budget. They monitor the overall progress of the crew; they keep track of the thousands of shots; they evaluate how resources are being used; they persuade and cajole and nudge and say no when necessary. In other words, they do something essential for a company whose success relies on hitting deadlines and staying on budget. They manage people and safeguard processes.

By changing a few words here and there, I have the definition of project manager that I have been seeking for years now:

Project managers are people who keep track of the endless details that ensure software is delivered on time and on budget. They monitor the overall progress of the developmentteam; they keep track of the thousands of lines of code; they evaluate how resources are being used; they persuade and cajole and nudge and say no when necessary. In other words, they do something essential for a company whose success relies on hitting deadlines and staying on budget. They manage people and safeguard processes.

I love this definition. It perfectly describes what I do day-in and day-out on my job. I am particularly tickled by the line, “they persuade and cajole and nudge and say no when necessary.” A project manager who taught me a lot about the job two decades ago summarize this line back then with a simple phrase that I often repeat: “As a project manager, all you have is your charm.”

I’m only a quarter of the way into Catmull’s book, but it has proven its worth with this definition alone. I feel a great sense of relief in having a good, accurate, and succinct way of describing what I do.

Initial Thoughts on the Mac Mini

No comments

The new Mac Mini has been up and running for 10 days now and I have some initial thoughts. For context and clarity, I bought the newest Mac Mini (M1 2020), which is running the Apple M1 chip. I bought it with 16 GB of memory (way up from the 4 GB I have on my MacBook Air). The internal disk has 250 GB, but I’ve got two external disks connected to the machine, each of which is 3 TB giving me a total of 6.25 TB of disk space. One of the external disks is for media files and archived data; the other is a local Time Machine backup disk.

As far as performance goes, this machine flies. Applications open so much faster than on my MacBook Air. There doesn’t seem to be any performance hit with backups running and with the various services I have in the background. I really like how fast the machine is.

There are a few downsides I’ve discovered, however.

The M1 chip is the biggest blocker so far. While it is super-fast, not every app has caught up yet, and several still expect an Intel processor. For instance, I use Docker for development work, and I have to run a preview version of Docker Desktop because there is not yet a production version compatible with the M1 chip.

There are some quirks with homebrew as well. Homebrew can be run natively or using Rosetta2 which makes apps compatible, but at a performance cost. Running homebrew natively takes a couple of extra steps to setup, and some bottles have to be built locally to allow them to run natively.

MySQL runs fine on the Mac Mini, but there is not yet a compatible Docker image for MySQL for the M1 chip.

These are relatively minor issues, which only apply to someone doing development work. It appears that most places are working toward making their apps natively compatible with the M1 so I suspect most of these issues will go away with time.

For other tasks: writing, photos, general productivity, I am very pleased with the Mac Mini thus far. Given that it cost significantly less than the newest MacBook Air, it is well worth the cost so far.

I have set up the machine as a home server. I’ve got an internal web server that I am using to build a custom reading list app (that I plan on moving to my domain eventually). I am also using it to host an app for home document archive. Screen-sharing works well with it (I can use screen sharing from my MacBook Air to do development work on the Mac Mini when I am not in my office). I’ll have more to say on these things in a future post.

You can see the new computer in the photo above, peeking between the monitor and the external disks. At some point, I need to clean up all of the cables.

At this point, with the exception of a few development quirks related to the M1 chip, I am very pleased with the new Mac Mini.

Progress on the book collection database

No comments

I did manage to get started tonight, but it was mostly on configuration and design issues:

I upgraded my system to PHP 5.1.4 and MySQL 5.0.24. I also upgraded my installation of MediaWiki to 1.7.x (I use MediaWiki for not only developer notes and design documents, but for just about all household related stuff) Once all of that was configured, I got to work outlining the stored procedure API, which now consists of 96 stored procedures.

I expect to do more this weekend, but I’m beat tonight, and am off to bed…

Changes coming to my book database

No comments

Ever since I switched from a PC to a Mac at home, I have been using Booxter to manage my collection of books. Back in the day, I had developed my own, Windows-based, home grown application to manage it, but on the Mac, Booxter seemed the way to go. It served me well for quite some time.

But I want something web-based, something that will do libaray and reference management, and something that ties seemlessly into my reading list application. Over the last week, I have been working on the data model in my spare time, and I now have a model that I think does everything I need it to do. To make this work on the web, I’ve decided to do it as a LAMP application (replacing the L for Linux with a D for Darwin): Darwin (Mac), Apache, MySQL, PHP. I’m using a three-tier model for the application design and I have outlined the core API (stored procedures) for the database layer.

I plan on getting started this Labor Day weekend. My goals for the weekend are as follows:

  1. Implement the data model in MySQL
  2. Code the API
  3. Export my data from Booxter into my new data model

If I can get that much done over the long weekend, I will be very happy.

As for the longer-term plan, I am trying to completely seperate the presentation layer from the rest of the application so that the initial interfaces will be bare-bones HTML. Ultimately, I will build up the look and feel using CSS. Once I have a working data management interface, I will look into porting portions of the application to my public website, so that people can search the database if they want to.

Sounds like the perfect thing to be working on during this long and rainy weekend.

I’m also looking into buying two more bookshelves for my home office since I am way out of space on the 7 existing shelve units. But more on this later.

Microsoft sucks!

No comments

This is no revelation. But we M$ products at work, and one which I use quite a bit is Microsoft Visual Studio 2003 and Visual Source Safe. This morning, after compiling an application successfully, Visual Studio went bye-bye silently. No application exception, nothing in the event log. Nada. A reboot didn’t seem to fix the problem. I’ve narrowed down the problem to projects that are checked into Visual Source Safe. I can’t seem to open those projects, but projects that are not checked into revision control are accessible.

And yes, I checked the VSS server and I can get into that just fine.

This sucks becuase I was about to finish something up and get it published and check it off my list and move on to the next task. Now I’ve got to spend time I don’t have trying to figure out what the heck is going on!

UPDATE: It’s all working now, although it took a threat of setting my computer out to sea and praying for a hurricane to get it to cooperate. Incidentally, after I clicked the “Save Post” button on the initial post (when, in fact, I felt like screaming!), Tears For Fears, “Shout” came onto my iPod:

Shout, shout,
Let it all out.
These are the things
I can do without
Come on; I’m talking to you
Come on.

What a coincidence, eh?