Frame-Based Editing

Traditionally, programs are written as text files. Writing programs like this comes with many disadvantages, such as being able to make nonsensical errors. Much like the sound of one hand clapping, what is the meaning of an unmatched bracket? Why can a misplaced character early in the file cause the rest of the file to be unparseable? In frame-based editing, each statement or structure in your program is one cohesive, indivisible element: a frame. Here's an if frame: There is no syntax to memorise, type in or mess up; the keywords (if, while, etc) are just non-editable labels. (If you are familiar with block-based editors, we discuss how frame-based editing is different later on.)

If you want to insert a frame, you press a single key to add it. For example, to add an if frame, you press the i key (click left-hand icon to play animation):

During text editing, you have a text cursor that sits between characters to act as an insertion point. In frame-based editing, you similarly have a frame cursor, that sits between frames and acts as an insertion point. The blue bar is the frame cursor. You use the frame cursor to navigate up and down between frames with the up/down keys:

Because a frame is one element, you can't have half a frame; there is no idea of mismatched curly brackets here. Many syntax errors are thus automatically prevented. Frames can be manipulated as a whole item: easily dragged around, cut, copied and pasted without accidentally missing a curly bracket: And in fact, we can disallow drops where code is invalid; statements can't be dragged into the class scope (and methods can't be dragged inside methods): You can see that the drag target is indicated as invalid (via the red cross); in these cases, releasing the mouse button simply cancels the drag.

Wrapping code inside a control structure is a reasonably common manipulation. But you only need to insert the top and bottom brackets separately because that's how to accomplish the manipulation in a text-based editor. In a frame-based editor, you can do it more directly. You select the frames you want to wrap, then just press the shortcut key for the frame you want, like w for while:

Frames aren't just a way to edit text; they are a different representation of a program. Once you move away from the idea that your program is a text buffer, you can explore different mechanisms, overlays and displays of your code.

Here are two examples. Firstly, it is generally useful to have some idea of where you are in your code -- for example, which method you are editing. Once the method header scrolls off the screen, you usually lose this context. But in our editor we just pin the header to the top of the screen: This sort of context is often useful in your code. But if we pinned a header for every structure (if frames, while, etc) then you would soon run out of room on the screen. But there is some unused space we can take advantage of; the indent space. Here's what happens when the top of the structure scrolls off the screen -- the header is duplicated in the left indent margin: Naturally, this becomes more useful, the longer the body of the statement is.

Comments are generally used in programming for two purposes. One is to actually add a text comment to some code, to explain what is going on or apologise to the next programmer for the code you wrote. The other purpose is to disable some code. It's interesting that using comments for this is so firmly embedded that we tend to refer to "commenting code out" rather than "disabling code" or "turning off code". The fact that you use comments to disable code is a historical accident; the better thing to do is to have a way to just directly disable code. Like a right-click menu item: The frame remains present, but blurred to indicate it is disabled. It can be re-enabled in the same way.

No. Frames are useful for statements, but they get unwieldy if you were to use them for expressions. So to allow for faster editing, expressions are edited a lot like text, in something we call slots.

Sometimes a slot is a single text field; a variable name slot in a variable name definition is a single text field. But expression slots can have a richer structure. This allows us to do things like having prompt text for parameters in method calls:

Of course -- this isn't just a theoretical concept. It's built in to our Greenfoot software, aimed at helping beginners learn to program. First, download and install Greenfoot 3. We'll switch to video to guide you through the process of writing your first project: We are hard at work on the final version, which we hope to release later in 2015.

One of the initial struggles in programming is mastering syntax; remembering the keywords and brackets (or indents in Python), entering them correctly, and not messing them up when editing. Teachers will know that students left alone with code will randomly delete curly brackets and destroy indentation -- but frame-based editing doesn't lumber them with curly bracket or indent management.

Yes -- and Scratch is great for absolute beginners. But as students become more proficient and turn into intermediate or expert programmers, block-based systems become quite limiting. It is hard to manage and manipulate larger programs, and program entry becomes tedious, with too much dragging needed even for simple expressions like x=1+2. Frame-based editing makes a natural follow-on to block-based editing, via two key differences: we do not use blocks at the lowest levels of the program, and we have support for keyboard entry throughout.

One of the big drawbacks of block-based editors is that program entry can become quite tedious, because you have to drag and drop everything. For example, here is how you write x=1+2*3 in Scratch -- primarily by dragging: In our frame-based editor, this can be entered entirely with keys: =x 1+2*3 as follows: Frame-based editing gives you the advantages of easy manipulation for larger frames, without getting fiddly while editing expressions.

The shortcuts are useful to learn, but they don't have to be memorised -- the help column on the right-hand side shows the available shortcuts: This is an improvement over text editing, where students not only had to memorise the syntax for each construct, but also remember which constructs were available to them. The help provides some guidance and prompting.

It is like the blocks menu in Scratch. The nice thing about the frame menu is that it is so much smaller than Scratch. Scratch has lots and lots of quite specific blocks; assignment, expressions, turning, moving, changing colour, and so on. Greenfoot has only a few top-level frames, with much of the functionality effectively moved to be within method calls. This means that the frames menu is less overwhelming than the blocks menu.

The equivalent to the frames menu for method calls is code completion. Once the cursor is in a slot (e.g. in a method call frame, or in the condition of an if frame), you can press Ctrl+Space to bring up code completion. This shows all the methods and variables that are available: You can either click on the method, or use the keys to select a choice.

Most students are not expert typers. The code completion shown earlier helps cut down on typing. But there is also support for correcting typing mistakes. Much like google search, if you make a mistake while typing, then we try to offer corrections in the code completion: We also offer quick fixes for mistyped variable names (soon to be extended to method names): This is particularly useful when students forget about case-sensitivity:

Our intention is that students, starting programming at ages 5--10, will go through block based editing and frame-based editing to reach text-based editing. (Ideally, we hope that frame-based editing will be superior to text-based editing and catch on professionally, but we recognise that for the foreseeable future, text-based editing is the eventual destination for students.) Our Stride programming language is very similar to Java, so students can start in Stride and learn all the semantics of Java, and later on transition to programming Java with textual syntax. The students don't even need to leave Greenfoot: we have our new Stride editor, and our classic Java editor. They can even seamlessly have Java and Stride classes in the same project as they transition.

There are a few added features to help understand object-orientation. Greenfoot is already designed to help convey concepts like classes and objects. In the interface, the classes are shown on the right-hand side (there is one Rocket class) and the objects are seen on the left-hand side (there are multiple Rocket objects): One thing that we have seen students struggle with in Greenfoot is inheritance of methods. They often call methods, like move, without really understanding where the method "comes from", or why certain methods are available in Actor subclasses but not in World subclasses. We now have a new inherited methods display, which shows which methods are available (inherited) from the parent class: For convenience, these methods can easily be overridden in the current class by right-clicking on them: We also automatically label overridden methods to aid understanding:

Programming is a mix of planning, navigation, and code writing/manipulation. Frame-based editing can speed up the last item. We've seen already how elements can be moved around easily. Program insertion is also faster. Consider writing an if statement in a text editor: if (b) { }That's ten keypresses in all. In our editor, that is done with just three: ib To produce the same code:

IDEs do have these templates (although I wonder how many programmers actually use them?). But it's still more keypresses, e.g. in Eclipse it's still Ctrl+Spaceif b -- 7 keypresses. Frames also have the advantage that you can't accidentally mess up the syntax afterwards. These templates show that writing individual text elements makes no sense when they follow an easy template; but why allow users to edit the "if" text afterwards?

Yes -- but one interesting difference is that they are much easier to implement in frame-based editing. If you want to offer code completion based on the current location in the source code, you have do a lot of parsing to figure out where you are, and it becomes much harder when the syntax is incomplete or parts are missing. In frame-based editing, you can easily determine what the context is. Here is an example of contextual code completion -- watch carefully what is offered: In the method return type, types are offered. The method name offers overridable methods from the parent class (though we don't choose one). The parameter type offers types. (The parameter name offers no completions.) The method call frame offers method names. The catch type offers only Throwable and its subtypes.

Not just yet -- for one thing, it's only in our beginner's system at the moment, and also, we lack many of the features required to manage larger projects. But it would be nice for some professionals to try it out and see potential advantages, and hopefully a frame-based editor will one day be available for a JVM or .NET language (or similar) in something like NetBeans, Eclipse, Visual Studio, etc.

In theory, yes: our code is GPLv2 with classpath exception. We started out trying to develop the editor so that it could be taken standalone, but that turned out to be a huge constraint while developing, and not necessary for our primary aim (to develop a good editor for Greenfoot). So the editor is now quite tightly coupled to Greenfoot.

It does -- and more generally, spacing of code is approached totally differently in frame-based editing. In text-based programming, spacing is done manually, and to make sure that things line up, space characters are used. But this is retrograde compared to most other applications of computing: you don't use space characters for spacing in a Word document or on a webpage.

There are two aspects to spacing in code: indentation of each statement, and spacing within a statement. Let's start with the former: indentation of frames is automatic. The position of a frame is dependent on where it is in a program, and there is no need to manually enter or adjust the indent.

Yes -- our answer is neither!

The size of the indent is a graphical attribute, set in a CSS file, just like it would be on a webpage.

Yes -- and this achieves a separation between display/editing of code, and the actual content of code. We don't provide this option in our editor at the moment as we prefer having less configuration options -- but our editor is just one instance of the larger idea of frame-based editing. You could definitely do as described.

In document display systems like HTML and LaTeX, spacing is only used to separate words; multiple consecutive space characters have the same meaning as a single space character. The display takes care of spacing. In programming we often don't even a space character to separate words (identifiers); we have operators like + or . instead. Rather than rely on the programmer to input and manage whitespace, we automatically manage it.

If you want to input the expression 1 + 2 * 3 in a traditional editor, most programmers will type 1 + 2 * 3, with spaces around each operator. In frame-based editing, you save those spaces; typing 1+2*3 will still add whitespace around the operator: In our editor, the space bar usually either does nothing, or it acts as a navigation key (moving to the next slot). You may have noticed that the whitespace is also variable depending on operator precedence, shown more clearly in these two lines: In the line with only additions, the spacing is uniform as the precedences are all the same. But on the second line, the multiplication and division have less spacing to their operands, reflecting that they bind more tightly than the addition (which has more spacing to its operands).

When you write a paragraph of text in HTML or similar, you don't have to worry about manually wrapping the line; the system automatically flows the paragraph at the boundary. This is how code should behave; you write the line of code, press enter at the end, and the editor automatically wraps at the display boundaries. No need for semi-colons or line-continuation characters or manually indenting continuations -- here's what happens when you resize the window:

One major reason that people use vi and emacs is that they have incredibly powerful macro systems; with limited resources, that's not something we intend to support. But generally, graphical systems should be able to achieve all the usability of terminal based systems, and then improve on them. The key idea behind our editor is that if you stop viewing programming as a text buffer (which is exactly what terminal-based editors are designed for) then you can achieve better results.

No. The intention of the editor is to be better than editing a text representation, similar to say, how assembly language is better than writing binary machine code. If you use the editor and find yourself regularly wanting to return to a text editor, we haven't got it right yet.

Not necessarily. Our language, Stride, is stored as XML. While it's not intended to be human-edited, it demonstrates that you could define an interoperable standard between multiple editors for a language. Software lock-in is not caused by having a different editor, it's caused by not having a standard file format.

Roughly speaking, yes -- in principle you could edit any structured language in this way, like HTML or Python or C# or Haskell or whatever. In practice, you might need to tweak the syntax in a few areas to reduce ambiguity or smooth some rough edges. For programming languages, I believe that frame-based editing will work best when there is a clearer expression/statement divide. We are still thinking about cases where code blocks can appear in expressions (e.g. lambdas and anonymous inner classes in Java).

Stride translates to Java, and has been deliberately kept very close to Java in its semantic model. We wanted to create a new editor, and were not interested in creating a whole new language semantics (and compiler, etc) at the same time.

The ideas are similar to structured editing. Structured editing wasn't actually a bad idea, it was just poorly executed. In the intervening 25+ years, computing has gained advanced display/GUI capabilities, and we've learnt a lot about the usability of software. So you can think of this as a fresh attempt at structured editing. And really, this isn't the first attempt; Scratch and similar languages have already showed that these kinds of ideas can work.