Catalog shopping cart release update

[zsgoreczky]

As I have mentioned in my previous post, the engineering team is working on adding a shopping cart to Catalog. We have broken down this improvement into 3 different phases, and we will roll them out to Catalog Beta in 3 different steps.

The Shopping cart will affect multiple screens in Catalog. The main home page will have a shopping cart icon if an item is already added to the cart, the listing page (or details page) will have an ‘Add to Cart’ / ‘Remove from Cart’ button, and the enrollment congratulations page will also change a little. 

Since some of the institutions have their Catalog home and listing pages customized, we would like to make sure that you can see these changes as early as possible. The reason for this is that some Catalogs have custom colors for the header of the home page or the buttons of the listing page. In this case, the shopping cart icon and the ‘Add to Cart’ / ‘Remove from Cart’ button will have a different color as the other components. We would like to make sure that you have ample time to adjust the new icon and buttons’ parameters, if you wish to do that.

Consequently, we are going to add the shopping cart to Catalog Beta incrementally with the three steps noted above. This does NOT affect production—we are not going to release the shopping cart to production until December. So the incremental release affects ONLY Catalog Beta environments.

So as step 1, you will see the shopping cart icon in the header) and two new buttons on the listing page (next to the thumbnail and at the bottom of the page). Clicking the shopping cart icon will open the cart preview, and clicking Checkout in the preview will open the checkout page. Please note that the checkout page will not work properly yet, as it is still under development. 

Please stay tuned and keep an eye out for the Beta release.

UPDATE: Today (October 21, 2021) we have turned on the first batch of changes in the Beta environment. 

UPDATE 2: Yesterday (November 16, 2021) we turned on the second batch of changes in the Beta environment. This release contains the checkout page and the 'All Done' final page that we show once the payment / enrollment has gone through. 

UPDATE 3: Today (December 16, 2021) we have released the last batch of changes in the Beta environment. This is the scope of the January release. 

UPDATE 4: Today (January 5, 2022) we have released shopping cart to production. 

[jsowalsk]

Thank you for the update. We look forward to seeing this! @zsgoreczky Will there be release notes for this?

[zsgoreczky]

Hi @jsowalsk we will have the release notes available once the entire feature is launched. I will update this thread every time we roll out one of the three phases. 

[jsowalsk]

Great, thank you @zsgoreczky! We appreciate it. Does this include beta notes or just production notes?

[zsgoreczky]

We will aim for getting the release notes out by the time of the last beta release. 

[jsowalsk]

Ok, thank you, @zsgoreczky.

[zsgoreczky]

A quick update: Today (October 21, 2021) we have turned on the first batch of changes in Beta. 

[jsowalsk]

@zsgoreczky I just tested it and I think our instance has a lot of issues due to customization work. But, how long will this update be in beta for?

[zsgoreczky]

Hi @jsowalsk This is exactly the reason why we have rolled out these changes at such an early stage. So institutions have enough time to adjust their custom code and fix the off components. 

These changes will be in Beta until December, when we will have the Prod release of the entire feature. 

[jsowalsk]

Great, thank you @zsgoreczky.

[albertina_clayt]

I took a look at the first batch of changes in the Beta environment. We're only going to need to make a few minor tweaks to the footer button but otherwise the new shopping cart feature looks great! I'm looking forward to seeing the next batch once those are turned on in Beta.

[william_trest]

@zsgoreczky Initial thoughts about the cart is that it looks good and seems to function well. One constructive that I would like to offer: It may be good to change the enroll button to "checkout in cart" or something once an item has been added. This would take the user to the cart instead of the default listing checkout page.

For example, if I add a course to the cart, and go to a second listing, I can still click the enroll button that bypasses the cart. If I wasn't looking for the small-ish shopping cart icon at the top of the page I might miss it and accidentally enroll in the single course instead of my desired multiple courses. I hope that makes sense. 

I think it may make more sense to have both buttons go to the same place. If there is a use case for having items in the cart, but purchasing only the listing being viewed, then maybe a "Buy Now" button that is smaller or secondary. 

