Problem sets created by students don't show up in their dashboard

[benetechMatt]

When students are signed in, any problem sets they create are not showing up in their dashboard. Only sets they worked on and were created by someone else show up in the dashboard https://www.loom.com/share/9453ece0b8434992bcb050cae17ed7d4

[johnhbenetech]

@alexrcabral should there be any structural organization of 'created by you' vs 'solved by you' sets? or should they just be one big list sorted by date?

Also consider the case where a student creates a set, then also uses the share link to solve. That set would appear twice with same title.

[alexrcabral]

@johnhbenetech

should there be any structural organization of 'created by you' vs 'solved by you' sets?

Yes, eventually.

However, recent sets is not explicitly My Sets, it just shows the 15 most recent worked-on sets. Breaking out between my sets vs other sets (and being able to access more than 15 previous sets) is a separate issue.

should they just be one big list sorted by date?

List sorted chronologically by recent access (most to least recent).

Also consider the case where a student creates a set, then also uses the share link to solve.

The duplication is not part of a typical use case, since we explicitly updated the workflow so a student can work on a problem they've created, rather than doing the previous convoluted flow of creating it, then assigning it to themselves, and having to save both links.

If a student creates a set, then decides to duplicate it or assign it to themselves, yes it will create two sets, and those would appear separately in the "Recent Sets" because they are two separate "documents" with separate permission levels.

To clarify, what we're trying to solve for here is loss of work. If a student creates a problem and does everything right -- is logged in, solves it correctly, adds all the steps, and saves it -- they go back to their dashboard and their work is gone.

https://www.loom.com/share/6a1be041e72a4625ad9c3fdb4d256767

[johnhbenetech]

@alexrcabral

a couple of things coming out of a conversation with @rupeshparab

1. From a technical standpoint, it would be much cleaner/easier if we could break this down into separate sections. I can give you more details, but essentially solution sets vs. created sets are afforded in different API endpoints. So we would need to make both calls, then do the comparison of the timestamps to collate the correct order. This may cause increased wait time for the sets to populate in the front end.

2. From an interface point in view, there are a few key differences in the elements present in the two types of problem sets. If we choose to mix the two types in one section a user will experience different available elements on a row-by-row basis:

• created sets: has three-dot more options menu, only lists number of problems
• solution sets: does not have three-dot menu, has completion status (7/7 problems, green icon for completion)

I imagine this could be confusing esp for keyboard navigation as the number/types of focusable elements changes row to row.

Let us know if this changes your mind

[alexrcabral]

@johnhbenetech

1. A couple questions to your first point:
   • How much would the wait time increase? (e.g. is it an extra half a second, or is it three times as long to load?)
   • How would this be affected by reducing the number of recent sets shown (e.g. showing 5 rather than 15)?
   • If these were broken out by sections, would both API calls need to be made (similarly increasing the wait time)?
2. From the interface perspective, this is moving closer to the ideal. These sets should be surfaced similarly to fully enable students to be creating problem sets effectively.
   • Under the three dot dropdown on a teacher account, it has the options to “duplicate to edit/share” and “archive”, both of which are necessary on the student side as well. This is something that’s currently being addressed in current issues: #844, #1175, #1157, #1227.
   • With this soon being the case, there will be no focus difference between created and editable sets for tabbing between on a keyboard, since the problem as a whole, and the problem set dropdown will be focusable for both types of sets.
   • The primary difference is that /edit problem sets show the number of problems (eg “7 problems”), while /solve problem sets show the number completed (eg “3/7 Problems), optionally with a checkmark if all are completed. The logic on this can be updated in a separate issue

I still believe this is the way to go, though I would like to know more on how drastically the API calls + collating will effect the usability of the dashboard, and ways in which this could be mitigated.

[johnhbenetech]

1a. Not sure to be honest. But even a extra half second if more disruptive than it sounds. It's not an incremental load, so it would display nothing at all for that waiting period - which could be scary 1b. It's atomic not incremental so not a huge difference 1c. The main difference is two fold:

• We have already built the two separate required endpoints. So the separate approach would be hours of work as compared to possibly days of work with possible backend changes.
• In the current recommendation we have to call the endpoints and then also do the intersorting just in time so it requires waiting on both of those to complete

2. a. So to summarize, every problem set will have a three dot menu with the exact same options? Regardless of type of user or type of problem set? b. How should the three dot + 7/7 problem + checkmark work from a UI prospective. Since the check mark is not always present how should we order the display so it s consistent?

It's ultimately your decision, but I really dont understand why a user would prefer everything mixed together. Is this the ultimate vision for this page? How do users access problem sets older than the most recent 15? If the future vision has us going down a separation path eventually i would hate to do a bunch of unecessary work now that we just have to revert in the future

[johnhbenetech]

@alexrcabral is there a decision on this? I want to make sure this is addressed before we move on to other lower priority work

[alexrcabral]

@johnhbenetech Please do continue onto lower priority items. Since this has the potential to drastically affect usability, this will be shifted lower in priority to other dashboard changes. The primary need is for all sets to show up in the dashboard, secondarily the intersorting which would require the API call changes.

2a. The problem sets having a three dot menu is a separate issue which is being addressed elsewhere (e.g. in the students' ability to archive sets (#1227). 2b. Yes these should be displayed consistently, since they're addressing the same model (particularly with student-created sets). Number of problems, either total or out of total, space for a check mark if applicable, and the three dot menu.

Ultimately users expect to see all their work and be able to sort through it efficiently. We have a few options available to us in how we can surface this while also using the tools we have most effectively.