Understand how to manage the live demo usecase where multiple users connect to the same demo

[l2fprod]

related to #16

Let's assume we have deployed a Logistics Wizard demo in Bluemix. It has all the services deployed. It is accessible on the Internet to all Bluemix visitors.

The goal of the live demo if for clients to experience the app and also play with the scenarios like "a snowstorm" is coming. They run the business scenarios - not the more technical scenarios like "I want to simulate a connectivity failure of the database".

A new client connects to the LW demo site. She is prompted to register a new user id (should also be able to log in with 3rd party authentication like twitter/facebook/IBM ID).

Once logged, what does she see? We want to isolate the shipment data for other users. So we can have a new set of shipments created just for this user on first login. With the role/right management on the ERP service, we would make sure only her can see these shipments. This might require a customizable behavior in the ERP service to check more than the user role when returning shipments and also a way to identify a shipment as associated with a specific user. This would be needed only in the live demo scenario.

Once the ERP service API is able to filter shipments based on the connected user, the other services can use this filtering mechanism. As example, the recommendation service would have to make sure to only consider the shipments of the same user when making recommendations

Overtime we would want to cleanup the database too and get rid of users who registered a while ago but are no longer actively using the demo.

[l2fprod]

@benrondeau I need your view/review on how the live demo would work and what we should expect from an experience point of view when multiple users are concurrently using the live demo.

[uwefassnacht]

I think you have the flow right. A user is coming to the live demo:

If user is known:

• display same state of the demo that she left it at when she exited
• offer a button "reset demo" that would put the demo back into its initial state

If user is not known:

• register with password (also offer 3rd party auth, but lower priority)
• start demo in its initial state

[benrondeau]

@l2fprod Once we have personas finalized (maybe they already are @JakePeyser?) we can workout the experience they all will have with the app, including when they are using it concurrently

[jakepeyser]

@benrondeau check out the Personas page in the wiki - it's a draft, but I plan on refining them next week with the help of some folks from the JDE team

[benrondeau]

@JakePeyser Will do. I think it is important we shore these up ASAP, of which I will be glad to help drive.

[jakepeyser]

Personas being worked on in #45

[l2fprod]

pushing this back to TODO until we have better understanding of the data that will be shared vs. specific to a live session.

[jakepeyser]

User creates an account and logs in for the first time, they are presented with the initial demo state. This is comprised of an isolated data set for each new user. They are able to "reset" the demo whenever they need so they can revert to the initial state.

[jakepeyser]

Flow for working with demo sessions documented in the Demo Sessions wiki page. @l2fprod @benrondeau please review and verify this is what we discussed

[benrondeau]

I disagree with a username/password login idea. I think that when a session is created, a simple session ID is issued (like 14273) which can be used to revisit the session in the future. For example:

• User creates a session and plays around with the app.
• Using the session ID created in step 1, user revisits the app a couple days later to continue using the app. A 'continue previous session' option is offered and all they need to do is enter the session id to continue.
• After entering the session id, they re-enter the application and continue where they left off.

This approach gets rid of people forgetting their credentials, although they could forget their session ID, which we could just email to them if they'd like.

My two cents :)

[jakepeyser]

I don't see how a session ID make it any simpler than a username/password. The thought that @l2fprod and I had was to display the username/password in cleartext on the second screen. Users would not have to remember any credentials, only the name that they gave their demo session if they did not bookmark that page itself.

[benrondeau]

If they have to remember username/password, that is two things to remember. Session ID is only one piece of info. I believe that is simpler.

Regardless, I assume people will forget to write down their credentials and we need to have some sort of retrieve method (email them their credentials upon request, like a 'I forgot my login' function)

[jakepeyser]

Users would not have to remember any credentials

The username/password will be there for them on the page itself. The login mechanism will be all underneath the covers, we saw no value in instrumenting it for our demo. I can walk you thru our thought process if it is unclear on the Mural