How do I label a button that exposes a "code behind" editor?

Question

Background

I'm building an editor where the user interacts with a graphical representation of the data. This data is actually generated from a script which the user may expose and edit (the "code behind").

The Ask

How can I best design the UX to explain to the user what will happen when they click the button that exposes (unhides/slides in/fades in/...) this adjacent text editor?

The common terms seem like poor choices to me since they describe the text ("code behind", "script editor", "development environment"), rather than explain what it does or the nature of its relationship to the graphical data they are currently viewing.

Am I way off here? How should I architect this interaction?

Example

Here is a screen shot of the graphical editor next to the textual one. When you first arrive the text editor is hidden.

Thank you

Thank you for your input! Cheers.

Answer 1

You should label buttons so that they explain what they do. This is different from the why, which is better explained in longer form elsewhere: there could be any number of reasons to do something.

Your button will show the editor for the source code behind the graphical representation. I.e. it will "show source editor".

In web browsers you can usually "show page source", which has a similar functionality except it's not editable. Opening an editor should communicate the fact that you can edit the source, and it should be obvious that opening the editor would also be a way to view the source. You could call it "source", "source code" or "code" depending on what makes sense for your situation.

Answer 2

Don't worry about the label. Instead, associate the control geometrically with the action it performs. If the code editor slides in from the right-hand edge, make the button look like a pull-tab and put it on the right-hand edge of the screen. Involve it in the animation you use, by making it slide with the code editor, or rotate to become part of the title bar, or some other way. Use the same control to hide the code editor again, and don't change the label (except possibly to show the on/off state, or to flip an in/out arrow).

By making it clear that the control shows additional content rather than performing a (maybe irreversible) action, you're encouraging users to press it speculatively, as part of discovery behaviour when they first use the program. Keeping the label the same makes it easy for them to hide the content again when they've seen what the control does. Keeping the control near the panel it reveals makes it easier for the user to associate the control with the panel, to remember it next time they want the same control.

If you follow these guidelines to take full advantage of the user's discovery behaviour, it won't matter much what you label the control, as long as it can be distinguished from other nearby controls.

Answer 3

'View source code' or 'Inspect source code' where-in your replace 'source' with whatever terminology you are using on your platform.

I see this being used in browsers and WYSIWYG editors (mainly web dev ones).

Answer 4

First you should decide on the terminology you think is most useful. I've worked on similar things, and the story we liked was "you're working on a model and there is graphical representation of it and a code representation of it." Alternatively you could use "graphical model" and "code model", but I think "representation" is more accurate than "model" in this use.

Having decided on the story+terminology, those words should be surfaced in the UI: "View code model" or "View code representation" or simply "Code model" for buttons and menu items.

I don't like "Source code" because it implies the graphics are derived from the code, which may not be the case: the code might be derived from the graphics.