jmoenig
Simplify Project Sharing UX
A number of my students have had difficulty sharing links to their Snap! projects with me. I think a simplified option for sharing projects should be added.
Current Behavior
From: https://bjc.edc.org/bjc-r/cur/snap-crash-course.html
- Make sure your current project is saved, and then open the project you want to share.
- Then choose "Open..." from the File menu again, and select the project you want to share from the project list.
- Click "Share," and then click "Yes" to share. Then click "Cancel" to close the menu.
- The URL (the link) at the top of the browser window will have changed. Copy this new URL, and send it to someone else to share the project. Click for images that show where the URL is and how it changes.
Proposed Behavior
Allow users to share a link to the project they currently have open with just two clicks.
- Select "Save and Share" from the File menu
- The project will be saved, shared, then a modal will appear, saying that the URL to the shared project has been copied to the user's clipboard
Of course, the current behavior could be retained as option for rapidly sharing several projects.
Maybe some tweaks to this proposed workflow would be needed, but I think something similar to this should be possible, and would be a major usability improvement. Speaking as a usability researcher, the current behavior has significant room for improvement.
we now have a much easier and faster way to quickly share, publish and unshare projects! Students can simply go to their page on snap.berkeley.edu and click on the share button:
They don't have to do it inside the Snap IDE all the time. Also, on their page they can get a quick and single-glance overview over which projects they've shared and which are private. Do you think this helps?
Ah, that option is good to know about! I think that option is helpful in some situations, but a "Save and Share" option directly in the File menu would be more discoverable, and would better fit the typical workflow used by my students.
When using the BJC course, my students have the workflow of:
- Open blank or starter project in Snap! IDE
- Make edits
- Save and share
Since students are already in the Snap! IDE, being able to save and share in 1 to 2 clicks from within the IDE would be great for usability. Given this workflow, having to navigate to a page outside the IDE would add a substantial number of clicks.
EDIT: Having multiple options for sharing, and putting those options where users will see them when they are completing typical workflows, seems good for usability (i.e., increasing discoverability).
I agree, Jens; students make the decision that their project is ready to share with their teacher in the editor, having just fixed the last bug, and it's cheating to call the website solution fewer clicks without counting the (huge) number of clicks needed to get to the web site and find the project's page.
It would help a little bit if there were a one-click way to open the website project page from the editor. Well, two-click, File and then Website Page. But I think your entire program of wanting to push file operations out of the editor is way off base with users' actual workflows. The community site is great as a way for someone who isn't the project author to find it by browsing. But it's just useless to the project author, who is always in the editor when forming the intention to share, publish, delete, etc. the project.
Let's not just blindly follow Scratch in this mistake.
Sigh...this has been an issue for 7 years. I think we should add it.
It would help a little bit if there were a one-click way to open the website project page from the editor. Well, two-click, File and then Website Page. But I think your entire program of wanting to push file operations out of the editor is way off base with users' actual workflows. The community site is great as a way for someone who isn't the project author to find it by browsing. But it's just useless to the project author, who is always in the editor when forming the intention to share, publish, delete, etc. the project.
But, Brian, using the words useless is just not fair. You assume this because some of us just by default go to /run, but really we can (and should) make the community site more and more usable. Currently sharing a project from the editor sucks way more than an "open in Community" button would if it were always available. (It is there in the cloud menu, but only for shared projects.)
It's perfectly natural to want to manage your projects without opening them. No one opens Word to delete documents.
it's cheating to call the website solution fewer clicks without counting the (huge) number of clicks needed to get to the web site and find the project's page.
This is also just not true. (Well, actually it's partially true because there's a bug.... go to the home page and refresh. Then you'll see it should be 1 click to get to your current projects.)
You assume this because some of us just by default go to /run, but really we can (and should) make the community site more and more usable.
No, I'm not assuming that. I don't know how many clicks or keystrokes it took the user to get into the editor, although if the user is a BJC student they probably have a bookmark for it. My point is that, however hard it was for them to get into the editor, that's where they are when they form the intention to share a project. They don't just form that intention out of the blue while reading Facebook.
I'm not against making the community site better. I just don't think that solves the problems of users who are in the editor right now.
(It is there in the cloud menu, but only for shared projects.)
Wow! Has this always been there? Nobody tells me anything.
No one opens Word to delete documents.
No, that's true. But it's not a good analogy; you don't want to delete a project when you're in the process of editing it. But imagine if there were a Word community site on which you can share your docs; you'd be much more likely to decide to share a doc while editing it vs. out of the blue in the Finder.
go to the home page and refresh. Then you'll see it should be 1 click to get to your current projects.
Let's count: (1) Type ⌘T to get a new tab, because you're in the editor and want to stay in the editor after sharing. (2) Type snap.berkeley.edu; okay, if you're me, you just have to type s then Enter. (3) Click on your head, then click "My Projects." (4) Scroll through your projects to find the one you're looking for; let's just call this one click although it often takes me more than that. (5) Click on the thumbnail. I count seven clicks or keystrokes. (Two each in steps 2 and 3.) Even the one step you aren't handwaving away takes two clicks.
okay, if you're me, you just have to type
sthen Enter
I have the same thing, except it goes straight to <...>/snap/snap.html
Just checking in again, since this semester I have more students who are having difficulty sharing projects.
Interestingly, some students are sending me project links, but the links don't work. The links have this format (USERNAME redacted): https://snap.berkeley.edu/snap/snap.html#present:Username=USERNAME&ProjectName=U1%2dRow%2dof%2dHouses&editMode&noRun
And when I try to use the link I get the error:
Could not fetch project U1-Row-of-Houses This project does not exist or is private.
I wonder what path they are following to generate these broken links...
Regardless, simplifying the sharing UI along the lines I proposed would be a big help towards reducing student frustration, and helping students submit their assignments on-time successfully.
Does your team have the bandwidth to implement this change? Alternatively, if I open a pull-request implementing the behavior I proposed, would you merge it?
I wonder what path they are following to generate these broken links...
there are likely coming from the community page. Or perhaps they have unintentionally unshared a project.
I've lost some debates on this, but it hasn't been the case in over 5 years that a direct URL to a project means that it is published.
Does your team have the bandwidth to implement this change? Alternatively, if I open a pull-request implementing the behavior I proposed, would you merge it?
Not a ton of bandwidth, but I would strongly advocate for its acceptance on review the PR. There's at least 1 and up to 3 old PRs that implement such a change.
--
The larger design question actually stems from the fact that the Snap! IDE doesn't easily know about the visibility of a project. IMO, we need to more clearly indicate inside the IDE the status of a project's visibility.
Personally, I think it's daft that we've come to accept the URL as an actual indication. (Many) browsers now hide query strings and hashes by default so it's not even a super reliable technique.
We have some iconography for the community site which indicates status, which I think we should pull into the IDE along with some tooltips. (e.g. look at the https://snap.berkeley.edu/my_projects page for the different icons.) The problem is that we use two icons for what is (in practice) a 3 state system (private / shared via link, published) What I think we want is a 3 very clear distinct icons we can use in all the places.
But I very much want to move away from the idea that a URL indicates something about the state of the project.