A place to be (re)educated in Newspeak

Saturday, July 31, 2010

Meta Morphosis

Recently, I was pointed at rotated Google. This is cool in a perverse sort of way, and it immediately reminded me of Morphic.

For those who don’’t know, Morphic is the name of the Squeak (and in earlier times, Self) GUI. John Maloney (who nowadays does Scratch) introduced the original Morphic GUI back in the halcyon days of Self, and later adapted it to Squeak Smalltalk. The latest incarnation of a Morphic-style UI is Dan Ingalls’ lively kernel, which adapted the ideas to Javascript and the web. You can check it out in your browser right now.

What makes Morphic interesting is that it is compositional. The basic building block is a morph, which is just a graphical entity. The key is that everything in Morphic is a morph - including not just the basic morphs like lines and curves, polygons, circles, ellipses but also text, buttons, lists, windows ... you name it.

All morphs support pretty general graphical combinators - translation, rotation, scaling, non-linear warping, changing color, grouping/ungrouping etc. It follows that one can interactively rotate, scale or non-linearly warp an entire window running a live application.

One of my favorite Squeak demos is a class browser that’s been animated so that it floats around the screen, rotating as it goes, coupled with sound effects (a croaking frog is my preference). Of course you can keep using the browser and add methods or remove instance variables on the fly while it’s doing that. It’s an amazing display of the power of compositionality in action. It’s also perfectly useless (like rotated Google).

When running Morphic, you can always interactively ungroup a composite morph and get at its pieces. So you can disassemble the UI and find out what its made of. You can also do the opposite and assemble a UI out of simpler morphs; in a sense, the GUI is the GUI builder.

The situation is quite analogous to the physical world. A real window (the kind used to let light into your house) is assembled from physical pieces, and can be disassembled as well. The window as a whole, and each of its components, can be manipulated in space in uniform ways.

Thankfully, the laws of physics are compositional, since they were not designed by software engineers on a standards committee.

Put another way, if the universe was built like most software, it would have crashed long ago; the big bang would have a different meaning.

As a demonstration of good computer science, Morphic is brilliant. However, as a working UI it is problematic. You don’t really want your windows to fall apart in the user’s hands because they accidentally pressed some control sequence.

Looking at how physical windows work, we see that when they are assembled, they are secured so they are not disassembled too easily. Things are held together with glue or screws or whatever, and you need to make an effort to take the structure apart, perhaps using special tools.

This points at the way morphic interfaces should evolve. It’s great to have the underlying flexibility that they give you, but we want mechanisms to prevent accidents. We don’t want our applications decomposing by mistake. We also don’t want loose windows rotating by mistake. We need the equivalent of screws to hold things in place. The nice thing about screws is that they can be be used to build things up from parts compositionally, and they can be unscrewed when necessary. That way, we can take advantage of the flexibility of the underlying framework and do cool things with it, while keeping it safe for the end-user.

As rotating Google and (more significantly) Lively show, the web opens up the possibility of such UIs reaching a broad audience. I am sure we will get versions of morphic that are more refined, usable, attractive and polished - all less than three decades since they were introduced in Self. Instant progress!


gulik said...

I fail to see what is architecturally interesting with Morphic.

It's great as a kids toy, and E-Toys proves this. This is where you want to pull things to bits and put them back together, because it's fun.

However, actual user interfaces should be locked down. The user should not be able to change it. I agree entirely with you on this. I don't understand why the editability of Morphs is a good thing, and why the Morph base class even supports this. The editability should have stayed in a subclass somewhere, as a kid's toy. The editability is the big selling point of Morphic, and I've never understood why.

Once you take away the editability of Morphs, you're left with a standard widget set just like any other widget set. This is what the standard widget set of Squeak always should have been: light-weight, simple and only modifiable from code.

gulik said...

You say "What makes Morphic interesting is that it is compositional. The basic building block is a morph, which is just a graphical entity.".

I'd also like to point out here that most other "boring" widget sets work in the same way. For example, the base class of any Java Swing component is a JComponent.

Gilad Bracha said...


Let me try and get my point across again, more bluntly:

Try and disassemble your Eclipse window. You usually don't want to, I know - but that is not my point. My point is that you can't - even when you do want to (to see what makes it tick).

You can't, not because the application locked it down. It was locked down at (mis)conception. Using Swing instead of SWT would avail you nothing of course.

