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

Reconsider using the term "editor" for files and views on files #7903

Closed
gregvanl opened this issue Jun 20, 2016 · 14 comments
Closed

Reconsider using the term "editor" for files and views on files #7903

gregvanl opened this issue Jun 20, 2016 · 14 comments
Assignees
Labels
ux User experience issues

Comments

@gregvanl
Copy link

  • VSCode Version:1.3.0-insiders
  • OS Version:Windows 7

I think users will be confused by the term "editor" for a view on a file. Users think of VS Code as an "editor" of their "files".

I noticed this confusion when I started on the June_2016.md release notes. We have sentences like "As a preparation for enabling Tabs in the workbench, we revisited how you can interact with editors in VS Code. Many users coming from other editors were confused by some of the editor behavior in VS Code:"

As you can see above, we mention editor three times with two different meanings; as the tool VS Code and as open files.

This is more understandable as "As a preparation for enabling Tabs in the workbench, we revisited how you can interact with files in VS Code. Many users coming from other editors were confused by some of the open file behavior in VS Code:"

I recommend we use "OPEN FILES" instead of "OPEN EDITORS".

I don't see too many other uses of the term "editor" in the UI but some commands would need to be renamed:
Preview command Keep Editor -> Open File - I think "Keep Editor" will be confusing
File > Close Editor -> File > Close File - we no longer close the entire editor window, just the last file.

Using "editor" for the three editor windows seems fine so it make senses to talk about "editor groups" but these are groups of files not groups of "editors".

@gregvanl gregvanl added the ux User experience issues label Jun 20, 2016
@gregvanl
Copy link
Author

gregvanl commented Jun 20, 2016

If we move away from term "editors" for files, the breaking changes to the command ids called out in #6605 can be greatly reduced. Users and extension builders may be unhappy when their custom key bindings no longer work.

I'm also not sure there is real benefit in changing "Editor" to "EditorGroup" in the command ids. The editor window stays the "Editor" and now that it supports a stack of files doesn't mean the command id needs to change.

I worry that some of the UI and command id changes are being driven by implementation details and it isn't necessary to expose these to the user.

@bpasero
Copy link
Member

bpasero commented Jun 21, 2016

@gregvanl thanks for your suggestion but imho it does not make sense to call "editor" => "file" because there are many editor types that are not about files (e.g. markdown preview, the new extensions management editor).

@gregvanl
Copy link
Author

@bpasero I realize there are special views on files (preview, diff) and synthetic files that show up in an editor window but I think the 95% case is file system files. The term "editor" is already used to describe VS Code itself ("editor" versus an IDE) and also the three editor windows (LEFT, CENTER, RIGHT). I think using the term "editor" to also describe the items in the editor window is confusing and terms like "OPEN FILES", "file groups" and commands like CloseFile better matches the user's mental model.

@bpasero
Copy link
Member

bpasero commented Jun 21, 2016

@gregvanl can you summarize where exactly you would want to talk about "files" instead of "editor"? we already have command Ids out there that talk about editors (that we cannot change) and we actually talk about editors since our initial release so I am not sure why this issue is suddenly an issue.

@gregvanl
Copy link
Author

@bpasero Exactly, the current insiders implementation changes the old command id use of "editor" to be "editorgroup" and is a large breaking change. I don't think we need to make this breaking change. I would leave "editor" as is and it refers to the 3 editor windows. I would keep the term "file" and not rename it to "editor".

@bpasero
Copy link
Member

bpasero commented Jun 22, 2016

@gregvanl I would appreciate if you could point me to the commands in particular how they should be. there is a list of commands in #6605

@bpasero
Copy link
Member

bpasero commented Jun 22, 2016

I am asking because it is not clear to me where you want to use "file" vs "editor".

@gregvanl
Copy link
Author

Sure, I thought of doing this last night but ran out of time.

@bpasero
Copy link
Member

bpasero commented Jun 22, 2016

@gregvanl also to clarify: you would only change command ids and not other UI pieces?

@gregvanl
Copy link
Author

gregvanl commented Jun 22, 2016

Here's Atom's editor pane documentation

They call out "items" to refer to non-file content in an editor pane: "Each pane has its own "items" or files, which are represented by tabs." The rest of the documentation just continues to talk about "files".

@bpasero
Copy link
Member

bpasero commented Jun 22, 2016

image

No mentioning of files in their commands that "Close" something.

@bpasero
Copy link
Member

bpasero commented Jun 22, 2016

Essentially Atom solves this by calling an entry in a Pane an Item because it is not necessarily an editor to change the contents inside.

@gregvanl
Copy link
Author

gregvanl commented Jun 22, 2016

While not very exciting, I am getting behind on the term "item". Items can be files, previews, readonly and synthetic views which are displayed in the editors. The header could be "OPEN ITEMS" and we could have commands "Close Item" to close the top item in the editor stack and "Close Editor" to close the active editor.

@gregvanl
Copy link
Author

Even if we go with "item" instead of "file" and don't change "editor" to "editorgroup" that only saves 8 breaking changes (ex. focusFirstEditor, etc).
Given that "editor" doesn't show up often in the UI, "editor" is probably fine and accurate enough (ignoring readonly cases). We'll need to be careful to correctly call out "editor" and "editor groups" in commands and try to leave other commands generic (for example: I think we should change "Keep Editor" to "Keep Open" #8026).

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ux User experience issues
Projects
None yet
Development

No branches or pull requests

4 participants