Notebook: Confused about what Edit/View does

[ellisonbg]

I am doing UI/UX testing for issue #2142. The Edit/View button are either not working or working in a way that is really confusing. Here is what I observe:

• For notebook, text files (non-html), clicking on the name of the file in the file browser opens the file in the corresponding editor (notebook, file editor).
• For those files the "Edit" button appears, but does the same thing. All notebook users have gotten used to just clicking on these files, so presenting different way of doing that same thing is confusing and makes it more difficult to find the other buttons they want to use. The button based UI is getting unwieldy with too many buttons that are context dependent. Not suggesting we move away from buttons now, but let's not show ones that are not needed.
• For HTML files, clicking on the file opens it in the text, editor, clicking the "Edit" button does the same thing. Again, the "Edit" button seems unnecessary. However, if you click "View" you get a new page with a nasty error:

Is this a bug?

• For image files, clicking on the file opens it in View mode. The "View" button also shows and does the same thing. In this case, the "View" button is redundant. Furthermore, the "Edit" button shows, but errors after trying to open the file in the text editor.

My recommendations:

• Remove the "Edit" and "View" buttons in situations where clicking the file already does the right thing.
• The only usage case that I see where that isn't the case is the "View" on HTML files. I think that makes sense to keep, but we should debug it.

@gnestor

[takluyver]

We added these because previously you couldn't do either of these things from the UI:

• View HTML files
• Edit files that are textual, but where the system is not reporting a text mimetype. This is system dependent, but we've had quite a few reports of this. Since this is to work around our guess of 'can we edit this file', we necessarily have to show the button for some files where it won't work, and it would be weird not to show it on known editable files.

The error viewing an HTML page is a bug; I'll look into that.

[takluyver]

2208 fixes the error viewing HTML files, at least for me. Thanks for spotting that before we released!

[Carreau]

I think we can close this one as it is html view is fixed by #2208. And I agree with @takluyver that we should not be too smart. Edit/View everywhere seem fine to me.

[ellisonbg]

Not thrilled with all the buttons, but ok 👌

I don't understand why we would introduced new buttons that don't do anything useful.

Sent from my iPhone

On Feb 22, 2017, at 10:47 AM, Matthias Bussonnier [e-mail] wrote:

I think we can close this one as it is html view is fixed by #2208. And I agree with @takluyver that we should not be too smart. Edit/View everywhere seem fine to me.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[takluyver]

They both do something useful under certain conditions; see my earlier comment.

[ellisonbg]

Got it! I missed the issue of editable files that report the an unexpected MIME type. But allowing users to click on files that we know they won't be able to edit is very confusing (images in particular). Given this new information, my preference would be:

• Only offer "View" for HTML files.
• Show "Edit" always, except for image MIME types.

[takluyver]

There is another minor use for 'view', which I forgot - it gives you a way to get the raw text of a file which would otherwise open in the text editor. Possibly niche, but could be useful if you have e.g. a very long file.

I'd broadly agree with hiding edit when only images are selected, but we need to be a bit careful, because image/svg+xml, for instance, is text. The media part of mimetypes turns out not to be that helpful for us.

[Carreau]

Only offer "View" for HTML files.

Why ? Html are perfectly valid text files. Can't you edit a template.html file that you use from Python in Jupyter.

Show "Edit" always, except for image MIME types.

Why ? Isn't SVG a valid image format you might want to edit with a text editor?

[Carreau]

Well, just 🐴 with @takluyver and I think we agreed, we don't want to be in the businesss of deciding what can and/or cannot be viewed/editted.

[ellisonbg]

@Carreau sorry I think there were two possible meanings in my sentence "Only offer "View" for HTML files":

1. For HTML files only offer the View option (not the Edit one)
2. Only show the View button for HTML files and no other files.

I was meaning (2), so that yes, you would see the "Edit" button for HTML files. But you wouldn't see the "View" button for other things.

And by image types, I was only referring to jpg/png, not svg, which is definitely text and can be edited just fine. Right now if you "edit" a jpg or png, it opens the text editor, but it fails with an encoding error. If a user says "Edit this jpg file" that is a disappointing and confusing outcome...

@takluyver I agree that getting the raw text of a text file using "View" would be useful, but that doesn't work right now. The View button only shows (as far as I can tell) for HTML files. So actually, the current behavior actually matches my preference (View only shows for HTML files).

So I think the only change I would like is to not show the "Edit" button for the image/png and image/jpeg file types.

[Carreau]

For HTML files only offer the View option (not the Edit one)
Only show the View button for HTML files and no other files.
I was meaning (2), so that yes, you would see the "Edit" button for HTML files. But you wouldn't see the "View" button for other things.

Ah ! Sorry for the confusion.

but you wouldn't see the "View" button for other things.

Wait do you mean "Edit" ? Like you don't want the "View" button for images ?

And by image types, I was only referring to jpg/png, not svg, which is definitely text and can be edited just fine. Right now if you "edit" a jpg or png, it opens the text editor, but it fails with an encoding error. If a user says "Edit this jpg file" that is a disappointing and confusing outcome...

I got what you were thinking. The problem is that OS are known to not give the right mimetype. We had many issues with windows reporting css as application/css instead of test/css. Starting to black/whitelist is a rats nest. jpeg ? or jpg? or JPEG ? What if photoshop is installed ? Then it will appear as a photoshop file.

