RTS App - "access to Everything"

[Frank Cox]

Writing an app is a bit different and requires a somewhat different skillset than writing a program for a general-purpose computer. (It's not hard, at least on Android, but it's a bit of a kink for someone who's used to procedural programming like me; today's kids - get off my lawn! - may find it otherwise, of course.)

I wonder if they had a contractor write a framework for their app so they can just plug in the theatre name and customize it a bit when they sell it to their customers. Whoever wrote the framework may no long be available to make changes.

[Mike Blakesley]

I don't know, but RTS is a home-grown program (or at least, it's always been that way) and the fee they charge for this app is pretty low (25 cents per transaction, not per ticket) so I have a feeling the app is home-brewed too. I have this vision of a bunch of new young nerds going to work for them and coming up with this app plan. And since they may not have run it through a professional comprehensive test program (like the one my wife works for), this issue didn't get caught.

As noted before, I am guessing the problem lies where they registered the main structure of the program with Apple and Google and if they change it now, they'd have to go through all those hoops again. Which is totally understandable, but doesn't help with uneasy customers who have heard a million stories about ID theft.

I wish we had someone from RTS on here who could weigh in on this but I guess we don't.

[Marcel Birgelen]

You probably don't know, but is their app a "proper app" that has all its content inside the app or is it, like many apps out there, just another "kiosk app", that essentially just starts a web-browser without an address bar and connects to a web-application? In the latter case, updating the content inside the app should be pretty straight forward. In all other cases, you need to re-submit the app to the Google Play Store and Apple App Store. For small updates like this, the process should be quicker than for the initial publication.

[Mike Blakesley]

You're correct - I don't know. In my last email to them, I asked them to explain again why they can't change the privacy notice. (I had their other explanation but I deleted it.) When I get that, I'll share it here.

[Carsten Kurz]

Well every app receives updates quite regularly, and I wouldn't understand why a change to the privacy statement could not be updated the same way.

[Randy Stankey]

Agreed! Wholeheartedly! That's the standard way to fix problems, isn't it?

App publishers push updates to amend the User Agreement all the time. Why would this be any different?
It should be a problem that can be fixed in less than an afternoon's work. Heck! Some person could probably fix it before lunch break!

This is why I said what I did, earlier. Okay, yeah, I'm using hyperbole, above here. Maybe it's not a problem that can be fixed in an instant, simply by pushing an update but it's not a Herculean task, either. It's something that a reasonably competent person should be able to do if he puts his mind to it.

There's the crux!... "Putting one's mind to a task."

They all but refused to even put their minds to it!

That's laziness... Disregard... Rudeness... All around bad business.

As I said, above, if they aren't even putting their minds to something so simple as fixing a few sentences in their license agreement, I shudder to think what else they aren't putting their minds to that they should be.

[David Bird]

