-
Notifications
You must be signed in to change notification settings - Fork 45
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
improve publish button #414
Comments
@asolove ^ |
I have a proposed design for this that I can find when I get back home. The real issue is not UI though but concept. There are several completely separate things that can happen in the publish dialog that are currently conflated. IIUC, the way it works is:
A couple issues then:
What could we do with this? If I had an unlimited time budget, I would probably:
I also am still partial to the idea that “Share” would be a natural way to add in explicit assignment tracking, on which case “share with a single class section” might be equivalent to a published version, and have an option to expand the student files created from the shared assignment file. But yeah. |
@asolove 's proposed design is good. One clarification about how this works – there is only one ID for (and indeed only one copy of) the published file. The import and the The file is always mutable by re-publishing. Since it's owned by the owner of the original file, this doesn't give others a way to change it or anything, but others could always see the code change when re-visiting the share link or re-running a program with an import of that file. |
Oh, interesting! What is the deal with the two arguments to the import? I thought I had saw some code where that was versions. |
Let me think on that, it simplifies the design problem a lot! |
The second argument to import is just a friendly human name for the file to ease reading import lines (the publish UI just copies the name over). |
Oh and the |
@shriram @jpolitz Curious for feedback before I go further with this. The idea here is to have three separate states:
The share widget has a dropdown similar to the Run/Run with Types dropdown, which defaults to "Link" but can be switched to "Import". And the dropdown picker will have descriptions of when you want to use each, but this way Link is very prominent and only people explicitly looking for something else have to think about the import syntax. This is all powered by a fun discovery that the Google API response we already fetch has lots of useful timestamps and an md5 of the file content. I hope that separating out these states means we no longer need long text explaining the save v publish issue, and people will be less confused. |
Visually, I think it's pretty solid. Focusing on the few things I don't like:
|
Nice! Thanks for spelunking through those responses. That's super helpful. My feedback is basically the same as @blerner 's. I don't mind the undiscoverable dropdown next to Link since import syntax is so seldom used. The simple colored circles seem lousy for accessibility, not sure I have a concrete alternative in mind. |
Thanks for feedback, all!
Sounds like folks are ok with this direction, though, so I'll get the main flows working and then report back with a closer-to-real UI. |
We often get teachers (and likely students) who don't see/notice the difference between #share and #program links. I think I'd prefer to see at least |
Oh interesting! I don't even know the difference between #share and
#program: what are they? Happy to make sure we share more if that
distinction is important to experts.
…On Mon, May 2, 2022 at 1:14 PM Ben Lerner ***@***.***> wrote:
We often get teachers (and likely students) who don't see/notice the
difference between #share and #program links. I think I'd prefer to see at
least ...#share=XXXX... in the link text, so that (a) students and
teachers habituate to looking for that #share part, and (b) so that experts
can quickly skim the beginning of the uuid and correlate that with where
it's used in other files. (This had been useful, eg, in fixing up a bunch
of BS:P teachpacks, when we weren't quite sure we had the right original
files.) It doesn't need to be much, but I'm uneasy with it being *this*
shortened.
—
Reply to this email directly, view it on GitHub
<#414 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACCL4C6RDC7LEOIEPCHWTVIAEQFANCNFSM5LC4TBVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
When you're working on your own programs, you're working on a |
And what happens then? I assume they get a 404 because of lack of access?
Could we make that page a little clearer and add a "if someone sent you
this, they might need to share it with you!"?
…On Mon, May 2, 2022 at 2:06 PM Ben Lerner ***@***.***> wrote:
When you're working on your *own* programs, you're working on a
#program=XXXX link. When you share it, you get a #share=YYYY link (with a
different id than the program itself, since it's a copy of the original
file). Too often teachers (and likely students, but I haven't interacted
directly with them in classrooms) just copy the URL of the browser window
they're in, and send that URL to the workshop leaders -- and that'll be a
#program=XXXX link.
—
Reply to this email directly, view it on GitHub
<#414 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACCL67CGPKJILXW6Q4Z6DVIAKTTANCNFSM5LC4TBVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The person who sends out the wrong URL won't notice anything -- how could they? they aren't doing anything directly with CPO at that point! The recipient of the link merely sees a red "The program failed to load" message in the status bar at the bottom-right. We have no way of detecting whether the program id was bogus, mistyped, or forgotten-to-be-shared, since the GDrive API just returns a 404 to us. |
Sure but our UI after the 404 could guess and explain that either the link
was bad, you are signed in with the wrong account, or if someone gave you
this link they should use share instead.
…On Mon, May 2, 2022 at 2:28 PM Ben Lerner ***@***.***> wrote:
The person who sends out the wrong URL won't notice anything -- how could
they? they aren't doing anything directly with CPO at that point! The
recipient of the link merely sees a red "The program failed to load"
message in the status bar at the bottom-right. We have no way of detecting
whether the program id was bogus, mistyped, or forgotten-to-be-shared,
since the GDrive API just returns a 404 to us.
—
Reply to this email directly, view it on GitHub
<#414 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACCLYXC3Y2G76J4ZTX32LVIANFDANCNFSM5LC4TBVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Right now the publish interface looks like this:
I wonder if a better interface isn't to have three buttons:
I think it's also important to put the conventional "copy" icon right next to the URL. For people who know about Ctrl-C/Cmd-C, the current interface (w/ text selected) works fine. But for people who don't do that, they're going to drag the mouse, maybe select only part of the text, etc. I think there's a reason why apps have all moved to having a "copy to clipboard" button.
Curious what Adam Solove would say. This already looks improved by him, and I think it's visually better than before, but could probably be improved further.
The text was updated successfully, but these errors were encountered: