Your System – Not Guilty As Charged

Just another weblog

E-Commerce page “Guilty as Charged”

Posted by Joel Schipper on July 17, 2022

Recently I had the chance to sign-up on-line for a concert/fundraiser event. The invitation came while I was out of the house, and through Gmail delivered to my iPhone. I followed the link, entered all my information — including credit card payment data and pressed Continue. It told me one participant was successfully registered. I figured I was ‘done’ except that there was no payment confirmation, and no immediate email confirming my registration. The next day I checked my credit card website, and there was charge.

I went back to the email, but this time on a computer. The same thing happened. But when I scrutinized the buttons at the bottom of the screen, nothing said “go to checkout.” Instead there was one that said “skip participants.” Only by “logic of deduction” did I conclude that this must mean I was only registering one person, and the button meant “continue.” Turns out this button meant complete the check-out — without any further review or warning that my card would be charged — and so my registration was completed and payment submitted for the event.

I only wonder how many people failed to register for this fundraiser because of this very poor page design choice!

Posted in Uncategorized | Leave a Comment »

Walgreens – Guilty as Charged

Posted by Joel Schipper on February 23, 2022

Here’s a good example of ”bespoke” code not being thoroughly tested to all common circumstances.

Bottom Line — Walgreens did NOT check for which family member was making the appointment, and assumed it was the account ’owner.’ Here are the details.

We recently went to the site to make a vaccine appointment. I thought (quite logically) that we should ’sign in’ to our family account so that we could select the family member (my wife) during the vaccine scheduling process. But … that’s not how it worked out.

After answering questions and selecting the vaccine and making the appointment date and time, we were taken to a ’check-out’ kind of screen that asked if the end user (us) to either ’use account’ or ’continue as a guest’. Although the screen explained that ’guest’ option was the right approach if making the appointment for someone else, I still believe that since my wife is a distinct member of the ’family’ on the account — and since it recognizes her prescriptions separate from mine (as the account owner) — that it would ask which family member is requesting the vaccine appointment. In fact, this entire process — signing in and selecting family member — should have been the FIRST thing in the process; that’s a design error.

The ’guilty’ charge comes from the programming team assuming (or not even thinking about) which family member is making the appointment, and assuming (without ability to change/override) the account owner’s name. And from the testing/quality team not including a test scenario of someone with an account making an appointment for someone else already on the account — as compared to a child or other person not already on the account name list.

We need to have better design reviews, and make sure we corporate all design considerations in our testing!

Posted in Uncategorized | Leave a Comment »

E-Commerce Annoyances that are “Guilty as Charged”

Posted by Joel Schipper on December 27, 2021

Here are a few things that need to be corrected across the e-commerce website world:

1 – Chat windows are NOT pop-up’s in my opinion. They are there because you need help and want to chat. You’re never forced to chat when you don’t want to. So don’t force me to figure out my security settings and allow pop-ups on the e-commerce site. Example:

That said, some pop-up chat windows appear very quickly because the website senses you might be having ‘trouble.’ Usually these are easy to click away — just make sure the user can find the chat when they really do want and need it.

2 – An e-commerce sites must be able to recognize that you are on a mobile device. That means that I want an on-screen keyboard that is appropriate to the data entry task on a mobile device, such as having the @ sign and “.” or “.com” buttons on the same keyboard as letters. Switching back and forth several times to type “” is really simple stupid from the POV of the user experience. Being recognized as being on a mobile device also means switching the keyboard to a numeric entry pad for fields such as zip codes and amounts. It’s terribly hard for ‘older’ fingers to accurately hit the little numbers in a QWERTY layout on a tiny screen.

3 – In my opinion, the ‘best’ e-commerce sites anticipate your address as you type it into the ‘shipping’ address, and prompt you to select it, thus saving you the trouble of typing it all in. This is especially important when doing mobile e-commerce, and always welcome regardless of your device.

4 – Finally, it is always nice to either ask permission to save the payment method (credit card details), or at least let the user know that these details are not being saved, and are only used for encrypted transmission for payment processing at this moment. Too many cards are saved and later hacked, which is a great annoyance for someone using a lot of websites. Better to have a PayPal/ApplePay/GooglePay/AmazonPay option so a person doesn’t leave their credit card data all over the web.

