Bite-sized, i.e. fixes or combination of fixes that can be done in less than 15 mins each
~Information displayed inconsistently~ ✅ (@t-cheepeng )
~Task:~
~Button under Courses tab of instructor pages is grouped into Other Actions. But the other tabs with similar tables has actions that are not grouped~ Will not be grouping the action buttons together as there is no strong reason to do so. Also avoids an unnecessary additional click to get to the items
~Archived course table in the Courses tab is not collapsible but the Recycle Bin table is collapsible.~
~Landing Page~ ✅ (@t-cheepeng )
~Error pages should show feedback form to collect user submitted error~ Merge to #9356
ErrorReportComponent~Regarding input validation at point 9, we have an issue open tracking the implementation and development of this in #9419. There's only those few forms left honestly (unless I missed something), and I still stand by my opinion in https://github.com/TEAMMATES/teammates/pull/10049#issuecomment-627767630 that it would benefit the user experience in filling out the forms. Furthermore, I realise now that it might save us unnecessary backend API calls (that are going to be rejected anyway) thus reducing the overall server computational cost.
@damithc okay for us to proceed on this?
Regarding input validation at point 9, we have an issue open tracking the implementation and development of this in #9419. There's only those few forms left honestly (unless I missed something), and I still stand by my opinion in #10049 (comment) that it would benefit the user experience in filling out the forms. Furthermore, I realise now that it might save us unnecessary backend API calls (that are going to be rejected anyway) thus reducing the overall server computational cost.
@damithc okay for us to proceed on this?
Indeed there are benefits of front-end validation. Right now our primary concern is optimizing development effort. I suggest we postpone it because it increases the development effort and not essential for V7. Those are incremental improvements we can do after V7 has been released.
For item number 6. the different error pages that are shown in the app are:




@damithc @wkurniawan07 @xpdavid Do we follow V6 and only have the error form in 1. and 2. or have the error form for all 4 items? Also, do we want to embed the form onto the page itself or have it popup as a modal?
The general rule:
If using the form, the log message saved (which is then emailed to me) should contain enough information for me to take an action. For example, I should be able to email the person back. If it is not possible to know the contact details of the person trying to access, either we have to collect that info using the form or else ask the user to email us instead of using the form.
I think we can have the form in 3 too.
For 4, users often reuse the previous link to reach the same course. It should only show an error if the link is being used by a different Google account than the one it was used before. In those cases, we can use the form.
Looks like I need to give more context about how the new error page (if it can still be called a "page") works.
In V6, the architecture is 100% server-side rendering (SSR) with occasional AJAX request in many parts. That means, any request for new page will be served entirely by the back-end. If any error is encountered during such processing, the server will redirect to pre-defined error pages, such as pageNotFound.jsp, unauthorized.jsp, etc. You can find the details in the release branch which still contains the V6 code (at the time of writing), specifically here: https://github.com/TEAMMATES/teammates/tree/release/src/main/webapp.
In V7, the architecture is single-page application (SPA) with AJAX requests to REST endpoints for data. Under this architecture, there is only one initial request for page which is index.html, and everything else is just directing the user to the correct page template, as defined by the web URL. For this reason, error page being defined as a "page" does not make sense anymore, except for one single case which is "page not found".
Since V7 (or, in general, SPA+REST application) works by getting data and then transforming data into user-friendly view, any error "page" doesn't really fit what an error page really means in SSR architecture. In fact, the ones you listed above are not errors, those are expected output from business logic (e.g. if a course join link is no longer usable, then we display as such). It is true that we can be more user-friendly and perhaps add some reporting form, but as far as the actual definition of error (server returning 4XX or 5XX) is concerned, none of the examples above are errors.
Actual error handling in V7 can/should be done in few different ways:
entitytype parameterThis is a very delicate matter and varies largely case by case, much more so than in V6.
This is a very delicate matter and varies largely case by case, much more so than in V6.
Understood. Can all these cases be divided into two categories like this?
If the answer is yes, the first category can be shown the feedback form (for serious errors) and the second category can be asked to email us directly or show a feedback form but with an additional field for contact email.
Can all these cases be divided into two categories like this?
No. It's not that simple. Take, for example, the instructor home page (user contact details known). These are the AJAX requests happening after the initial page load:
The first one, as it happens only once and only during the initial page load, can be handled by popping up either error report component or toast message.
The second one, however, happens afterwards and happens concurrently, so if there are 10 courses for this instructor, there will be 10 parallel requests (or maybe 3 as only the first 3 courses are loaded by default; need to check again). Here it doesn't make sense to pop up any message because there can possibly be multiple parallel errors happening, so displaying "Data failed to load. Try again?" is the better option.
The third one is even more complicated, as any error coming from it will only be visible when the user finds out that s/he cannot perform any action s/he should be able to.
No. It's not that simple.
Understood. For each case, also factor in if the contact details are known or not and tweak the response accordingly. If not known, and if appropriate (case by case basis), either collect that info from the user or ask the user to email us directly. I just want to avoid the case where the user thinks she reported the error and waits for a fix but I have no way to reach the user.
Can I take on 10 (Instructor edit question page) part (i)?
@manzurayusup Thank you for the interest. However, that sub-issue is already being worked on by other people.
Most helpful comment
Indeed there are benefits of front-end validation. Right now our primary concern is optimizing development effort. I suggest we postpone it because it increases the development effort and not essential for V7. Those are incremental improvements we can do after V7 has been released.