Very cool device! It does lack in accuracy. Pitted dice are off balance and the 1 will land on the bottom more often than not. That is why Vegas does not use that type of die. There is error in the machine; look closely at the video where the dice get stuck at the top.
Ah. But they were. The list was meant to highlight the milestones in the historical pendulum swing. The first web browsers were definitely dumb terminals. Dumb terminals, in the before time, used special characters in the data stream, often called Field Attribute Characters or FACs, that would signal whether or not the following characters were a data entry field, or highlighted and/or blinking text (showing my age here). The browser protocol just replaced these with verbose HTML tags (which provided only slightly more flexibility).
Add-ons are just hacks. I know that sounds bad or derogatory, but it is true. They are features the original browser designers had never imagined. Browsers are evolving, which is good, but they are way beyond their original intent and struggle to find common ground. But this goes to my case in point. As they evolve, with add-ons, to make up for what the core lacks, you are moving the pendulum back to client-side processing. You are migrating activities from the server to the client. Your client is getting fatter (richer). Why? Is the server overloaded? Bandwidth? More likely, it is to fill the gap in usefulness, by reducing the server round-trip response times.
Browser applications with add-ons are evolving to replicate the same immediacy and usefulness that we had 20 years ago with LAN-based enterprise applications. We grew fat and happy with 10Mbps of bandwidth on the LAN. And of course, eventually 10Mbps wasn't enough, many applications grew to need 100Mbps to handle client traffic. Gigabit anyone? We had to retreat to dumb terminals (browsers) to deal with the limited Internet bandwidth, which is exactly why terminals were dumb years ago, when the LAN cabling was coaxial (or twin-axial).
Remember, at the dawn of the Internet era, most people had only a 23Kbps modem. Most pages were sparse and you had to click on a link to a picture if you wanted to view it,
Why struggle with a browser to build an add-on to do your client work? Why not just build a rich client that communicates directly with the server and does exactly what you need? Lean and mean custom protocol for massive speed! It will do whatever you want and not contend with browser deficiencies and incompatibilities? Of course, this is in the context of an effective enterprise application and NOT a public portal, which is best suited for browsers.
It sounds as though you are championing the thin-client-server model with a browser. You are the "boots on the ground" that must take care of the systems. You can conveniently fix the user's computer, fire up a browser and off they go. And of course, since you know which browser works best for the application, you install the right one.
Our application is also client-server model but with a custom rich interface. It is written in Java, and in the last 8 years we've only had one incompatibility issue across operating systems. We may be the guys in the White Towers developing the software, but with our framework, we developed a deployment utility, aptly name Connex. It is a 256K program that you download to their desktop. You run it, enter your credentials, pick your app (optional), pick your server (optional) and the software installs all by itself. If the user is having a problem, even perhaps corrupt files, they can press one key (F5) before they login, and the utility will inspect each file (checksum) and replace any that are missing or invalid. What is not to love about that.
We have never encountered a cross platform incompatibility or collided with other software. If we do encounter an error, we can retrieve the Java stack traces from the user with a simple download through our user administration utility.
Since we control the whole tool chain, from client to server, including the UI, we don't spend ages getting the various browsers to behave, act consistently and suffer through the browser wars version after version.
Therefore, the browser is convenient for you, saving you time and headaches. I admit it saves time, and as a tech, it saves expensive time. But what about the user? Assuming you only need to correct such problems occasionally, the user must deal with the browser interface for hours on end. What about their convenience, time and headaches?
We've seen all of this before and we will see it again... (I've heard that line somewhere before)
So where do rich clients apps fit in the pendulum swing? I think rich client apps give developers absolute control over where a process runs. They take more planning and deliberate server communications, but I believe the payoff is huge. We developed a Java rich client framework for our applications development. We develop under Linux and test and deploy to Windows users. We never tested it on Mac, yet we just had a Mac savvy user install it and run without issue!
Don't buy the argument that rich clients apps are too hard to distribute. We built our own tool that will reconcile the installed Java class files at user login. TALK ABOUT A MASSIVE TIME SAVINGS in both support and debug! It ensures all users are running the same version, all files are checksum validated, and since we deploy files at the
As for performance, we run rings around browsers! Our framework implements both in-memory and persistent object caching. It is a true n-tier architecture where a hierarchy of caching servers receive and broadcast updates which optimizes slower connections. For high volume customers we install a caching server behind their firewall to consolidate traffic over the net to the server.
The payoff? Users can view large sets of data, change sort orders and instantly change their view on the data, all of which occur solely on the client side. It happens quickly, without breaking the users train of thought. Our framework regularly can easily deliver 50,000 objects to a client application for them to view and manipulate, and should any one of those objects change, they will see that change immediately. Not going to happen with a browser any time soon.
We have customers running our software as a service using only a cellular connection for an office of four users. The framework is completely optimized for slow connections; once I gave a 30 minute demonstration of our inventory software using a laptop and cell connection. Afterwards, I showed them the connection stats; the total download was 4MB and the upload was 750KB. For contrast, I then spent less than five minutes browsing their current website which quickly racked up over 15MB of bandwidth.
The web has it's place. We would not expect any anonymous visitor to download and install an application. It is the right solution for the broader market, but I refused to roll back the user interface and usability 20 years and abandon the power of the desktop computer to use a web browser for enterprise solution. The web is convenient for everyone, optimal for no one.
This announcement has had an immediate impact on my use of the service. I got notice this morning that they received my returns and that I could rate the returned selections. I cringed (in anger) and figured rating them would be completely pointless. There is no way their suggestion feature will even come close with three profiles rolled into one. The signal-to-noise ratio will be pathetic with the induced noise from my wife and kids profiles.
"Fix" one part of the service and break another. Oh, and piss off your customers too.
Perhaps some miracle movie selection algorithm has evolved from their netflix prize contest, requiring all movie ratings be rolled into one profile. (Yeah, right.)
Motivated by money? Surely. Careless with greed? Likely.
I've noticed several design suggestions in your code.