Keep in mind that the button at the top are advanced action, by default clicking on the links will do the right thing (hopefully). And removing either edit (or view) has IMHO more chance of annoying advanced users than to really be annoying for newcomers, and I think that Jupyter have mostly been about allowing users to do arbitrary things, and that would go the opposite way.

[ellisonbg]

I totally agree we should give advanced users the tools they need. The issue in this case is that the "advanced" usage-case buttons are put right in the middle of very basic buttons such as Move, Download and Delete:

That makes the lives of the many non advanced users difficult, just to appease the advanced ones. The right UI for this type of thing would be to put the more advanced action behind a context menu, but I think that is outside the scope of 5.0.

Trying to think about an in between path...

We already have a reg-exp in these code paths for file extensions:

https://github.com/jupyter/notebook/blob/master/notebook/static/tree/js/notebooklist.js#L604

Editing those lists for the Edit/View button is trivial. Also, looking at file extensions is exactly how we map files onto models/views that can view/edit those files in JupyterLab. I can submit a PR to address this...but what to do exactly.

To me, the most important question is this "what precise things do the Edit/View buttons enable a user to do that they could not do otherwise". Based on what Thomas said that is:

• View an HTML rather than edit it.
• Edit text files that don't show up as text files.

Let me see if I can put together a PR that shows the Edit/View buttons for these cases alone.

[ellisonbg]

OK, I think the PR I just submitted addresses everything. Thanks!

[andyneff]

I'm still confused. Is this issue resolved? I just upgraded to 5.1.0, and I can not edit what I guess are considered "unknown" files now (but all purely text).

My opinion is to err on side of more flexible. Let anything be editable (with the understandable exception of notebook files, as already done). Maybe use an alert when you click edit to say "Hey, I think this is a binary file, are you sure?", but removing the edit button seem a little drastic to me.

MIME types, accepted extensions, unaccepted extensions (or even other suggestions like binaryornot) all seem to be making the decision for me, when I'd rather decide if I want to be able to click edit or not. Choosing the default behavior is fantastic, but preventing me from editing feels like a little much. Even if I'm only 1% of 1%.

Workaround

I can work around this by adding a bookmark with javascript:$('.edit-button').css('display', 'inline-block') and clicking it every time I want to edit a file that was determined to not be editable.

[takluyver]

Can you give some examples of files that you expect to be able to edit but can't?

[adl]

@takluyver The GNU Coding standards require all projects to have a set of text files called README, NEWS, ChangeLog, LICENSE, etc. Those are text files without extension. Python's mimetype.guess_type returns (None, None). Jupyter 5.1.0 does not allows those files to be viewed or edited, at least on my system.

As a Unix user, I'm used to think that everything is a text file unless proven otherwise, so this feels backward.

[ellisonbg]

If that is the case (I am not doubting you) then we definitely have a bug.
The edit/view semantics are a bit subtle, sounds like we missed some things.

On Fri, Sep 29, 2017 at 12:00 PM, Alexandre Duret-Lutz <
[email protected]> wrote:

@takluyver https://github.com/takluyver The GNU Coding standards
require all projects to have a set of text files called README, NEWS,
ChangeLog, LICENSE, etc. Those are text files without extension. Python's
mimetype.guess_type returns (None, None). Jupyter 5.1.0 does not allows
those files to be viewed or edited, at least on my system.

As a Unix user, I'm used to think that everything is a text file unless
proven otherwise, so this feels backward.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/notebook/issues/2203#issuecomment-333210893,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0LWbZjb8oDByq3qLTF6JDT6FkCjYks5snT5UgaJpZM4MFi32
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[kiendang]

I'm also on 5.1.0 and the Edit button doesn't show up for .r and .R files either.

[ellisonbg]

@gnestor - can we fix this for 5.1.1? - this is a pretty significant
regression

On Wed, Oct 4, 2017 at 8:16 AM, Dang Trung Kien [e-mail]
wrote:

I'm also on 5.1.0 and the Edit button doesn't show up for .r and .R files
either.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/notebook/issues/2203#issuecomment-334190000,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0K8pczPvWiAEAh0wDi7Jyfou33vrks5so6E9gaJpZM4MFi32
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[gnestor]

@ellisonbg Yes, I will push for a 5.2 release tomorrow or Monday with a fix for this.

[ellisonbg]

Thanks!

On Thu, Oct 5, 2017 at 3:16 PM, Grant Nestor [e-mail]
wrote:

@ellisonbg https://github.com/ellisonbg Yes, I will push for a 5.2
release tomorrow or Monday with a fix for this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/notebook/issues/2203#issuecomment-334607372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0BQSyg74RalkJexH7QWBOCJkNXp7ks5spVUlgaJpZM4MFi32
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[rgbkrk]

Could we get the current #2871 in as part of 5.2?

[gnestor]

@rgbkrk Yes! Shall I merge?

[gnestor]

Notebook 5.2.0rc1 is available on PyPI so please give it a try and confirm that this is resolved 👍:

pip install notebook --pre --upgrade

[blink1073]

@gnestor, did you mean 5.2.0rc1?

[gnestor]

I did 🤦‍♂️

[kiendang]

Just tested. Works for both .r files and files without extension. Thanks a lot @gnestor 👍