Regarding the next poster that said the UI is bad and the system crashes when its overloaded. I am not good with this stuff by any means and found the user interface (assuming what that means) very easy. The website and mobile app gave me everything I needed on the homepage. Also technology problems can be identified and fixed, hence why they are doing voluntary tests. Just because it's starting out rough doesn't mean its going to stay that way forever.
No, they are not doing "voluntary tests"...
The website isn't "hey, do you wanna use this new website to book your ADRs and trip or the old one". ALL GUESTS experience the new website, whether or not they have bands.
Whilst you can opt out of the bands, the RFID stuff still exists, as does the App and MDE. You still use the same system, but instead of bands with Bluetooth tracking features (that is the
ONLY difference) you get an RFID enabled card.
MDE is already rolled out, the new ADR system is already rolled out, RFID readers at gates and in parks is largely rolled out. Bands and FP+ are a side system, meant to distract users from the larger impacts (well done to distract people from the larger infrastructure, I think, so kudos to whomever thought of marketing that).
As you said, technology problems can be identified and fixed...if there is a will to fix them. They never fixed them with their old sites...why would they fix them with their new ones? And, something none of us can say because we aren't privy...IF the original systems replacements (ADRs/Ticketing/Sales/Hotel POS/Other POS/Ticketing/etc) were designed in such a way to coordinate and allow them to be fixed, and there is a solid USEFUL documentation process involved. With MM+, I haven't seen this.
Here...I'll give you a real world example. I will use aliases because I can't really say who the actual "companies (yeah, we'll call them companies...but lets say they collect tax dollars...lets go with that)" are...
Lets say you build a Database. The Database needs to have something to identify each record...that's called a UID. The UID works at multiple levels in the DB to link records, and this is used to form relationships (I am not going to go on for paragraphs about how relational DBs work).
Well, lets say you pick a UID that isn't really unique...I dunno...like SSN. Then, years or decades down the road you want to merge this with another DB, which captures SSN, but has their own UID that they generated on their own.
Well, can't integrate (well). Why? Because you don't have UIDs in a true sense. (this is what I suspect they ran into with their hotel / ADR systems...the POS (Point of Sale, for those wondering) have been integrated for a very long time...)
Now, even worse, what if your DB doesn't have UIDs at all to tie to (common in many "purpose only" DBs developed in the 80s and 90s)...well, then your DB is wholly incompatible with integration, and must be re-developed. All while the proverbial "engine" is running (Guests still come and go).
I could go on and on about this...but, my point is this.
Disney is trying to integrate many disparate systems that were purchased (or outsourced or...I highly doubt...developed in house) at many different levels. To execs, they think...well, "there's an app for that", because they think that iTunes makes them technical geniuses. In reality, they have a VERY tall order for IT...and (as we've seen) an expensive one.
Now, could IT figure it out? Certainly. But, who should be the test subjects? Guests? Or should you invest in beta testing. Again, the same execs who think the fact they tapped their iPads a few times tonight to update to iOS 7 think...hum, this should be easy. Who needs alpha or beta testers? If it stinks, then IT obviously didn't do the job right. They say this without the faintest CLUE of the monumental task they have asked of IT.
All that being said, has Disney IT EVER on the go.com side been very good? Nope. The old website didn't work all that well, and the new one follows suit. The issue here is...YOU DIDN'T NEED THE OLD WEBSITE.
Disney is hanging it's hat with MM+ on the technology working flawlessly, which includes the clowns (yes, I think that's a good term) at go.com. All the while asking historically disparate systems to integrate on a level they were never intended or designed to do so, and not pumping (as they have found out) enough money into getting it to do so.
Some execs think "well, why not just farm it out to India or Romania"...well, dumbos (actually, that's an insult to dumbo), the reason is without a solid map of the business logic, you CAN'T do that, because outsourced programmers stink. In fact, all programmers stink if they either a) don't know what you want to accomplish or b) they don't know what YOU want. Most of the time execs assume that you can just say a few words to a programmer and they'll get it, but that's complete crap. Programmers will do EXACTLY what you ask them to do...passably. That is why they are good programmers. Because they think logically, in steps...like computers...like code.
And, if you don't hold their feet to the fire, they will pass you crap code. If you leave design up to them (since they don't understand your overarching business concept, since you were "too busy" to explain it to them) they won't design their systems to integrate...
Ugh, I need to end this rant here before I start to get ugly about it...