Anyway just my initial thoughts... Great job team!

[jsowalsk]

@william_trest Great points. I didn't even think of this. It is pretty much a bypass to the cart.

[zsgoreczky]

Hi @william_trest Thank you for sharing your feedback. We are going to change the behavior of the flow for the 'enroll' button and it will work as you have described it in case shopping cart is turned on for the institution. We will also keep the existing flow in case an institution either doesn't want to or cannot use shopping cart. 

I will send an update once the next batch of the feature is out in Beta. 

[jsowalsk]

Thanks, @zsgoreczky. Can you please describe this piece: We will also keep the existing flow in case an institution either doesn't want to or cannot use shopping cart.  

Thank you for your feedback @william_trest.

[william_trest]

@zsgoreczky Thank you! That sounds great. I think this shopping cart will help our users very much. 

[zsgoreczky]

@jsowalsk There might be institutions who don't want to use shopping cart or they cannot if for instance they have their own custom enrollment flow and they don't use Catalog's flow for it. In such cases we can exclude these institutions from the shopping cart release and they will be able to use their existing flows. 

[jsowalsk]

@zsgoreczky Thank you for clarifying.

[taevans]

@zsgoreczky We were wondering how shopping carts work across multiple sub-catalogs that are under one parent catalog. In our instance, for example, we have our top-level Catalog and then each of our various colleges/units on the platform have their own sub-catalog...11 in total so far that are domain based.

When checking it out in beta, we noticed each sub-catalog seemed to have its own unique shopping cart rather than one user shopping cart that could span across any sub-catalog under the parent account. Is it structured this way because in our situation each of our sub-catalogs have unique payment gateways? I would think it might get confusing for a learner to keep track of multiple shopping carts. 

I'd love to learn more about settings or customizations that we'd have access to, if any.

[jsowalsk]

I would love to hear more about this @taevans. Thank you for bringing it up.

[zsgoreczky]

Hi @taevans Thank you for reaching out and sharing your feedback. 

You are absolutely right about the separate shopping carts for catalogs / sub-catalogs in case there are multiple payment gateways configured. 

Unfortunately, Catalog cannot detect and distribute the cost of different listings across different gateways under one payment. So let's say Listing A needs to g through Payment Gateway X, and Listing B needs to go through Payment Gateway Y, we cannot support the checkout for Listing A and B at once. One payment has to belong to one gateway and one bank account as of today. 

We are aware of this not being optimal and might be confusing in some cases, and we are truly sorry about it. 

[jsowalsk]

@zsgoreczky just to confirm, if we have the same payment gateway along with the parent and subcatalogs then it will work right? Will the shopping cart recognize multiple child subcatalogs? For example, I purchase a course in the Business subcatalog but I also want to purchase a course in the Public Health subcatalog will this be recognized in the same shopping cart? I think this is optimal for usage in multiple institutions. 

[zsgoreczky]

Hi @jsowalsk Yes, in this case students will be able to checkout in one step regardless of the different listings they have in their cart. 

Even if there are multiple payment gateways configured we will use the same cart, however, when students reach checkout, they will be able to pay and enroll in listings that 'belong together' based on the payment gateway. So there will be one cart, but within the cart we will organize checkout based on which catalog / sub-catalog and consequently, payment gateway they belong to. 

[jsowalsk]

Great! @zsgoreczky what about programs will this be dealt in the same way? So, what you are saying is one person can purchase courses from different subcatalogs right and they will end up in the same shopping cart as long we use the same payment gateway for all subcatalogs?

[jsowalsk]

@zsgoreczky What happens if someone purchases a course through a link instead of the storefront and vice-versa? Will they end up be purchasing from the same shopping cart? 

[zsgoreczky]

@jsowalsk As I mentioned in my previous reply, all students in all cases will use the same shopping cart. The checkout itself might happen in multiple batches in case different payment gateways are configured. It's independent of the listings' types or how they are accessible. 

[jsowalsk]

Got it. Thank you @zsgoreczky.

[jsowalsk]