Thank you programmers! You’ll make everyone’s life a bit easier with these simple improvements.

Posted in Uncategorized | Leave a Comment »

More Guilty as Charged “Bespoke” systems

Posted by Joel Schipper on February 10, 2020

As I’ve written in the past, it’s “bespoke” (aka custom) systems that seem to be the source of many “Guilty: As Charged” examples of software clumsiness.  Here’s another one with the increasingly common “MyChart” medical end user software.

You often need to check that your medical provider specialist “referrals” have been recorded in your MyChart.  My wife uses the Providence Health Care Systems “My Chart” (  But it’s not intuitive how to navigate to find these referrals.  In fact, I had to write to “Customer Service” to figure out how … and here’s what I learned. 

First, you navigate to the primary  heading of “Billing.”  Then you use a drop-down list called “My Insurance / Coverage Details”.  This brings you to a list of people covered — and you select yourself (or a family member).  That brings up a page with two tabs — the primary one is “Eligibility.”  But instead you need to select the tab called “Referrals” … and then you see the list of referrals.  Oddly enough, there isn’t a “more details” about an individual referral, but instead a hyperlink on the referring doctor’s name that brings up a new page with the referral detail.

Overall … a confusing and very intuitive way to see your referral information.  At least in this aspect, this seems like a system, “Guilty: As Charged!”

This Dilbert cartoon puts it in perspective

dogbert ctrl-alt-F4-DEL

Another software system that seems “Guilty: As Charged” is a conference registration system my wife and I recently tried to use to register for a conference focused on making books one at a time.  The navigational path was completely unclear. 

Did we first find a course and select it, putting it into a cart?  Why did it seem to want a partial payment (material fee) before processing my enrollment and other data, and asking for the full course fee?  How was the on-campus room and board connected to my enrollment?  None of this was clear, and to compound the problem, in the very first minutes that registration was open, classes were being filled, with an on-line counter showing the number of enrollment slots remaining. 

Perhaps this software was originally intended for college course enrollments which (at least fifty years ago in “my day”) could be very competitive.  But it seemed completely out of alignment with the business conference registrations that I’ve made over the last twenty five years, where the first information is about who you are, and only then moving towards to either conference content selection and/or conference fee payment.  I understood as we attempted to navigate this confusing piece of registration software that our fees were dependent upon our workshop selections, and beyond that, upon our selection of lodging and meal options. 

Today’s modern Cloud / SaaS software — and many e-Commerce experiences — are made far easier by a navigational process map that tracks what you’ve done (e.g., make selections, prepare to review your cart, make payment, etc.) and what steps lie ahead.  The conference software that was frustrating us had none of this.  And worse, relied on multiple drop-down menu’s to tie the pieces together, some of which kept saying that the opening of registration was on a given date, and not recognizing that the registration was in fact already open. 

Bottom line is that this packaged software offering, perhaps tweaked specifically for this organization/conference, is “Guilty: As Charged.”

On the plus side, I would like to give kudos to the wedding registry purchase page of  This is an excellently designed page where (at least in Safari on a MacBook) a fast typist can enter credit card and billing information without having to lift the fingers to use the keypad or mouse.  Congratulations!

Posted in Uncategorized | Leave a Comment »

Guilty as Charged? — The Caucus System

Posted by Joel Schipper on February 6, 2020

The software that failed the Democratic party in the 2020 Iowa caucus voting sure sounds “Guilty as Charged.”  Why?

  1. At the very least, the end users got confused over how to use the app.  This normally means that there was insufficient testing “along the way” during development of how the intended design was being realized though the actual coding or programming.  Quality Assurance during design reviews, perhaps with real end users and screen mock-ups, are a key way to detect these problems.
  2. If the design was OK in terms of usability, perhaps the problem lay in a program bug.  In that case, was there sufficient unit testing?  Completed application testing?
  3. And if the design was OK, and there were no coding bugs, then perhaps the problem lay in the ability of the system to scale to the volume of users that night.  Was there volume testing performed to equal the anticipated input levels?  Or did the (presumed) Cloud platform running the app not have the ability to detect volume issues and scale rapidly?

All of these are clearly avoidable problems.  So is the underlying issue the maturity of the programming organization?  It could be.  Given the reported “ease” of developing an “app” for a smart phone, and given the ability of non-career IT professionals to build an app, perhaps the Quality Assurance thought pattern that is required for enterprise system development was missing from the development of the caucus app.  And if so, what can and should we do about it?

Posted in Uncategorized | Leave a Comment »

Forecasting Maintenance Inventory with Descriptions?

Posted by Joel Schipper on May 7, 2018

Recently I came across a discussion in which an asset-centric company — a business that has a lot of assets (e.g., equipment) they are trying to maintain — was frustrated in the forecast and purchase of the parts used to maintain that equipment.  The discussion author was seeking a “better way” to utilize the descriptive fields in the item master to help “standardize” descriptions so that purchasing could better “forecast and buy” these items.  It’s clear that without standard descriptions a given “Pump Model ABC” could have been purchased once as Model ABC Pump, another time as ABC Model Pump, and again as Pump Model ABC, etc.  The discussion author wondered if non-stock inventory items were a good pathway, and dismissed the idea of creating standard stock items as too much effort.

But when I read this discussion thread, I thought — wait, a moment, what’s the underlying business issue here?  Having the right pumps and parts in stock when they’re needed?  Or reducing the effort of Purchasing when they are scrambling to buy that pump or part?  My experience with inventory management and procurement in a maintenance-centric situation is that standard item numbers — and inventory and consumption history — will be required, regardless of the perceived effort.  And here’s why, and what I wrote in response to the discussion thread …

If you are trying to forecast the usage of, and plan the purchase of, parts that have a consumption history, and will be used again, I strongly urge you to make them into standard inventory items, and to consider adding them to preventative maintenance bills of material; you really will not be able to make any forecasts without an established usage history, and JD Edwards [or any ERP system] requires you to do this via stocked items.

In maintenance management you have two types of forecasts:  the “known” or certain forecast that comes with the arrival of a preventative maintenance (PM) event — these happen every “so often” (time, hours, cycles, etc.).  When the PM event arrives, there is no guessing — the parts on the PM BOM are what are needed.  And you can “forecast” these events with relative ease, and add that forecast to an “MRP” run to buy the parts in advance.  The other type of forecast is more statistical, and is for “Break and Fix” maintenance events.  Only a history of issues, or a “two-bin” system of keeping enough in a back-up storage so that when you go to use the first of the back-up supply there is enough time to order a new “bag” or quantity of supply – can be used for an expensive item in which you keep only one or two reserve units, or for common, lower cost items in which you keep a carton/case or other “order quantity” in reserve at all times.

I suspect using these two types of forecasts – PM’s and Break&Fix – will overall lower your total cost of ownership through less purchasing “effort” and through higher overall “uptime” on the equipment being maintained, and that “uptime” is probably the highest value driver to you.  Equipment that is down cannot bring you any value while it’s down.

This approach will keep Your System: Not Guilty as Charged.  Going down a ‘descriptive’ approach — unless your parts are inherently attribute based items (and in that case use JD Edwards Attribute Management or similar product) — will more likely make your system “guilty as charged” later on … that is, you’ll never get the result you’re seeking, and the system will carry the blame.

Posted in Uncategorized | Leave a Comment »

Hard Coding a flexible structure can land you in a mess of Trouble

Posted by Joel Schipper on February 13, 2018

Recently I taught an introductory class on Oracle’s JD Edwards EnterpriseOne General Ledger module.  I posed this quiz question to the class to bring out how the soft coding attributes around a chart of accounts can prevent the “hard coding” of organizational structure or other logic into the account — which are always very difficult to change later after an implementation has gone live.  Here’s the quiz question:

The Object account represents the “what” of a journal entry, such as cash, sales revenue, cost of goods, travel expense, etc. The next field, the subsidiary or sub-account, when used as intended by JD Edwards in best practice, represents:

A. A more detailed slice of the object account, such as air travel expense

B. A departmental characterization, such as sales department travel

C. An individual entity, such as sales to Customer ABC.

D. All of the above are best practices

The right answer is “A” because if the object account represents travel expense, then a good or “best practice” use of the subsidiary or sub-account is to break this down further, such as air travel expense, lodging travel expense, etc.

Answer “B” is not a best practice because in JD Edwards, the object/subsidiary part of the account entry is always prefixed with the business unit (aka cost center or department).  And the business unit itself has 50 user defined ‘category codes’ to soft code it’s meaning, such as “Sales Department” and “Northeast” — using two of those codes.  So if the region is redefined as “MidAtlantic”, then you simply change the value of the code, with no impact on the design of the chart of accounts.

Answer “C” is wrong is a similar manner because of the ability to ad-hoc append a very granular “sub-ledger” value — such as the address number of a customer or supplier or employee, or a work order number, or a machine asset ID — to the transaction.  Again, there is no reason to ‘hard code’ this type of meaning into the chart of accounts.

Yet, I saw a presentation from a webinar recently in which the object account was being hard coded to have specific meaning.   The 1st 2 digits of the object account were being used to identify a department/division and the next 2 digits (positions 3&4) were representing the type of amount (i.e. asset such as cash, liability such as AP, revenue such as parts sales, expense such as labor).  This is a hard coded approach that can only lead to lead to trouble later on if and when “things” change.

A better approach would be to let the department designation reside with the business unit.  And to have the more detailed information in positions 3 and 4 either be an object account, or a subdivision of the object account using the subsidiary account.

In any event, sticking to the proscribed soft coding capabilities of your system will increase your chances of  having “Your System:  Not Guilty as Charged.”


Posted in Uncategorized | Leave a Comment »

Library Checkout Software: Guilty as Charged!

Posted by Joel Schipper on November 3, 2017

I don’t get to see that many “packaged” software offerings that are really “Guilty as Charged” … that is, the software really does a bad job of something.  And I don’t usually point out software names.  But I’m repeatedly frustrated at my local library by the check-out screen, from a 40-year old software outfit called Innovative Interfaces, and my suspicions were confirmed by the younger librarian at the desk.

There are two parts to the problem.

The first part is the user logon or sign-in.  Everyone knows that passwords emphasize the use of a mix of lower and upper case letters.  Yet this password entry screen has no upper case shift key on the screen … thus, even though you have a password with upper and lower case that works properly on the library’s web interface, the checkout kiosk ignores the upper case letters.  I fail to see the point of this.

The second part, though, is a more serious user interface problem, and has stumped me more than half the time I go to check out of a book.  Again, the web portion is great — I can search and reserve (‘hold”) a book easily on-line.  But when I go and physically get the book, and bring it to the check-out kiosk, I sign-in, and then lay the book on the scanner bed.  This part works great.  The problem is what to do next … one would expect to see a large and prominent button — probably lower right corner — that says “Continue” or “Finish” or “Press here if done checking out books”.  However, as they used to say on Saturday Night Live, “But, No!”  There isn’t any such button.  The only option remaining on the screen is in the upper right corner, and says “Sign out, Joel Schipper.”  Really?  Why would I want to sign-out before I feel like I’ve finished the book checkout function.  Every librarian I’ve encountered at my branch feels the same way.  Yesterday, the fellow said that Innovative Interfaces will not make this kind of change unless “all” the libraries who use the software demand the change.  Again, really?  Where is the desire to provide an outstanding user experience?  Someone at Innovative is way behind the curve here.

To be fair, the company is now under new (and private) ownership, with a new CEO.  A quick Google search brought up this article from the Library Journal’s website about how a new CEO (in 2013) was going to modernize the company and shake up it’s culture.  You can read it for yourself:  We’re waiting! 

Posted in Uncategorized | Leave a Comment »

Could the world have minimized the ransomware attack on XP?

Posted by Joel Schipper on May 14, 2017

The malware ‘ransomware’ attack that hit the world on Friday, and may continue in a new form tomorrow (Monday May 15, 2017) is not preventable, but the damage might have been a lot less if those in charge of institutional computer networks did their jobs properly.

This malware, which was reportedly stolen from the U.S. National Security Administration, attacks a vulnerability in the no longer supported Microsoft XP operating system (O/S).  Even though Microsoft offers a patch for the vulnerability, Microsoft has little or no ability to promote that patch to continuing users of an unsupported O/S, and certainly not to the zillions of pirated copies of the XP O/S.

Thus, if you are CIO (Chief Information Officer) or other official in charge of institutional computers, what in the heck are you doing running the XP O/S, and most especially what are you thinking in not doing everything possible to protect it while moving at full speed to get off of it?

Here’s what the New York Times reported today (May 14, 2017) about the lack of proactive protection despite warnings in Britian’s National Health Service (N.H.S.):

Britain’s defense minister, Michael Fallon, told the BBC on Sunday that the government was spending about 50 million pounds, about $64 million, to improve cybersecurity at the National Health Service, where many computers still run the outdated Windows XP software, which Microsoft had stopped supporting.

A government regulator warned [my emphasis] the N.H.S. last July that updating antiquated hardware and software was “a matter of urgency,” and noted that one hospital had already had to pay £700,000, about $900,000, to repair a breach that began after an employee clicked on a web link in an unsafe email.

“The threat from cyber attacks has not only put patient information at risk of loss or compromise but also jeopardizes access to critical patient record systems by clinicians,” the regulator, the Care Quality Commission, wrote in its report.

There should be consequences to those in charge of these institutional computers.  This should have been a less destructive incident – especially since the attack did not go against the Windows 10 O/S which has been on the market for almost 2 years.  I think this should have been “Your System:  Not Guilty as Charged.”

Posted in Uncategorized | 3 Comments »

A successful ERP implementation depends upon a proper “Pre-Sales” cycle

Posted by Joel Schipper on February 18, 2017

Recently I read an article from a consulting firm that guides software selections and advises on implementations.  The article was about the top 5 reasons why executives are afraid to undertake ERP and/or Digital Transformation Projects.  Reason #1 was executive fear that the project will take too long and cost too much.  The article offered these two safeguards:

“Our annual ERP Report shows that most projects either take longer than expected and/or cost more than expected. This statistic is often what drives fear. However, implementing strong project controls and governance is one way to mitigate this risk. Another failsafe way to address this risk is to ensure that you have a comprehensive implementation project plan that includes many of the hidden costs of implementation that most ERP vendors and consultants fail to recognize.” (My emphasis added).

These are great techniques, and absolutely required for project success.  But a project with hidden (“built-in”) surprises and problems needs more than those two remedies.  The missing, key critical factor for success:  A proper “pre-sales” cycle.

I don’t mean a demo, particularly one oriented towards a huge checklist of features that all the top ERP systems will be able to handle; as I’ve written before (more than once), that kind of demo is a waste of everyone’s time and money.

A proper pre-sales cycle allows the time for sufficient “due diligence” in discovering, documenting, and examining the critical aspects of the target company’s business practices and policies, and why these practices are needed for the company’s success.  These functions are what needs to be examined in sufficient depth, compared across competing ERP vendors, and demonstrated for usability and true degree of fit.

Simply saying “we perform function XYZ in our business operations” and having a vendor say “yes, we have a feature that allows you to do function XYZ” may not be enough.  ERP sales rep’s are strongly urged to avoid getting into “implementation details” when trying to make a sale, on the grounds that these details will confuse the customer – and slow down the sales cycle.  The unfortunate phrase is “Don’t confuse implementation with sales.”

But it is during “sales” that a company has the chance to discover if what they will need during implementation is actually met by the software.  Overlooking or bypassing the detailed examination of a crtical functional fit during the sales cycle will mean an extension of time and money through a customization or enhancement during implementation – or perhaps a sub-optimal solution through “work arounds.”  Sales and implementations are indeed tied very tightly together.  In that old phrase, the “devil is in the details” … and that’s what executives are afraid of.

Insist on a full and proper pre-sales cycle.  Don’t take vendor or consultancy reassurances that everything is “covered” when you haven’t seen it yourself – at least to the extent that you are personally confident that your critical features exist and can be implemented.


Posted in Uncategorized | Leave a Comment »