DCL Testing a Navigator App on the Fantasy!

[sweetpee_1993]

I just read this:

DCL is testing a new mobile app for their Navigator's while on-board. It's currently limited to the 9/7 & 9/14 sailings of the Disney Fantasy. The app will connect to the ships WiFi network for FREE to get it's data.

Search Disney Fantasy in the Apple app store or Google Play store. Once the program is fully launched, it appears as if there will be a separate app for each ship.

I'll be on the 9/14 Fantasy! Guess I'll be reporting on this for y'all!

A little hesitant, tho. Are the cruise ships going the way of the MM+ crap?????

 

[DISNEY FANTASY]

Report back on it, I saw this direct earlier today its a great idea,

 

[sweetpee_1993]

Report back on it, I saw this direct earlier today its a great idea,

Definitely will. I wonder if I'll be able to sneak-connect my MacBook, too!

 

[DISNEY FANTASY]

Definitely will. I wonder if I'll be able to sneak-connect my MacBook, too!

Lets see!

 

[joanna71985]

I like this idea! I really hope it works out

 

[DISNEY FANTASY]

I like this idea! I really hope it works out

Agree!

 

[Bolna]

I think part of the software for doing this app might be coming from NextGen, so I think it is more of a byproduct. I don't think that this means that all aspects of MM+ will come to DCL. I rather think that MM+ tries to get some of the cruise industry system to WDW, so just the opposite. From everything I have read about other cruise lines there it seems to be standard that you for example can make reservations for certain things via your stateroom TV. This I think would be similar to reserving FP+ from your app.

For me the two elements I don't like about MM+ is the tracking and data mining as well as the booking FP+ 60 days out. Since you need your KTTW card already now for so many activities, DCL already gets a lot of data from you. I don't think they need more as the space you move in is much smaller, so it is far less interesting for them to know which elevator you regularly use than it would be for them to find out which attractions you go on regularly. So I can't see them ever investing in the tracking element. And the reservation thing: that's already in place with booking Palo, Remy, spa, excursions so many days ahead. What else would there be to book? The tastings maybe... But I think that is something that is decided on a shorter notice which they offer, so it makes no sense to book these far ahead.

I can even see that people would like to have a MagicBand on the cruise. You can wear it in the pool, it is more comfortable than the current kids club bracelet.

So I think if DCL gets stuff from Next Gen it actually will be the more positive sides of it, not the negative ones.

On the app though: I would wish that you could access the same data through the stateroom TV though as it would give those people who don't have a smart phone the same access. I know that my IPhone will live in the safe again when I am on a cruise. One of the best things on the cruise was not to carry any stuff around with me that I need to watch. But I think it is a neat feature and might help you sort through the activities in a better way.

However, for me one of the nicest things during the cruise is to settle into bed in the evening and read through next day's navigator! Can't imagine it being as nice if it is the app...

 

[5thGenTexan]

I think its a cost cutting measure. The Navigator is A LOT of expensive color printing.

I don't do a great deal of cruising, but when I do I turn my phone off and put it in the safe with my car keys, wallet, passports.....

One more note, I don't even own a smartphone of any kind and this would be a bummer if the paper version were totally discontinued.

 

[flynnibus]

They need to make the app support messaging without requiring internet. Then I'd see a huge use for it... get rid of wave phones and put the navigator in your pocket with reminders and maps? Then I'd see a killer app.

 

[englanddg]

They need to make the app support messaging without requiring internet. Then I'd see a huge use for it... get rid of wave phones and put the navigator in your pocket with reminders and maps? Then I'd see a killer app.

A VoIP client could also be used for audio / video chat on the ship LAN.

