Challenge Overview
Topcoder is working hard on a massive update of our belowed community platform. Recently we implemented the new version of Challenge Details page. It is almost production-ready, but its piece related to challenge terms needs some updates, both in design and in logic. Development will be done in Community App repository. Use the latest commit in develop branch (b2265c0217083f0d46800f50b67036c4db623968 at the moment of writing), follow our Coding Standards.
Challenge terms are something you probably don't see much on day-to-day basis. However, when you try to register for a challenge, protected by terms you have not registered earlier, Topcoder gets you to the terms agreement flow. When you register for a challenge protected only by terms you have already accepted before, you don't need to agree again, so you don't see that flow (but you still can see applicable terms in the sidebar on challenge details page). There are two types of challenge terms: simple one is managed entirely by Topcoder backend (there are endpoints to get terms text as plain text, and to agree); and a more advanced ones, using DocuSign. It is not easy to test related functionality with development or production Topcoder backends, thus we got a mock implementation of terms service in Community App. To use it, run the app with MOCK_CHALLENGE_TERMS_SERVICE environment variable set true. In this mode any challenge will be protected by one simple, and one DocuSign NDA (in this case just a page with two buttons that trigger the same callbacks as the real DocuSign would) terms. It does not store agreement status, thus each time you reload the page and try to re-register, you'll be asked to agree for terms again. However, once the terms flow is implemented correctly, entire process should happen without reloading the app, thus this behavior of mock service is not a problem. For testing purposes you may edit the actual data returned by the mock service (https://github.com/topcoder-platform/community-app/tree/develop/src/shared/services/__mocks__/data). Note that real Topcoder API returns auth error, when getTerms(..) is called with auth tokens for completed challenges (it is not imitated by mock service at the moment). Here we have the test challenge in prod you may use for the final testing.
1. Design. We have new designs for challenge terms modal here. Desktop / Tablet / Mobile layouts are all in scope. Note the following:
Challenge terms are something you probably don't see much on day-to-day basis. However, when you try to register for a challenge, protected by terms you have not registered earlier, Topcoder gets you to the terms agreement flow. When you register for a challenge protected only by terms you have already accepted before, you don't need to agree again, so you don't see that flow (but you still can see applicable terms in the sidebar on challenge details page). There are two types of challenge terms: simple one is managed entirely by Topcoder backend (there are endpoints to get terms text as plain text, and to agree); and a more advanced ones, using DocuSign. It is not easy to test related functionality with development or production Topcoder backends, thus we got a mock implementation of terms service in Community App. To use it, run the app with MOCK_CHALLENGE_TERMS_SERVICE environment variable set true. In this mode any challenge will be protected by one simple, and one DocuSign NDA (in this case just a page with two buttons that trigger the same callbacks as the real DocuSign would) terms. It does not store agreement status, thus each time you reload the page and try to re-register, you'll be asked to agree for terms again. However, once the terms flow is implemented correctly, entire process should happen without reloading the app, thus this behavior of mock service is not a problem. For testing purposes you may edit the actual data returned by the mock service (https://github.com/topcoder-platform/community-app/tree/develop/src/shared/services/__mocks__/data). Note that real Topcoder API returns auth error, when getTerms(..) is called with auth tokens for completed challenges (it is not imitated by mock service at the moment). Here we have the test challenge in prod you may use for the final testing.
1. Design. We have new designs for challenge terms modal here. Desktop / Tablet / Mobile layouts are all in scope. Note the following:
- No need to require the user to scroll down to the bottom of terms text to be able to agree (i.e. I agree button is always visible on the screen, and enabled).
- When there is just a single terms - no need to show the progress bar.
- When some terms of the challenge have been agreed for already, they should be shown in the progress bar as agreed, but should not appear in the agreement flow.
- In some cases there might be more than 2 terms to agree. In this case, on mobile layout, the progress bar be horizontally scollable and show just two terms within the view at a time. See how such scrolling is done for mobile layout of tabs selector on Challenge Details page (https://github.com/topcoder-platform/community-app/tree/develop/src/shared/components/challenge-detail/Header/TabSelector), pay attention to the semi-transparent elements on the edges of scrollable area, when it is not scrolled till the end. We want to copy that solution here as well.
- We should show loading indicator while waiting for DocuSign response (mock terms service explicitely uses 3 sec timeout before responding, it is done on purpose, as the real DocuSign API also has some delay before it renders DocuSign loading indicator - while we are waiting we should show our own loading indicator).
- DocuSign terms are shown in iFrame, and now the code use /iframe-break endpoint and some goofy logic, involving reloading of the app, to handle results of DocuSign agreement. This should be reworked, using proper messaging between iframe and its parent (probably, there is some good npm library we can adopt for that, or we should create a dedicated utils module handling related functionality), and the current iframe-break-related logic should be wiped out from the codebase.