Donald Norman, in his book The Design of Everyday Things, makes the point that truly good designs are easy to use, because they make it intuitive how they should be used - in his words, they afford a usage pattern.
How do you describe the state of a running program on a whiteboard? You draw the stack. So it seems to me that a stack is the natural visual metaphor for a debugger. Here is a screen shot of our new Hopscotch-based debugger, which will soon replace the Squeak debugger in the Newspeak IDE.
You can see that the debugger looks like a stack trace. Every entry in the stack trace can be expanded into a presenter that shows that stack frame - including the source code for the method in question, and a view of the state of the frame - the receiver, the variables in the activation, the top of the evaluation stack for expressions (i.e., the last value computed).
Of course, this isn’t my idea. It’s another one of those great ideas from Self, as evidenced in this screenshot:
we already stole the idea from Self once before, in Strongtalk, as shown here.
One of the nice properties of the stack oriented view is that you can view multiple stack frames at once, so you can see and reason about a series of calls, much as you would at your whiteboard.
In contrast, most IDEs (even Smalltalk IDEs) show a multi-pane view, with one pane showing the source for the current method (in its file, naturally), one pane showing the state of the current frame, and one showing the stack trace.
You can’t easily see the state of the caller of the current method, or its code, while simultaneously looking at the current method (or another activation in the call chain). And if you modify the current method’s code (assuming you can do that at all), you’re likely locked into a mode, and can’t see the other frames unless you save or cancel your changes.
Hopscotch GUIs are inherently non-modal - so you can modify any one of the methods you’re viewing, and then link to another page to view, say, the complete class declaration, all without opening another window and without having to save or lose your work.
The fact that one rarely needs more than one window is one of the things I really like about Hopscotch. There’s no need for a docking bar, or tabs for that matter. Tabs are popular these days, but they don’t scale: they occupy valuable screen real estate, and beyond half a dozen or so become disorienting and unmanageable.
Hopscotch does better than the mainstream, and better than previous efforts like Strongtalk or Self, partly because of its navigation model, and partly because of the inherent compositionality of tools built with it. The fact that I can move from the debugger to the class browser in the same window did not require special planning - it’s inherent in the way Hopscotch based tools behave - they can be composed by means of a set of combinators. Compositionality is one of the most crucial, and most often overlooked, properties in software design; it’s what sets Hopscotch apart.
You can find out more about Hopscotch in this paper and on Vassili ‘s blog.
The design of debugger UIs is one example of something that needs to change in modern IDEs. There are others of course. Many are related to the basic problems of modality, navigation and proliferation of panes/windows noted above. Overall, your typical IDE UI is too much like the control panel of a B-52 bomber or an Apollo space capsule: a mind boggling array of switches, gauges, controls and wizards that interact with each other in myriad and confusing ways. This is neither necessary nor desirable. Like explicit memory management and primitive types, in time we will progress beyond these.
10 comments:
Kinda off topic, but I don't like to miss such an opportunity to sound pedant :) the B52 doesn't seem like a so good example because one third of the panel is occupied by the array of dials in the middle, which look like they are arranged in columns, one column per engine, the engine throttles being the eight levers at the bottom. It's like an audio mixing console with so many controls at first sight, but it's actually very regular and understandable once you identify the pattern.
These interfaces actually give direct affordances for many elements, rather than a single navigation affordance that you have to go through before you can manipulate one of the elements. In The Humane Interface, Jef Raskin praises the Sony 2010 radio that had a 8x4 array of buttons for presets, because it allows direct access to 32 stations, even by touch in the dark, while modern radios force you to select a station with a modal "previous/next preset" interface.
Damien,
You're probably right - the B52 interface may be a fine thing for all I know.
I've worked with hardware that is somewhat similar, and it is certainly not simple to master. So the B52 serves as an example of complexity, but maybe not of poor interface design or unnecessary complexity.
Unfortunately, the mentioned video is so blured and the camera too far away so you cannot see anything :(
I'd like to suggest to provide some screencasts to demonstrate the debugger and hopscotch in action.
BTW: As you quote Eclipse - do you think the proposed UI would also work for Java or Scala or other languages and could be build on top of the Eclipse platform?
Stefan,
I've been thinking of creating some videos of our own, as you suggest. Especially as it transpires that the StS08 video does not provide a usable view of the screen. Sigh. Maybe I should take down the link to it altogether?
Stefan,
I'm sure the ideas of Hopscotch would apply to languages like Scala and Java - both have nesting, which really benefits from this kind of navigation (as Vassili explains in his talk).
Regarding Eclipse: the concepts are of course universal, so you could in theory apply them in Eclipse or anywhere else.
In practice, it's not so easy. The existing paradigm is not really a good fit, so you'll probably end up with a hybrid, with panes and tabs etc. intruding.
I'll give you a concrete example: in our native interface, we'd like to use existing native file selection dialogs. However, these are typically modal, and fundamentally inferior to a Hopscotch based file selector. The latter would be non-modal, would not use up a new window, would be listed on the history page, could be extended to link to other tools seamlessly etc.
I'd expect a lot more of that sort of thing in an environment like Eclipse.
In general I've found that the benefits of the mainstream, with all its facilities, are often outweighed by the overheads of fighting with its problems.
Nevertheless, I expect that Hopscotch will influence other systems over time, even if the results will be somewhat lobotomized.
The Smalltalk world has been doing this for a generation, producing new ideas and seeing them spread to the wider world: witness window systems, pop-up menus, MVC, IDEs, GUI builders, Extreme/Agile programming, unit testing, refactoring.
I worked with the Self and Strongtalk debuggers many years ago and thoroughly hated them. I found I spent a lot of time managing screen estate instead of browsing.
I think the idea of using a linear layout has become viable only recently -- because mouse wheels have become ubiquitous. Without a mouse wheel linear layout requires too much gesturing. I guess this harps back to the book you quote ;-)
Hi Reinout,
Sorry to hear that. I'm not sure I understand the issue with the debugger and mouse wheels. Perhaps you can eleborate. I'll comment on what I do understand for now.
Managing screen real estate is an issue in Strongtalk, not so much in the debugger as in general.
In Strongtalk you tend to get a lot of windows - just as in a "standard" IDE you get a lot panes or tabs. One can debate which is worse, but both cause you to spend time docking/undocking, opening/closing or resizing.
In Hopscotch the situation is much better, because of the web browser style navigation paradigm, and the seamless, open-ended tool integration.
I hope you'll give it a try when we get to our first public release.
First, I must say you all have some fantastic ideas with this new language and I'm really looking forward to its release.
Do you plan to do any posts/videos for situations where the "treat everything like a web page" doesn't fit (e.g. a spreadsheet, or even a web browser itself for that matter), so one can get a feel on how difficult it is to break from the default?
Personally I don't care much for the "treat it like a web page" layouts, but I'll try to reserve judgment until I can use your system for myself.
The problem I always see is it puts even more things in my view that I don't want to see. For example, in Strongtalk I have to see text from at least all the categories in the class I'm working on. And not off to the side where I can ignore it like e.g. Squeak, but rather right in the "text space". When I am looking at one method I don't want anything else there. I understand your point about seeing more then one method at once, but when I want that I want *just those methods*. So for this example, Squeak actually gets me closer then an HTML view because I can open e.g. 3 windows and place them where I want.
The best for me would be to use some kind of selector and then my three methods come up automatically spaces for the display I have, but not extra data. Not method headers for all the methods between, etc.
I hope this doesn't come off as too negative because I really am looking forward to Newspeak. And I appreciate the fact that if I can't live with the GUI system I can just change it. :)
Jason,
Thanks for the kind words.
I think the idea of posting on how to deal with examples that might not seem to fit the mold is a good one.
The framework has a lot of flexibility in it. For example, a one line change to method presenters would allow you to view a single method on its own page, as you suggest.
I don't think that specifically is a good idea, and I can explain why, but I don't want to digress right now.
There are other views you may not have seen - for example, if you search for a selector, you get a page listing all of its implementors on the top, and all its senders on the bottom. I can imagine refining the search criteria so you get a list of just the relevant methods.
As another example, method presneters allow you to get a hierarchy view, showing all the implementations of the method in its superclass chain listed on a single page.
We've also considered letting you drag and drop presenters to form your own customized pages.
What we hope to avoid is adding features that encourage people to set up complex multi-pane views like traditional IDEs. I hope that Newspeakers will appreciate a relatively minimalist approach, that fosters creative solutions to GUI problems. We'll see.
It's also worth noting that because of class nesting, the traditional Smalltalk browsers just aren't workable in Newspeak; that is one of the things that got us started on Hopscotch.
One simple solution to jason's point (seeing too much) might be to make "Elision" first class. If I see 10 class categories in a list, I can "collapse" 1-5 into a "...", keep 6, collapse 7-9, and keep 10.
1-5...
6
1-9...
10
Post a Comment