A server on board (actually, I'd run two for failover) could easily handle the load / provide the services, and sync with the main servers onshore at intervals. The guest wouldn't notice at all.

Issue is...there are parts of the ship that need some more repeaters (Aft balconies, for example)...but that's rather easy to fix.

Add in magicbands, and I think this is a fantastic idea!

 

[flynnibus]

A VoIP client could also be used for audio / video chat on the ship LAN.

A server on board (actually, I'd run two for failover) could easily handle the load / provide the services, and sync with the main servers onshore at intervals. The guest wouldn't notice at all.

Go back to the mainland for what?

Disney shouldn't offer connectivity to the internet without charging for it. But offering a local 'fog' network where the navigator and onboard services are offered is something I think should be within the 'free' category because it enables things onboard and stands to reduce ongoing costs for the company.

Videochat would just be a risk IMO. It puts more load on wifi, meaning you must build your network out more in a technology that is a luxury that most opt not to use anyways. Offering realtime synchronous data is many times more taxing on the network than simple http data that can afford to be delayed.

 

[englanddg]

Go back to the mainland for what?

Disney shouldn't offer connectivity to the internet without charging for it. But offering a local 'fog' network where the navigator and onboard services are offered is something I think should be within the 'free' category because it enables things onboard and stands to reduce ongoing costs for the company.

Videochat would just be a risk IMO. It puts more load on wifi, meaning you must build your network out more in a technology that is a luxury that most opt not to use anyways. Offering realtime synchronous data is many times more taxing on the network than simple http data that can afford to be delayed.

For data collection by Disney. What else? <grin>

And, I agree, audio only. But, still, doable on the local wifi there (without having to go to servers)...

Easy to write an app that connects to a server on the ship that hosts the communications.

 

[flynnibus]

For data collection by Disney. What else? <grin>

And, I agree, audio only. But, still, doable on the local wifi there (without having to go to servers)...

Easy to write an app that connects to a server on the ship that hosts the communications.

Mainland vs onboard is a non-factor for any chat services. client media is point to point and registration is easy enough to do locally. What Disney would have to tackle doing 'on-premise' on the boat is the authentication. Services should be tied into your centralized Disney profile.. which is hosted back on the mainland. Disney would have to have an onboard cache or copy of the disney profile services. Probably something they've already tackled for it's network of subsidiary companies.. but making that work without dedicated network may be a fun challenge.

I doubt such an app would negate the need for printed navigator copies in every cabin.. but certainly could enhance the guest experience IMO.

 

[englanddg]

Mainland vs onboard is a non-factor for any chat services. client media is point to point and registration is easy enough to do locally. What Disney would have to tackle doing 'on-premise' on the boat is the authentication. Services should be tied into your centralized Disney profile.. which is hosted back on the mainland. Disney would have to have an onboard cache or copy of the disney profile services. Probably something they've already tackled for it's network of subsidiary companies.. but making that work without dedicated network may be a fun challenge.

I doubt such an app would negate the need for printed navigator copies in every cabin.. but certainly could enhance the guest experience IMO.

Easy enough to migrate profiles once one "links" the cruise in the My Disney Experience app / website. They do one final dump to a server onship while at Port of only the records required for basic authentication, done deal.

Users then put their phones on airplane mode, connect to the ship wifi and they route DNS to a local server on board for onship applications vs offship surfing.

Easy peasy.

 

[flynnibus]

Easy enough to migrate profiles once one "links" the cruise in the My Disney Experience app / website. They do one final dump to a server onship while at Port of only the records required for basic authentication, done deal.

Users then put their phones on airplane mode, connect to the ship wifi and they route DNS to a local server on board for onship applications vs offship surfing.

Easy peasy.

Not so easy...
1) users are not isolated and locked. Your solution needs to support password resets, forgotten passwords, users with actual internet access making changes, etc. Any changes made onboard need to be synch'd with the mainland, etc. You want a system that can authenticate locally, but you can't assume an exclusive copy that is disposible at the end of the cruise.
2) 'a final dump' is still trying to take the entire Disney/Go user footprint That is sizable, and on top of that is a whole new security risk, etc.