In the same type of scramble everyone had last summer as to "how to operate", we set ourselves up to use their app for advance tickets as well as concessions. At one point in Ontario, we were banned from selling at a take-out window and had to try to figure out a way to deliver food to cars. We ended up using the web-based app for tickets only because there was no way to quickly remove an item you had run out of without re-starting the system, but worse, there was no way to refund a customer if they had selected and paid for something that you either had run out of or they changed mind, etc. The web ticketing app had some sort of glitch where our batches weren't clearing, we still haven't totally figured out why, and since we were not selling tickets at the gate during that time, we went nearly 2 months with no ticket revenue. It did eventually get sorted out, however some transactions were left "hanging" long enough that the funds were returned to the customer, and then months later when the batches got "forced through", the charge showed up again on their cards. We had to explain to everyone that we were not putting through fraudulent charges. Most people were able to confirm this and understood. Unfortunately, we've had at least a half-dozen transactions that got pulled back by the bank anti-fraud protocols and truthfully it's such an ambiguous mess to try to prove it's not, we'll just eat it. The timing to replace cash system hardware (RTS program apparently has a "poison pill" which won't let new software get installed even if it might otherwise work) with the uncertainty in the industry is not great, but to me RTS has just not changed and is very cumbersome. We've kept it because it is somewhat remote-managable (there's no chance it's anywhere close to intuitive enough for young staff to manipulate), but I don't know, it's really becoming hard to work with.

[Mike Blakesley]

RTS has just not changed and is very cumbersome. We've kept it because it is somewhat remote-managable (there's no chance it's anywhere close to intuitive enough for young staff to manipulate), but I don't know, it's really becoming hard to work with.

I can't disagree with any of the above. We've been using RTS for nearly 20 years and while a lot of new features etc. have been added, it's not exactly the whiz-bang program it should be considering what it costs. The only reason we haven't changed from it is, it's familiar and I will say that they are VERY responsive when it comes to problems. (Except the one that started this thread.) They'll do what it takes to get you rolling again, even if they're often somewhat grumpy as they do it. I can't count how many times I've thought about changing to something else, but then have backed off at the last minute because what we have now might not be perfect, but it does work.

My feeling is, and keep in mind that this is coming from someone who does not know anything about writing software or coding. But I think RTS is just a lot of old code that has been added to and added to and now it's just a bloated mess. You can get done what you want to do, but (especially in the ticketing part) the process used to reach the goal is very daunting.

We had the same issue with the computer software we used to use at our auto parts store. The rest of the world was moving at the speed of light and we were still in the horse and buggy days. Finally the company upgraded to a newer system which was much better, but now it's starting to suffer the same fate -- they keep piling features on to it, but the understructure isn't enough to support all the bloat and it winds up crashing under its own weight. (Not always literally, but figuratively.)

[Marcel Birgelen]

Despite the breakneck speed a lot of stuff is evolving, coding software takes considerable resources. Doing software right isn't easy, especially if you want to keep future expandability in mind. It doesn't help that the entire software industry is a constant moving target. Software frameworks come and go almost as fast as you can do a Google search. Most of the new stuff nowadays is being developed as web-application, based on frameworks that will become unsupported legacy in just a few years down the road... We've been there ourselves.

This always-online aspect hasn't made software development any easier, as a completely new aspect entered the scene: Security. If you look at software of yesteryear, it often didn't give a damn about actual security. Nowadays, with stuff being on-line all the time, security has become a major burden for software development. And those who neglect this, will come to learn the hard lessons rather sooner than later.

[Frank Cox]

There's a water vending machine that I wrote in the mid-80's that's still running to this day, and a program to log oil well production that I wrote just a few years after that. Both of those are written in Turbo C and run on DOS. They're working fine and neither one needs to be fixed. The hardware has been changed a few times, of course. You can get some really nifty minature DOS computers these days too.

These days software that I (occasionally) write usually targets https://invisible-island.net/ncurses/ for user interaction simply because it tends to be we might look at again in twenty years stuff. I use ncurses because it's not difficult to learn, runs on almost everything Unix/Linux, and hasn't changed in any significant manner for many years.

I spent quite a bit of time looking for a similarly slow-moving GUI toolkit and a few years ago I discovered http://xforms-toolkit.org/ (which is not the same as the xforms webform thing.)

I haven't actually done a lot with xforms-toolkit other than play with it a bit off and on and there hasn't been a suitable project come along for using it yet. But it beats the socks off of gtk and the like for my purposes since it's a plain-jane C library and the api hasn't changed in years, just like ncurses. So it suits me fine.

Gtk is actually pretty cool and I've done a few odd and ends with it, but it's such a monolithic thing that wants you to do everything through it and it's a moving target. "I see that you just updated your system. Here's two kitchen sinks and a cat."

[Marcel Birgelen]

We're drifting a bit, topic wise, but since the zombie apocalypse is still upon us I consider that as a "good" excuse.

The good thing about ncurses apps is that they work over any plain terminal connection, like SSH, no need for some local XServer or other screen-sharing stuff like VNC, X Windows, RDP or Citrix... The problem obviously is that people expect a bit more from their user interfaces nowadays. Gone are the days when people got the same job done with old-school serial VT100 terminals.

For cross-platform desktop compatibility I've been using WxWidgets for ages. The nice thing is that they're pretty well supported in the two primary programming languages I tend to use nowadays: Python and Erlang. WxWidgets works nicely on Windows, MacOS X and practically all X Windows implementations out there and it also supports "native looks", so it integrates with the look and feel of the particular operating system. The only thing it doesn't support are mobile platforms, which is a bit of a bummer, but then again, mobile apps usually need their own, special views. Most mobile apps I've been involved with ended up being of the "kiosk style", where they essentially just load a web-page that looks like a mobile app...

[Frank Cox]

Wxwidgets doesn't support C. And since I've never really had a good reason to learn oop, it's something that I've just never done. I stick with functional/procedural stuff in C and, well...

Tyrannosaurus-Rex-Struthiomimus-dinosaurs.jpg
I guess that's me. Whether I'm the one in front or behind depends on the day....

[Marcel Birgelen]

I guess it depends also on perspective...

I guess I'm the T-Rex with my bloated, modern OOP language. I look mighty impressive, but once you start running, I won't be able to catch you.

I've never done much UI-work in C, to me, it somehow it feels like C wasn't meant for that, It's after all just a glorified macro assembler. :P

[Mike Blakesley]

I wrote our first computer-based ticket selling program in BASIC. It had a few capabilities that even RTS doesn't do, such as being able to output a report of the year's movies and sort it by gross, studio, rating, alphabetically, etc. I would sit here in the evenings and tweak new features into it on a regular basis. I used it for at least 10 or 15 years until RTS came a long. I think my ticket-selling screen was more attractive than RTS's is today, although I didn't have touchscreen capabilities of course.