Monday, February 27, 2012

Mary Poppins at the Devos Theatre in Grand Rapids - More Treacle than Brimstone

Perhaps it was the $50 nosebleed second balcony seats, or the cast figuring it's just those 'hicks from Grand Rapids,' but whatever it was being performed last weekend under the name of 'Mary Poppins' appeared so over-rehearsed and depersonalized as to be a sterile, mechanical experience with most of the performances being phoned in.

The 'updated' story has the somewhat scattered suffragette Mrs Banks becoming a frustrated former stage actress, the oblivious Mr Banks becoming a physically cruel father with a lewd eye towards the new nanny, and Mary Poppins becoming less of a magical governess and more of a 'good witch'.  In fact, the added musical bridges, insipid songs, and sung dialog had more to do with 'Wicked', 'Les Miz', and even 'Sweeney Todd' than it did with the Disney original. 

Obviously, the animated sequences would have been a challenge for a stage setting, but the substitution of naked statuary sans genitalia for the dancing penguins or singing lambs was just - well, creepy.  And the conversion of the "Supercalifragilisticespialidocious" song into a Richard Simmons-esque variation on a theme of "YMCA" was more sweaty than choreographed.  In fact, most of the choreography was pretty dreadful.  The "Step in Time" number was saved only by the character Bert's walk on the proscenium.

The sets were good, with lots of Germanic-cinema expressionism in the bank staging and some interesting forced perspective in the kitchen sequence.  In fact, given the Saturday afternoon experience with the musical, an hour or so of explanation of the operation of the set and how it worked would have been a far more entertaining outing.

In short, if you love the original movie, there is nothing added to this staged musical to make it worth your while.  Save your money and do as we did afterwards -- visit No. 17 Cherry Tree Lane on DVD and get all singy, sniffy, and sentimental.

I'm wondering now if the same 'creative group' will go after the filmed musical "My Fair Lady" and make an 'updated' stage version of it!?  Imagine - Freddy marries Eliza this time, Col Pickering hooks up with the head housekeeper, and Eliza can have a duet with her phonograph complaining about being tools of Henry Higgins....and they can sing all the dialog, since that's what MUST be done in any musical onstage these days!

Friday, February 24, 2012

Musings on Pharmacy Operating Systems

Having been circulating among pharmacies over the past dozen years, I have come upon several varieties of pharmacy-based operating systems, most of which have been designed by engineers and programmers without the slightest inkling of the primary operations of a pharmacy.
Invariably, these systems are chosen by department managers looking only at the bottom line cost, and rarely, if ever, with consideration for those who have to actually make use of the product.  The old canard "oh, there's always a learning curve," is usually invoked, when for the users, it's more of a "learning cliff."  And patients, trained for instant gratification and regarding a pharmacy as just a variation on McDonald's, don't give a rat's patootie that workers are gnawing their arms off during a conversion to an 'improved' system.
The software marketers create handsome websites extoling all of the functions of their systems, but - and I find this very interesting - never really show what their system looks like in practice.
Two systems in particular - one called 'Prodigy' (no relation to the old pre-internet online service) and the other called 'RX30' - are classic examples of this mindset.

Prodigy is an odd collection of jumbled screens, originally designed for nursing home 'cycle fills' (a process that quickly becomes a billing nightmare), unmatched fonts, complicated by a nonlinear work flow that has the user moving back and forth in the process of filling a prescription.  Its choice is usually by those who want a centralized access for billing, from several off-sites, for which it seems well suited.  However, for a user, it serves only to add about 50% to the processing time of a prescription, just in the back and forth of the workscreens.  A mouse is required, something that really ruins any workflow.  Operating two terminals, two trained and experienced employees, going breakneck, can process a max of 140 prescriptions in 9 hours (that's just processing, not filling, by the way).

RX30 suffers from similar drawbacks.  The screens are inconsistent in their layout, with function keys being especially challenging, as each one opens a set of menu options which then change depending on the screen.  Changing a spelling error in the prescription label, for example, means F1 > Workflow (the tenth selection in the menu options)  > Edit/label > F2 > toggle or mouse to instruction field > make change > F4 set (not just 'enter' - you have to 'set' the change with a function key)  > F5 reprint (or is it the other way around? Again, process over outcome).  For any clinical tracking, it has a 'comment field' that can be altered or deleted at will or whim (so useful progress notes will have to be kept separately in a word processor document set up on your own).   Getting a reprint on a label is another 4-5 step process. The pharmacy being introduced to this system usually does about 200 Rxs per day.  The backlog of unprocessed Rxs by 11am was about 50.  The POS process with the system is additional software, with a completely different set of menu screens, with lots of mousing and touch screens (and don't we just love the 24 hour virus life cycle on a touch screen device in a healthcare setting), and nearly a doubling of clicking processes.  It is obvious that RX30 just bought an existing setup for their POS - there is no integrated workflow with the pharmacy operating system.

It is apparent that these packages, while not inherently evil and possessed of some level of functionality, are at best poor examples of creating a useful or efficient workflow.  Neither of them have been developed by programmers who seem to 'get' the purpose of a retail pharmacy setting - to fill new prescriptions and refill existing ones.   There is far too much time wasted in twiddling and fiddling, almost as if they were developed by teams trained in algorithms of computer games rather than the stark, dull, workaday need to grind out prescriptions quickly and efficiently.  A stark example is that neither filling nor refilling a prescription are among the top choices of their opening menus.

And, it is interesting that it takes a team of trainers several days to 'educate' pharmacists (with 6 years of college) and their certified technicians (again, they are the ones who have to do this all efficiently) on how their systems operate.  That is a huge flag right there.  Systems can follow an intuitive design and flow.  Neither of these do.

When we hear 'oh it's only a few seconds extra time' for each prescription, these programmers need to understand that a few seconds, multiplied by 200, is a considerable amount of time during an already hectic workday.  They get paid by the hour - we get paid by the prescription.

Sunday, February 12, 2012

Experiment with Chroma Keying - ANM 239 at KVCC

The Cinematics/Animatics capstone class wanted to experiment with After Effects for a chroma key exercise.  I demonstrated the same work here using simple ol' Sony Vegas.  It's the technique, not the much time is spent learning software instead of massaging the mind...