@zsgoreczky The one thing I just thought of, is there a way to integrate the add to cart button with the Sign in to enroll button. I think it is confusing since there are paid versus free courses and you would think Add to Cart would be for paid courses and not free. Would there be a solution for this?

[zsgoreczky]

Dear All, Yesterday (Nov 16) we turned on the changes of the second phase in Catalog Beta. This phase contains the checkout page and the 'All Done' page (previously Congratulations page). Please check them out and let me know if you have any questions. 

There is going to be one more Beta release with the last, third phase's changes before the Holidays. We would like to make sure that you have ample time to check all the changes in Beta so we are going to turn on shopping cart in Production at the very beginning of January. 

Please stay tuned for the last Beat release, I will update this post and thread once it is done. 

[jsowalsk]

Hi @zsgoreczky,

I just tested what you mentioned in this most recent blog post and I noticed that when I add a course that is fee-based to the shopping cart I do not get asked to pay for it and I get automatically enrolled after selecting the enroll button. But, if I go through the normal route of selecting $x enroll button I get sent to the payment gateway is there a reason for this?

Also, I shared with my CSM usability feedback and issues I ran into while testing out the shopping cart that would be great for your team to consider.

[zsgoreczky]

Hi @jsowalsk The majority of the issue you raised are going to be fixed with the last Beta release (Phase 3). The behavior you described above is also due to the last batch of missing capabilities. With Phase 3 the experience will be consistent. 

[jsowalsk]

@zsgoreczky Thank you. How long will Phase 3 be in beta for before moving to production? Also, if an institution is not interested in using the shopping cart will there be an option to turn it off?

[zsgoreczky]

Hi @jsowalsk Yes, if an institution doesn't wish to use shopping cart, we can turn it off for them. There won't be an option for it on the UI, it can be done by the engineering team. 

We are planning to leave the entire feature in Beta ~2 weeks not counting the Holidays. Obviously, we will also take into account the feedback we have received from the different institutions. 

[jsowalsk]

@zsgoreczky Awesome! Thank you. 

[escull]

Hi @zsgoreczky wanted to follow up on a suggestion by @william_trest above regarding the 'buy it now' option.

It's important for some use cases at IU that, even when shopping cart is enabled globally, the listing pages retain a button that allows the direct enrollment flow (as it exists in prod today), effectively bypassing the cart. You had mentioned above that you would modify the Enroll button functionality to align with William's suggestion...can you describe how that will change, and if it does, will we lose the current direct-enrollment process that bypasses the cart?

