The Madness of Software Design: Designs that Require Customizing Browser Setting to Operate

We are looking at a number of third-party internet-based software solutions for a range of things from HR onboarding to safety and training management.  With minimum wages and other government-imposed employment costs rising, we are looking for ways to automate anything we can.

We have run into a useability issue on most of this software.  As a note, my employees tend to be 55 years old and older, and so many do not have a firm handle on computer skills.  So stuff needs to be simple and just work.  Unfortunately, no one seems to be willing or able to design a system that works with default browser settings.  In particular, everyone wants to design their software to require popups.  I have no idea why.  But time after time I put a system out for a subset of my employees to test and I immediately get 19 people calling me back saying that it does not work, they can't get in, etc.  The typical problem is that most of this software seems to require that the browsers popup blocker be turned off.  Why in the world would you design software for a feature that 99% of browsers today have turned off by default?  And worse, that require users to change a setting that only exists deep in setup menus most users don't even know exist.  I am pretty capable and it took me some poking around to find the popup options in Chrome.

This makes me totally crazy.  I had a long talk today with my onboarding company trying to explain why getting rid of an hour of HR time with their software at the cost of an extra hour of IT support time for each new employee trying to access the system does not save me any freaking money.  We received access to a training and safety system for free from our insurance company but it took so much of my personal time to get each employee able to successfully log into it that we abandoned it this year, despite it having a lot of good resources in it.  I will tell you guys that despite the world of these business solutions being apparently crowded, there is still room out there for someone who can program a front-end that reliably works with a variety of browsers and systems.


  1. Frederick Davies:

    You are complaining about pop-ups!? Try and manage a set up that demands specific sets of (out-of-date) Java, browser and security options no one has ever heard about. Someone should teach developers that just because you have functionality available does not mean you are required to use it!

  2. Another Guy Named Dan:

    It gets even more fun when you have two different applications which each require different specific versions of Java, plus pop-ups, plus their own proprietary media player anytime anyone presses the F1 key (which tries to install itself and fails because we do not give administrator rights to users by default).

  3. aczarnowski:

    Most developer's get it. Designers and marketing, however, come up with the damndest things.

  4. Matthew Slyfield:

    "The typical problem is that most of this software seems to require that the browsers popup blocker be turned off."

    Technically it doesn't have to be turned off you can create exceptions for specific sites/servers/applications.

    Your problem is that these companies are mostly making their products for companies with full time IT departments with control over the hardware and software configurations of the users..

    Most corporate IT departments lock down these settings so that they can configure them the way IT/security wants and individual users can't change them.

  5. ECM:

    While I won't argue that designers and marketing are trouble, recalcitrant coders can be--and in my experience, are--every bit as bad.

  6. Matthew Slyfield:

    As a coder, let me say that my life would be a lot easier without users. :)

  7. kidmugsy:

    The IT business is packed with people who are moderately intelligent but suppose themselves highly intelligent. That's the kernel of the problem.

  8. Another_Brian:

    Part of the problem from a development standpoint is that HTML is not really designed for the types of things people want to do with web-based applications. They have to use things like JavaScript, AJAX, and plugins like Flash to get the sort of functionality that they would get natively with a client-server application. But then not all browsers support all of those things the same way, and then there's numerous different browser versions with various different defaults, and they are all customizable. Building for browsers saves you the complexity of building and deploying all the nuts and bolts of a client-server application, but it comes with a whole other set of complexities that may or may not be a worthwhile trade-off.

  9. Wilhelm Arcturus:

    I learned quite a while back that horrible interfaces from all ranges of software... Oracle, SAP, PeopleSoft, and so on... are a direct result of who makes the buying decision. The VP or C-level officer is sold the data and reports the software will provide, not the interface. Or they are told the interface is customizable, but the fact that customization is not supported between versions is left out. Anyway, the person who makes the buying decision never uses the software at the employee end of things. The mandate just comes down that this is the new thing to use. IT has to make it work in some minimal way and the employees just have to suck it up and figure it out.

    You're in the odd position of being both the person making the buying decision and the person who has to implement and support. If only that were more common.

    And the irony of the situation as I see it is that, when the interface is difficult to use people will invest just enough time to get by. If the time tracking software is a huge pain... the one I have to use has a couple thousand projects on a single menu and I have to select the right one... and it doesn't remember my selection from week to week... the data people enters tends to be just a shade of reality, which in turn makes the reports inaccurate and the whole thing a farce.

  10. disqus_00YDCZxqDV:

    That's crazy. Technology exists today to build solutions that 'just run' on any modern browser. Probably the solutions you are looking at were actually built 10 years ago and now have problems working outside of a corporate intranet.

  11. Not Sure:

    I'm having an issue with how our website displays and I ask the designer for help. He asks what browser I'm using and I answer Internet Explorer. He tells me the site displays better if I'd use Firefox or Chrome. Ok then- I guess I just get in touch with the 2,500+ contacts (many of whom are barely computer literate, which is why I'm using IE in the first place- so that I can see what most of our users see when they come to the website) in our system (ignoring the fact that not everybody who accesses our website is known to us) and tell them to switch browsers. Yeah, that's a good solution.

  12. Fred_Z:

    My favourite professor when I studied computing science told us that programming the human interface was the only part of it that was not clerical work.

  13. HenryBowman419:

    The U.S. Government is one of the worst offenders of such. It provides training software that (a) requires using the horrible Internet Explorer and (b) requires pop-ups. To me, it is simply evidence that either (a) Microsoft actually pays the Federal government to require such or (b) the Feds are serious idiots. Or both.

  14. marque2:

    Flash is obsolete. HTML 5 supports all the features flash has and works on cell phones.

  15. Another_Brian:

    And it was finalized like two weeks ago.

  16. marque2:

    Most features of HTML 5 have been put into browsers 3 years ago. Internet standards are never quite finalized, so no surprise there.

    If you are wonderiging how Apple and Google get away without allowing flash - it is because their browsers already support and the companies are encouraging the use of HTML 5.

  17. slocum:

    A lot of these apps are probably a bit older and may have worked fine with default browser settings when they were released a few years ago. Browsers have gotten increasingly locked down by default over time -- which means either refactoring of the software (which is costly and adds no new functionality) or custom browser settings. And the kinds of vertical market applications you're talking about usually don't have large user bases or large corporations behind them, so they often don't have the resources to do what you're asking for.

  18. tex:

    Zuckerberg, at a tech conf, notably said the biggest business mistake he made was relying on HTML5 and rewrote his aps in native languages. In many cases & in many ways HTML5 is not ready. I'm in process of developing a multi-device complex Ap & have been advised by many gurus “Don't use HTML5. Its not ready yet.”

  19. tex:

    Kinda makes me think of my wife.

  20. tex:

    Browser based SW has a lot of problems vs native based Aps, e.g. Windows Aps for Windows or Mac Aps for Macs.

  21. Rick C:

    People love to hate on IE because it was so busted for so long. They should really look at IE 11, which is much more standards-compliant than before. The only real problem is its Javascript engine is relatively slow.

  22. epobirs:

    On the one hand, nearly all browser for several years give an alert when a popup is attempted and allow the user to allow it for that session or permanently for that domain. On the other hand, there isn't much reason for using popups anymore. Oddly, I've noticed several sites that produce a popup alert during a download request but then go ahead and work correctly anyway. This baffled me. Was I missing some important info? I tried disabling the popup blocker and letting the site have its way. All it produced was a little box say my download would begin Real Soon Now, which was already said by text on the main page.

    On the other hand, when dealing with older users a lot of what are considered normal interface elements simply fail. My mother is completely oblivious to anything happening on a part of the screen that doesn't have her focus. It took years to convince my younger relatives that any kind of instant messenger chat was never going to work because the IM entry in the task bar could flash for hours without her noticing. She is a severe case but I've seen the popup alert messages go ignored far too often by older users.

  23. Nosmo King:

    Alan Cooper (among others) has a few books on interface design and interaction design; they're worth reading if you design software, if you don't they'll just confirm what you already know as a user and bury you in geek speak. My experience is that a lot of developers don't place the necessary value on how users actually operate their software in particular and their computers in general. That is compounded by the massive number of business operators - supervisors, managers, directors, etc - who do not really understand how their business operates and what the physical and information flows are within the business. One of the first things I do with a client is take their flows apart, find out exactly how they work - which always surprises everyone - and build flow charts. That process is a very great deal of work, and many clients balk at the time and expense. But, you have to know what everyone thinks it is, and what it actually is, before you can build a plan for what it needs to be, and begin figuring out how to accomplish that.

    Some problems can be fixed by applying a different front end to the application for user interaction. Sometimes that's not enough and the entire app needs to be nuked and replaced top to bottom (from user interface all the way to the database). One thing that gets overlooked, and it's just a patch, not a true fix, is automated database lookups within the front end (and front ends like that are really another app running on top of the base app). A lot of user interaction that causes confusion and frustration can be reduced (and, please note I said "reduced" not "eliminated") by having the front end query external data sources (external to the front end) and return proofed data (by "proofed" I mean that data element has been validated against known good data elements so garbage isn't being returned; if the proof fails no data is returned). That saves a lot of keystrokes, both speeding things up and reducing manual keystroke errors and generally improves data quality. I've tried doing this sort of thing with browsers, and even with a lot of hacking that's never turned out as successful as just building a complete new front end, one that's tailored to the needs of the busness. The big challenge there is providing the foundation for easily expanding the front end app to accommodate future, unknown needs.

  24. mesocyclone:

    Your favorite professor, then, was an idiot.

  25. HoratiusZappa:

    Too many code monkeys in love with particular technologies, and not enough people well enough trained and disciplined to conduct proper analysis and to use basic tools for implementation.

  26. marque2:

    OK - have it your way. HTML 1.0 is also quite stable. I wouldn't venture beyond that either, just to be safe.

  27. ErikTheRed:

    That's dead on - unfortunately, a lot of these apps would have to be rebuilt from the ground up to work properly with the new frameworks.

  28. ErikTheRed:

    This was an issue about 4-5+ years ago, but it's been widely cleaned up since. There are now a lot of great frameworks and apps that have the look and feel of a reasonably-responsive windowed user interface, all within a web environment that's reasonably compatible with most modern browsers. Synology's user interface is an interesting example of something done relatively cheap. Where this often breaks down is not having scalable infrastructure behind it, but you can screw that up in a native code-based application just as easily (that being said, I see more of it with web-based systems - I think there's a learning curve still in play).

  29. Mike Powers:

    You joke, but you can do just about anything you actually need to do with HTML 1.0.

  30. webdev:

    Eh, even today, there are plenty of things that would be easy to do in a native app that is painful at best and nearly impossible at worst to do in web dev. And that's not counting the number of times (even with the libraries) you need to write the same code 2 or 3 different times because browsers do things differently. As an example, say you have a web application, that web application uses a client side javascript library to generate a series of charts and images from a set of data. Your user wants to be able to click a button and save those images to a file. How you do this (or even if you can do this) depends not only on the browser your user has, but the specific version of that browser as well. And don't get me started on printing a portion of the page. Sure, you could re-write the chart creation code on the server side and send a request for a file download, but why should you have to redo all that code (and then maintain two code paths) when what you want is already on the user's computer?

    The reality is, the web was never designed for these sort of applications (hello stateless communication) and though it has evolved, libraries have been developed and things are better than they were, it's still not an ideal environment for a lot of applications, even though it's being used for it,

  31. aczarnowski:

    Indeed. My first flippant response was too broad. This last week brought it home to me but good.

    Some developers get it. Some developers want to fix this stuff. Most developers are drowning in requests from people in the org that don't get it and happen to be their bosses. There's only so much time in the day to push boulders up hills.