That lack of flexibility is a direct result of restrictive design. The GUI elements do not compose when they are running *live*.

If they did, one could choose to lock them down or not, depending on the context. That flexibility is valuable.

Alexandre Jasmin said...
This comment has been removed by the author.
Alexandre Jasmin said...

In Squeak Morphic I often find it useful to take the UI apart.

If I want to automate an action that is triggered by an UI item I can easily inspect that item and find the code behind it. I can even clone the item and modify it on the fly.

I also like the fact that windows are not special. I can just spawn morphs directly on the world and play with them in a workspace. I can also move morphs in and out of their window and experiment with various layout managers for instance.

Even though it's "fun" to have some editability I think it's much more than a simple kid's toy. Complex desktop applications such as IDEs and word processors have very flexible UI. They include configurable toolbars and draggable panels. Often users can add their own UI items for launching scripts and macros.

If a flexible UI is needed I don't see the point of restricting that flexibility to just a few parts of the application. It's good to have a few screws holding the thing together but software objects are sufficiently malleable and cheap that I can afford breaking them. If I break the Eclipse window in "debug edit mode" it should be easier to fix than a physical window.

Actually I see a similar paradigm in web development. Using Firebug (and other web inspectors) I can edit a page DOM, change CSS styles and execute scripts on the page. I think such exploratory programming tools are invaluable.

I have not used the Lively Kernel yet but I find it very intriguing. It seems it can turns the little experiments I do in Firebug into an integral part of web development.

Stephen said...

More and more UIs are going in the direction of Morphic (exactly the opposite of being locked down and only modifiable with code). Eclipse itself with its detachable menus, perspectives, reconfigurable tabs, etc is working in the direction of Morphic, but it's primitive and just scratching the surface (though I would also consider Morphic to be primitive). Take a look at advanced stock trading UIs...they are probably pushing the edge in terms of reconfigurable user interfaces. I would like virtually every kind of application I use to support the type of reconfigurability that Morphic offers (albeit more refined than Morphic). I want to be able to view information in a way that suits me rather than someone else's notion of what would suit me.

Unknown said...

So Squeak affords the user lots of power to change the system, but that comes with the risk of the UI falling apart in her hands.

This sounds to me like (your description of) the old world of pre-service computing. Managing my own computer gives me lots of control, but it does tend to fall apart in my hands.

That bargain works for me, but less well for my mother who prefers booking holidays to fiddling with computers.

So it's "central services" to the rescue. Joy (until there is a problem with a duct).

But you suggest that we *can* have things that are both adaptable and strong if we put those things together carefully with screws and ductile materials rather than throwing them together using brittle stuff and a dab of glue.

So why do we need the services again? Why don't we just get local computing right?

I know, I know -resistance is futile.

Perhaps Newspeak secretly resists Central Services by making real computing viable on the edge..

Alas, I fear Newspeak's problem will be the effective disappearance of computing power outside the datacenter.

Creideiki said...

You are talking about solved problems. The solution is known and called an undo log. Allows anything to happen, but never allow to break the undo function. That's all.

You could go further by making multiple undo log (one for the user datas, one for the system/programs state, revision 1 is the just installed system state). Or to allow to work on a projection of the undo log ("only revert changes to this selected block of text", I always wanted this function in text editors).

Under Microsoft OS it's called Ctrl+Alt+Del. It's far from perfect, but for most clueless people it's the 'come back to stable state' keybinding.

Unknown said...

I can't resist asking..

Am I correct that you and Dan Ingalls are now colleagues at SAP Labs?

Does this mean you stand around the water-cooler discussing how nested classes fell out of Smalltalk?

And has Dan convinced you that browser based Brazil needs to bind to the SVG DOM and bypass HTML entirely?

Its great fun to speculate about what the two of you might cook up...

Gilad Bracha said...


I don't see this as a services vs. local issue. Both of these have UIs and the UIs will tend to have the same issues in principle.

As for your later post: Dan and I are both at SAP labs, but not in the same group. We do chat on occasion, but I couldn't comment on the contents. I'll let you speculate instead.

Gilad Bracha said...


Unlimited undo is a very good thing. Allow anything to happen is more questionable. For example, you don't want the to let the undo button get thrown away by accident. And Ctl-Alt-Delete is not the answer of course: failure is not an option.

So, no, I don't think any of this is a solve dproblem. It is a solvable one though.