One thought I had was to keep the current button functionality, but clarify with text so users would be less likely to think that the Enroll Now button would add the course to their cart (kinda like Amazon's ability to buy now, even with things in your cart). For example:

Side note: Since there are buttons for different enrollment flows, maybe consider moving the cost out of the Enroll button, perhaps above the buttons? Could help with accessibility as well, since screen reader users may tab past the enroll button.

These are the kinds of things we could look at doing with customizations in our theme's JavaScript, as long as the listing page has a button that allows direct enrollment.

Thanks for all of your work on this...looking forward to seeing Phase 3 hit beta!

[zsgoreczky]

Hello @escull  and All, 

First of all, I would like to say thank you for sharing your thoughts and feedback. I really appreciate all the comments on this thread. It seems that the different institutions prefer different behaviors for the 'Enroll Now' flow.

I have talked to the team about this and we've decided to let root catalog admins decide which flow fits better to their institution's needs. So we will introduce a new root catalog admin setting with which you will be able to control whether you prefer 'Enroll Now' to use shopping cart and add the item to the cart or to skip the cart and, similarly to Amazon's 'Buy Now' option, checkout immediately. 

@escull With regards to the price on the Enroll button, we are going to remove the amount from the button in Q1 when working on storefront customization. 

Have a great weekend, Everyone! 

[jsowalsk]

@zsgoreczky Thank you! When can we expect to see this? Also, will it still be the case that if an institution wants to turn off the shopping cart they would need to go to engineering still right? This will not be a part of this workflow?

[zsgoreczky]

Hi @jsowalsk in ~2-3 weeks as part of the last phase. 

[jsowalsk]

@zsgoreczky Great, thank you.

[zsgoreczky]

Dear All, 

We have just released the last parts of the new shopping cart feature to Beta. 

@escull In order to support the old enrollment flow as well, we have built a root-catalog level account setting with which admins can control the behavior of the enroll button. 

I wish all of you a relaxing and peaceful holiday. 

[escull]

@zsgoreczky Perfect, thanks so much for taking our enrollment flow into account and working that option into the admin settings. We're down to the last couple of days before most of us scatter for a couple weeks for the holidays, but we'll kick the tires a bit and see how things look with phase 3 on beta.

One relatively minor thing: I noticed that with the "Starts enrollment only for the specific listing" option selected in the admin side, it causes the listing button to revert to the uppercase, larger button styling. Not a huge deal at all since we can adjust it in our theme, just FYI.

[jsowalsk]

@zsgoreczky Thank you! We will reach out with any questions during testing.

[jsowalsk]

@zsgoreczky From testing in beta I found the following things:

When I have one course in my shopping cart I can pay and enroll.

But, when I have one in the shopping cart and it is "in progress" for checking out I cannot add another course. Why is this? This happened from selecting the back button from the shopping cart. 

Also, I know like currently, that paid and free courses have separate processes to enroll/checkout -- will there ever be a time that you don't have to check them out separately? - is this because these courses are in two separate subcatalogs? Why isn't it giving the name of the listing? I noticed that I can add one to the cart and then I need to sign in to add another one to the cart and then this happens.

Also, when I am in the process of checking out and want to get another course added to my cart I cant do this since the checkout is in the process - this would be very confusing to the end user.

Also, the shopping cart is greyed out since you need to move forward with the current purchase/enollment because you cant revisit your cart. You can only get the chance to add another course is if you delete the course from the cart.

 Or sometimes I can checkout for both courses paid or free at once but this is not consistent :

 

 

[jsowalsk]

@zsgoreczky Also, I am trying to understand the difference between the two radio button settings - is it that one brings you to the shopping cart to check out and enroll and the other option is you go to the listing to enroll?

[zsgoreczky]

Hi @jsowalsk Happy New Year! We are working on fixing the behavior of long listing titles, so that will get improved in a few days. 
With regards to the multiple checkout options within the cart, that will be shown only in two cases, if different payment gateways are configured for the catalogs / sub-catalogs the selected listings in the cart belong to or if multiple currencies are set for the catalogs / sub-catalogs. The Beta environments work a little differently when it comes to payment gateway configurations and in Beta you also see the multiple checkout options in case the listings belong to different domains. However, in Prod you will see them only in case of the above mentioned two scenarios. So in case of UMD, in Prod you won't see the multiple checkout options. 

As for the checkout process already in progress and not being able to add more items to your cart, this behavior is intentional. For those institutions that have the multiple checkout options due to the different payment gateways or the currencies, it would be very confusing if we allowed students to add items to the their cart when the checkout is in progress. 

Regarding the two different enroll flows, we kept the old one which does not use the cart but immediately takes the user to the reg. / login page and then to the payment provider's interface to pay. The new flow (and that's the default one on the admin page) adds even single listings to the cart when someone clicks 'enroll' and the student goes through the same flow as if they purchased or enrolled in multiple listings (checkout page, payment gateway interface) 

I hope this is helpful. 

[jsowalsk]

@zsgoreczky Hi Zsofi, Happy new year!

What do you mean by?: We are working on fixing the behavior of long listing titles, so that will get improved in a few days. Do you mean when a subcatalog appears instead of the listing name? Which seems to happen occasionally for me even though the course is in a different subcatalog and NOT the root:

Here are the courses that I added to the cart:

https://umd-dit.beta.catalog.instructure.com/courses/new-osso-catalog-site

and

https://umd-chbe.beta.catalog.instructure.com/courses/biopharmaceutical-manufacturing-basics 