A more practical scenario is a solution that authenticates via proxy.. but the challenge is how to cache to reduce network load and provide services when internet access isn't available at all for the boat. You don't want the whole system being susceptible to that. Copying authentication services almost never is the answer.. its generally safer to design the system to provide max functionality even when authentication is unavailable.

 

[englanddg]

Not so easy...
1) users are not isolated and locked. Your solution needs to support password resets, forgotten passwords, users with actual internet access making changes, etc. Any changes made onboard need to be synch'd with the mainland, etc. You want a system that can authenticate locally, but you can't assume an exclusive copy that is disposible at the end of the cruise.
2) 'a final dump' is still trying to take the entire Disney/Go user footprint That is sizable, and on top of that is a whole new security risk, etc.

A more practical scenario is a solution that authenticates via proxy.. but the challenge is how to cache to reduce network load and provide services when internet access isn't available at all for the boat. You don't want the whole system being susceptible to that. Copying authentication services almost never is the answer.. its generally safer to design the system to provide max functionality even when authentication is unavailable.

That's overthinking it. An no, no way would I suggest they dump the entire user footprint for Disney/Go (that's funny).

Simply have a ship specific authentication system hosted locally on the ship which can be linked to the Disney/Go account for the duration of the cruise. It would involve the creation of a few fields in each DB...nothing uber complex.

To the end user, it would be seamless. Much like linking "tickets" is in the current system.

 

[flynnibus]

That's overthinking it. An no, no way would I suggest they dump the entire user footprint for Disney/Go (that's funny).

Simply have a ship specific authentication system hosted locally on the ship which can be linked to the Disney/Go account for the duration of the cruise. It would involve the creation of a few fields in each DB...nothing uber complex.

To the end user, it would be seamless. Much like linking "tickets" is in the current system.

That requires creating new credentials that are unique to the ship because you still need to authenticate the local user session. 'Ticket' linking is different because there is no authentication with tickets and the biometric data is resident to the ticket/gate system.. not linked back to Disney/Go.

Linking that 'local only' token to the Disney profiles would require actions performed while you still have access to the main Disney/Go profiles. DCL can't link everyone ahead of time because not all users will have supplied their Disney/Go profiles prior to the the cruise. Users on board can't associate them (with validation) without network access.

Once you chose to have local only user profiles, there is less advantage to linking to Disney/Go at all because it adds so much complexity for limited gain. The point of using Disney/Go is to avoid having to create new logins, using singular identities, and to be able to persist data after the cruise.

You don't want people associating local tokens or identities to your Disney/Go identities without validating the Disney/Go profile.

This is too much of a technical discussion for this thread... but federation with limited network connectivity is a challenge.

 

[englanddg]

That requires creating new credentials that are unique to the ship because you still need to authenticate the local user session. 'Ticket' linking is different because there is no authentication with tickets and the biometric data is resident to the ticket/gate system.. not linked back to Disney/Go.

Linking that 'local only' token to the Disney profiles would require actions performed while you still have access to the main Disney/Go profiles. DCL can't link everyone ahead of time because not all users will have supplied their Disney/Go profiles prior to the the cruise. Users on board can't associate them (with validation) without network access.

Once you chose to have local only user profiles, there is less advantage to linking to Disney/Go at all because it adds so much complexity for limited gain. The point of using Disney/Go is to avoid having to create new logins, using singular identities, and to be able to persist data after the cruise.

You don't want people associating local tokens or identities to your Disney/Go identities without validating the Disney/Go profile.

This is too much of a technical discussion for this thread... but federation with limited network connectivity is a challenge.

Yes, and neither of us have gotten too technical...best to stop it now before it does.

Still, going back to your comment that started this conversation, I agree, it would be neat!

 

[1023]

Just use MAC id from the device to create the "on board" auth profile after initial authentication. The MAC ids can be stored locally and purged between voyages. The app "for ship use only" could use a local challenge for auth if need be. That way only an outside call would be done only if required. I'll have to think about it.

*1023*

 

[Bolna]

Ahem - could you take your techno babble to the Chit Chat forum please?????