Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move Scratchpad button from top bar #32

Open
mapq opened this issue Sep 5, 2013 · 3 comments
Open

Move Scratchpad button from top bar #32

mapq opened this issue Sep 5, 2013 · 3 comments
Assignees

Comments

@mapq
Copy link
Member

mapq commented Sep 5, 2013

The scratchpad button, as pointed out by Dr. Edwards at our last meeting, is in an odd location. Here is what I think should be done... (but this is open to discussion)

  • this button is sort of like the homework and the practice problems, in that it gives you access to writing Python code... it also works like one of those in that is saves versions and keeps them around.
  • so lets move the scratchpad to the same page where you select homework's and practice problems. Maybe the scratchpad is a button with some short description at the top of that page (the page that shows the homework) in a row that goes the full wide of the page. Then below is are the homework, etc. as it is now.
@allevato
Copy link
Member

allevato commented Sep 5, 2013

Well, part of the reason that the Scratchpad is where it is is because it's
user-global, not associated with a particular assignment or course. I'd be
worried that moving it where other assignments are would send the wrong
message that it's associated with those entities.

Maybe put it under "Resources" as mentioned in the other issue instead?

Tony Allevato
Sent from my phone—pardon the typos

@mapq
Copy link
Member Author

mapq commented Sep 5, 2013

You are thinking as a developer... "global" vs not "global" is nonsense to the user. The user is in a class and in that class there are "free code" (or scratchpad), homeworks and practice problems. They are all part of "my class"... if the user is in 2 classes at the same time, then there is a "scratchpad" area in each (even if it is stored singly globally)...

The global distinction is one based on internal resource implementation that the user should not be exposed to...

Good to hear from you! Hope Google is treating you well.

@s-edwards
Copy link
Member

Given the target audience for pythy, it sure seems like the mainstream case is a user is involved in one course only. Even if a student happens to drop that course and retake it later, my guess is that even during the second course, they are still primarily thinking about "the current course" when they're interacting with pythy.

I do expect that most users will see their course home page (that is, the home page for the current course) on pythy as pythy's main locus of activity, and the scratchpad link will be on that page. Then all we're discussing is where on the page that link will go. From this point of view, I can see that there is no distinction in the student's mind between features of pythy "associated with this course" vs. features that are "independent of this course", because the vast majority of student users only consider pythy in association with their current course.

If this dichotomy is not part of the way these beginning students think about pythy and their relationship to it, then it shouldn't play an important role in navigation placement, either, IMHO. Basically, I'm saying beginners are going to associate everything on Pythy with their one course, and we can't really fight that. So fearing that students will "accidentally" associate the "global" scratchpad too closely with their current course is not a very useful rationale--where the link is placed (i.e., near to or far from assignments in the course) won't matter. Instead, I think we should strive for intuitive navigation and just embrace that students are going to see pythy in this more myopic way (i.e., as a one-course site, for the current semester). We still need to provide nav support for accessing multiple courses in order to make instructor/TA lives easier, and to more soundly handle situations where students eventually do take multiple python courses uses pythy over multiple terms, of course.

@ghost ghost assigned ArturAguiar Sep 11, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants