nfischer / course-dashboard Goto Github PK

It's also useful to be able to upvote/downvote on course resources. I think this feedback system is a significant aspect of our project. We may want to look into how this is implemented, since it sounds like it could be slightly tricky:

• Each user should be able to vote up or down, and change their vote at any time, but only be able to cast one vote (i.e. you can't upvote something and then upvote it again tomorrow, but you can upvote it and change your mind and downvote it)
• This implies that the database needs to keep track of which users cast which votes, in addition to the total score of the resource

Once we have voting implemented, we should also sort resources, taking into account both timestamp and rating.

Also, do we want to consider automatic removal of posts that receive a low enough score? Could be an issue for homework assignments (don't want everyone to downvote HW 1 to get rid of it), but this could be valuable with student-uploaded content (throw out resources that people found misleading).

fira sans is a reasonable choice to try for font

Creating a resource without a title makes it not appear (can't click on it since it isn't in the UI). This probably isn't what we want. Either a javascript alert which reminds the user to make a title, or perhaps the "title" is a snippet of the body of the resource (i.e. "Hey guys, check out this really cool website I found the other day." could have the "title" "Hey guys, check out..." and the body will still be the full text).

see title. I should be able to edit the previous markdown instead of retyping

We should add time stamps to our nodes so that we know how old they are. This is useful when we're sorting our nodes, since we want new nodes to tend to be higher up and old nodes to be lower down.

This isn't a huge issue if we are dealing with 1 year's worth of course info, but this is relevant if we're allowing resources to carry over multiple years (last year's professor announcements are significantly less important than this year's announcements).

We may also want to add expiration dates for some things (like homework assignments will "expire" after their due date, or after the term ends, so that next year's class won't be confused and accidentally read the wrong "HW 1").

see title

When we add a week to the course creation UI, we're asked to add both the start and end date. Since this labels everything as a "week", I think that once we enter the start date, the end date should be automatically set to 6 days later.

In the interest of flexibility, we should allow this to be editable (in case someone has a module in a course that's longer than 1 week). But I think this is a nice default.

Also, in the interest of flexibility, we should probably also allow the "Week" label to be changed to something like "Module" or "Unit" (to allow for logical units that are longer than 1 week). As before, I think "week" is a nice default though.

We should update our README and take out deprecated sections. In particular, is this migration section deprecated? If so, we should cut that out sooner rather than later. I can handle it easily, just wasn't sure if it was still applicable (since I didn't write it).

I think we should set up unit testing for the flask stuff. The sooner the better, since we're required to have it done anyway.

Reasons to do it sooner:

• Continuous Integration: This will run all our unit tests on every push and pull request, so that makes sure that we never merge broken code (which is tough to resolve later on).
• Peer review: This goes along with the CI stuff. Once we have continuous integration, this will significantly cut down on the peer review time for pull requests, which will help speed up our process later on, which is when development pace will be critical.
• We have to have tests eventually, and it's better to find out sooner rather than later if our testing framework won't work for us.

The week view has a vertical line going down the middle of the page (it's like a timeline). Clicking something on the page (such as a topic) will cause the line to move slightly to the right (and it moves back when we go back to the week view).

Steps to reproduce:

1. Start the web page
2. Click "week 1"
3. Observe the position of the line (it lies between the two e's in "week 1")
4. Click "Design Notation"
5. Observe that the line has moved slightly to the right (it lies to the right of the right-most e in "week 1")

When we add a resource, as soon as we click "create," it should be visible in the list of resources. Right now, we have to close and reopen the list of resources under the topic in order to see the update.

Let pressing "ctrl-enter" mean the same thing as clicking "Create" when making a new resource. This is just a convenience thing, since I find myself wanting to press "ctrl-enter" to save the resources.

This would be useful for the frontend, as through this, we could parametrize the frontend by class.

Create a notification when a course was successfully created.

We should ideally be able to support Windows 7 and up. I believe the python script addSampleData.py is OS-agnostic (for some reason it's slow on Windows, but it should be good otherwise), so I think the only other issue is the directory structure. This should be fixed in #26, but we will need to test it out to make sure.

Also we need someone to upload quickstart instructions for Windows, so I'll tag someone to take care of that. We should be able to run the entire project, frontend and backend on both Linux (Ubuntu) and Windows.

The UI for how resources are displayed is good, but somewhat nonintuitive. My concerns are as follows:

• edit and delete buttons are hard to distinguish from the text of the resource. Maybe we could make these look more like buttons (perhaps surrounded by grey boxes) and less like regular text? Or maybe even just a different font. My only concern is that adding a resource like "Title: Something body: new" looks like:

Something
new
edit
delete

• Title is difficult to distinguish from the rest of the resource, for similar reasons as above. Maybe a slightly larger font would do the trick?
• Lots of scrolling. It's hard to see all the subjects under a given week. This doesn't give us a high-level view of the subject material. Maybe if we minimize the "create resource" UI to just a button that expands? Definitely open to other ideas, it's just concerning that the high level topics are hard to see.

When I click on a week->topic->resource, the resource is visible on the screen. If I want to go back to the topic (so I can choose a new resource), I often find myself wanting to press escape.

Current behavior: this closes the resource and the topic (takes me back to the view of that current week).

Desired behavior: close only the resource (take me back to the topic view). If I really do want to go back to the week, I will then press escape again, so we aren't losing functionality, we're just making it easier to "go back to the topic".

see proposal at https://tonicdev.com/sakekasi/piazza-experments

As it currently stands, if the course creation page has an "add resource" box open on the page, this is required to be filled out. To me, this is non-intuitive. The better behavior would be:

• If a resource is left blank, I obviously don't want to add a resource. Instead of forcing me to click a "minus" button, just infer that I want to add no new resources.
• If I fill out half a resource (ex. title, but not body), infer that I actually did want to make a resource, but made a mistake. Remind me to fill out the body. If I realized I didn't want a resource, I'll go back and delete it.

This stands the same for topics and assignments. Even if we have the "there must be one or more topic" rule, this still applies to the 2nd, 3rd, 4th, etc. topic boxes, so it's still something we should implement.

I would probably do this by associating the user id and resource markdown with the content and modifying the resource renderer to only render the markdown.

We ran into the issue where, if someone wants to remove a topic, they may have an issue figuring out which minus sign to hit. Something that can help with this is to have tooltip for when you hover over the plus/minus signs that says something such as "add a resource", "delete an assignment", "add a week", etc. This will help, since if someone hovers over a button, they'll at least get a subtle cue that the button they're about to click might not be the best one for them.

To really solve this, we may need to figure out a way to make it more obvious which buttons go with which objects on the screen. Not sure how best to do this, so we should spitball some ideas. Regardless of this approach, however, I imagine the tooltip approach would align well, so it may be worth implementing for now.

Requests are considered cross-origin when going from localhost to 127.0.0.1 or vice-versa (parse current URL instead of hardcoding).

We will need to maintain the state of which users are enrolled in which courses. This is a many to many relationship, as each user might be enrolled in multiple courses and each course might have multiple students.

This will be necessary when we finally support authentication (prevents user X from accidentally posting in course Y if he's only enrolled in courses A, B, and C).

when editing nodes in the new editing UI, changes are not shown until week is manually closed and opened. Re-render should occur as soon as I press submit on the editing ui