Teammates: UI / UX Improvements

Created on 19 Jun 2020  ·  10Comments  ·  Source: TEAMMATES/teammates

Bite-sized, i.e. fixes or combination of fixes that can be done in less than 15 mins each

  1. ~Primary buttons are mostly used. Need to vary the color used. E.g. delete button
    should be red.~ Merge to #10243

    1. ~Task:~



      1. ~Scour through the website to find all the different buttons used~


      2. ~Decide the colour of each buttons~


      3. ~Implement them~



  2. ~Buttons should look more like buttons~ Merge to #10243

    1. ~V6 has a drop shadow effect that makes it look more 3D. V7 buttons kind of blends into the background~

    2. ~Task:~



      1. ~Get a suitable button style from bootstrap or self-defined ones~



  3. ~Information displayed inconsistently~ ✅ (@t-cheepeng )

    1. ~Task:~

      1. ~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

      2. ~Archived course table in the Courses tab is not collapsible but the Recycle Bin table is collapsible.~

  4. ~Misaligned labels and inputs fields in forms/details pages~ ✅ (@t-cheepeng )
    ~Task:~
    ~Adding new course on instructor page~
    ~Edit feedback session Course ID label and data in the top box~
  5. ~Landing Page~ ✅ (@t-cheepeng )

    1. ~Task~

      1. ~Bottom banner not centralised in mobile view~

        Medium-sized, i.e. fixes that are of considerably widespread reach, but consists of smaller sized fixes each

  6. ~Error pages should show feedback form to collect user submitted error~ Merge to #9356

    1. ~Missing feature from V6~
    2. ~Task:~

      1. ~List down all the different error pages~

      2. ~Decide which pages should show a feedback form~

      3. ~Notes: Make use of the component ErrorReportComponent~

  7. ~Opening / closing tabs feels very abrupt. V6 had animations for that~ ✅ (@ccyccyccy)

    1. ~Task:~



      1. ~List down all pages with tabs~


      2. ~Assign them a global class for tabs toggling~



    2. Animations do not play smoothly on initial component load, e.g. Expanding a panel.

  8. ~We use snackbar and progress bar from Angular material, however Bootstrap has support for those as well (toast and progress bar). Check if we can use Bootstrap instead and therefore eliminate the dependency to Angular material.~ ✅ (@wkurniawan07)

    1. ~https://ng-bootstrap.github.io/#/components/toast/overview~

    2. ~https://ng-bootstrap.github.io/#/components/progressbar/examples~

  9. ~Input Validation~ [Defer] Feature increases development effort and is not essential for V7. Can be added in after release of V7

    1. ~Validate input after the user finishes typing, not after clicking save.~



      1. ~If too hard to instantly validate, then consider scrolling up to invalid entry after clicking save? Or highlight error box in red~



    2. ~Task:~



      1. ~Investigate further if validation at the frontend really gives any improvements since backend already does so and returns error messages.~



  10. ~Instructor edit question page~ ✅

    1. ~Would like a way to collapse the questions. They take up too much space. Hard to get an overview of all the questions~ ✅ (@ccyccyccy)



      1. ~Default should be expanded~


      2. ~Could reuse the same “Expand All” button from the results page~


      3. ~Would be good to implement this feature~



    2. ~Optional description taking up a lot of space. Make it appear smaller at first and reuse the same resizable box for the main question box, making description textbox size dynamic~ ✅ (@ccyccyccy)

    3. ~Course ID not aligned~ (Fixed in UAT)

    4. ~Clicking on feedback path that expands to show possible paths should not dismiss the tab~ ✅ (@ccyccyccy)

    5. ~Cancel modal should not pop out if there is no changes made~ ✅ (@ccyccyccy)

    6. ~Have a divider between “Choose from template questions” and the rest of the options under “Add new question”~ ✅ (@ccyccyccy)

    7. ~While editing question, “Discard” and “delete” button side by side feels like they do a similar function. Rename “Discard” to “Cancel”~ ✅ (@ccyccyccy)

    8. ~MCQ MSQ: Click / hover on ‘X” button on options should have animations~ ✅ (@ccyccyccy)

    9. ~Distance between questions should be slightly larger.~ ✅ (@ccyccyccy)

    10. Clicking on a disabled field should highlight the edit button



      1. Big hassle to capture click events on disabled fields. Defer for now



    11. ~Save and save changes buttons have the same function. Make them look the same~ ✅ (@ccyccyccy)

    12. ~Add cancel button below the question beside the save button~ ✅ (@ccyccyccy)

  11. ~Ensure that all clickable areas are actually clickable~ ✅ (@ccyccyccy)

    1. ~E.g. Clicking on template questions to expand tab only works when clicked on the words rather than the box~

    2. ~Ensure cursor turns to pointer on clickable surfaces (where applicable)~



      1. ~E.g. Checkboxes don’t need pointers, but expanding tabs should need them~


      2. ~E.g. Student list cursor do not change to pointer on clickable surfaces~



  12. ~Ensure entries in tables and sortable tables are consistently displayed on load~ ✅ (@t-cheepeng)

    1. ~E.g. Instructor results page/all records page: comments shown are not sorted by date~

    2. ~E.g. Instructor courses page: Refreshing the page shows different layout every time~

    3. ~Convert sortable table to be used for all tables?~



      1. ~Use first column by default to sort (Customizable)~



a-UIX c.Epic

Most helpful comment

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.

All 10 comments

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:

  1. You are not authorized to view this page (Has error form in V6)
    image
  2. The page you are looking for is not there (Has error form in V6)
    image
  3. Ooops! Your google account is not known to TEAMMATES (Does not have error form in V6)
    image
  4. Invalid course join link (No counterpart exists in V6)
    image

@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:

  • Pop up the error report component; this is implemented only in course join page, you can reproduce by going to a course join link but drop the entitytype parameter
  • Pop up a toast message
  • Display "Data failed to load. Try again?" or alike in the table/div/... itself
  • ...

This 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?

  • User contact details known (e.g., user followed a legit session link in an earlier step)
  • User contact details unknown (e.g., clicked on an a link of a deleted course)

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:

  • Load the courses belonging to the instructor
  • Load the sessions of each course
  • Load the instructor privileges for each course (to know what kind of actions the instructor can do for each course)

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.

Was this page helpful?
0 / 5 - 0 ratings