We have a set up at UMD that all subcatalogs point to the same Authorize.net portal but they are set up separately by url by our CSM and us creating the url but the CSM activates the gateway. What does this mean for the following? If you are saying, with regards to the multiple checkout options within the cart, that will be shown only in two cases, if different payment gateways are configured for the catalogs / sub-catalogs the selected listings in the cart belong to or if multiple currencies are set for the catalogs / sub-catalogs. The Beta environments work a little differently when it comes to payment gateway configurations and in Beta you also see the multiple checkout options in case the listings belong to different domains.

For this, However, in Prod you will see them only in case of the above mentioned two scenarios. So in case of UMD, in Prod you won't see the multiple checkout options. What will we see instead? What do you mean by multiple checkout options? Like I showed above or? This:

How do you recommend we tell users about the below? Since the expectation is they would want to add more to their cart before checking out?

As for the checkout process already in progress and not being able to add more items to your cart, this behavior is intentional. For those institutions that have the multiple checkout options due to the different payment gateways or the currencies, it would be very confusing if we allowed students to add items to the their cart when the checkout is in progress. 

Also, now when I select checkout for any course doesnt matter the subcatalog except for these http://umd-payment-testing.catalog.instructure.com/ and umd-dit.beta.catalog.instructure.com its getting pulled from that is for payment I get the following (the two subcatalogs I mentioned are set up for payment):

Do you know why this is happening? Is it because only certain subcatalogs are set up for payment?

Regarding the two different enroll flows, we kept the old one which does not use the cart but immediately takes the user to the reg. / login page and then to the payment provider's interface to pay. The new flow (and that's the default one on the admin page) adds even single listings to the cart when someone clicks 'enroll' and the student goes through the same flow as if they purchased or enrolled in multiple listings (checkout page, payment gateway interface)  -- Got it.

[jsowalsk]

Also @zsgoreczky if we ask for the shopping cart to be removed temporarily from our instance, should we select "immediately takes the user to the reg. / login page and then to the payment provider's interface to pay" option in our instance, or will changing this setting not change/impact anything?

[zsgoreczky]

Hi @jsowalsk 

We were aware of long listing titles not getting truncated properly. We are fixing it now and it will be improved with the next release. 

Yes, in production you will see only one checkout button in the cart preview since as you also mentioned it you have authorize.net configured for all your catalogs / sub-catalogs. 

You are receiving that error because there is no payment provider configured for that catalog. As you mentioned it, you have authorize.net configured only for those 2 catalogs where you don't receive this error. 

If you do not wish to get shopping cart turned on for your institution, your admins will not see the two 'enroll' button behavior controlling options. 

[jsowalsk]

@zsgoreczky We were aware of long listing titles not getting truncated properly. We are fixing it now and it will be improved with the next release. - Got it. When will the next release be? Do you have an example of where this is happening?

Where will the checkout button be displayed? Do you mean the free and paid will not be separated in the checkout window for checking out? Yes, in production you will see only one checkout button in the cart preview since as you also mentioned it you have authorize.net configured for all your catalogs / sub-catalogs. 

Thank you for confirming this: You are receiving that error because there is no payment provider configured for that catalog. As you mentioned it, you have authorize.net configured only for those 2 catalogs where you don't receive this error. 

If you do not wish to get shopping cart turned on for your institution, your admins will not see the two 'enroll' button behavior controlling options. -- We would not like the shopping cart turned on for our instance. Can this be accomplished to leave the shopping cart in beta and not put it on in production?

[escull]

Hi @zsgoreczky...Since it's possible to encounter the "Checkout is in progress in another tab" message in the same tab (if you begin a checkout then navigate away without cancelling it), could the text of that alert be generalized to something like: "Note: Checkout is already in progress."? 

[zsgoreczky]

Hi @jsowalsk 

The next Beta release is scheduled for tomorrow, that will have the fix for the truncating issue. The same fix will get released to production next Monday (January 10)

The checkout button is displayed in the cart preview, you can see it in the screenshot that you have attached above. 

Yes, we will keep shopping cart turned on in everyone's Beta environment, even if you do not wish to have it turned on in production.