Java uses something called "ant" that's based on XML, and it quite sensible. Other programs can read and generate ant files, without having to follow all the ridiculous rules of Makefile's horribly ill-conceived syntax (like the distinctions about tabs). If only it weren't written in Java, ant would be the ideal replacement for make.
I don't know what you're doing to make using make so hard. Automake is tough, but for a single project, which you dont intend to be porting to other systems, a Makefile containing the targets, the sourcefiles, and the commands to compile each takes about 30-60 seconds of typing per target (especially with copy and paste and variables for compiler options), assuming you know how your source files fit together. If you want to do fancy stuff, buy a book. (See B. Not all wisdom is oral.)"
The very existence of make is a dire threat to our very American way of life.
You should be ashamed of yourself, apologizing for make. Sadam Hussein is more deserving of such an analinguistically adept rim job that your flattering words give to the daemon-spawn make.
Does your mother's mother know you've sunken so low?
There's a challenging job opening in Iraq for a new Minister of Information, to which you should consider applying your considerable anal-oral wisdom and reality distortion skills.
America: Love it or leave it. And to love America means to reject all forms of Makefiles!
Festival has some singing demos, using a simple XML format to mark up text with beat duration and note pitch information.
And Oregon Graduate Institute's CSLU Toolkit extends Festival with an implementation of Sable: an XML format that lets you mark up text with arbitrary timing, pitch and volume envelopes.
Main Entry: dictionaraoke
Pronunciation: 'dik-sh&-"ner-A-O-ke
Definition: Audio clips from online dictionaries sing the hits of yesterday and today. The fun of karaoke meets the word power of the dictionary.
I'm working on a project involving voice synthesis, so we've been shopping around and evaluating different systems.
We were hoping AT&T would do a better job than IBM at supporting their voice synthesizer. IBM pulled the Linux version of ViaVoice off the market without so much as a peep to their adoring fans on Slashdot, and wiped all mention of the Linux version from their web server. (Goggle isn't even allowed to cache it.) After IBM milked the slashdot linux fanboy publicity for all it was worth, they appearently didn't see any purpose in actually SUPPORTING the product -- so once their libraries stopped working against the latest Gnu/Linux libraries (happy birthday RMS!), they dropped their Linux voice synthesizer product like a hot potato instead of bothering to recompile it and issue an update.
So we hoped AT&T would show more comittment to the promises they made on their web site about their flagship voice synthesizer product, but...
Has anyone actually tried buying a single user copy of Natural Voices from AT&T? YOU CAN'T ANYMORE! They used to sell the synthesizer for workstations and voices for competitive prices (in the 100s of dollars range). So we bought a few voices to evaluate, and sent some simple technical questions into the email address they provided for support, never receiving a reply.
After several weeks they never answered any of our questions, but we decided to buy some more voices to evaluate anyway. But by then, AT&T had pulled the consumer single user version of Natural Voices off of the market (and it took weeks of phone tag to find that out because they don't give out "technical" information on the phone, and they never answer their email support address).
Now if you want to buy a Natural Voice from AT&T, you have to buy the server edition for tens of thousands of dollars. Had their support not absolutely sucked, it might have been worth us paying such a high price, but no way we'd ever consider going with AT&T, after they demonstrated such horrible unresponsive service.
Actually it's a good thing we didn't go with AT&T's voice synthesizer, because we need support for voice authoring tools, and AT&T is incompetent in that regard, since they refuse to give out technical information over the phone, and never answer their email. No support whatsoever. Zilch. Nada. Forget about it.
The quality of the commercial voices comes more from throwing lots of time and money into the production process -- the commercial software is not any more advanced than the open source research projects -- in fact the research projects inspired the commercial products!
-A speech synthesizer user who's been jerked around by AT&T and IBM, and is now happy to have no other choice but to use excellent open source software.
Date: Fri, 8 Apr 88 19:30:41 EDT
From: Don Hopkins <don@brillig.umd.edu>
To: weiland@bensun.cs.umd.edu, plaisant@bensun.cs.umd.edu
Cc: don@brillig.umd.edu
Subject: NeWS front end
I've implemented a window with space for a control panel at the bottom
and appropriate methods for handling it (no scroll bars), taught the
formatter about.startcontrols and.endcontrols, and made classes of
control buttons, so now you can describe the control panel as a
storyboard file. (This seems to me to be a good idea.) I've also given
the formatter a good working over, and it's a lot nicer now. It will
not run off the bottom of the page any more. It makes sure there's
room before putting anything down. It handles the line height
correctly now. (i.e. before, if you were in a tall font, then did a
newline, then switch to a short font, the new line would be as tall as
the font you were in at the start of the line, even though there are
no words in that font on the line. Now the line will only be as tall
as the tallest text or displayable actually drawn on it. It will put a
piece of text or graphics onto the next line if it won't fit on the
current line, unless the cursor is at the beginning of the line (so no
unnecessary blank lines). It will put it on the next page if it won't
fit on the current page, unless the cursor is at the top of the page
(so no unnecessary blank pages). While it's laying out the stuff and
building the display list, it draws rectangles on the page to show
where it's at. (i.e. the bounding box of the last line it completed)
When it finishes each page, it erase the rectangles and draws the
stuff it just layed down. It handles damage to the pages correctly
now, by repainting them, so it's not necessary to retain the images of
obscured canvases. (They will be repainted from their display list
when exposed.) So it should run OK in color, but that still needs to
be tested. When you format a multi-page document, you see the first
page being layed out (rectangles), and when it's done, it's painted
and the touchables become active. At the same time, the rest of the
pages are being formatted underneath the first page on top. You can
flip through the pages and touch the touchables while the formatting
is going on. (No callbacks to the client can happen till it's done
formatting, though.)
Do you want me to write a real storyboard parser? I'm still using
Forth right now.
Some more things I still need to do: Magic back and next buttons that
dissappear when they're not applicable. Title and page number in the
frame label. The formatter should aggregate adjacent strings on a
line into one.
The fact that ICCCM is a total nightmare negatively effects the quality of life of all X-Windows users, not just developers. Aren't you aware that the Linux desktop user interface experience is absolutely horrible, or have you poked your eyes out with hot pokers to keep from seeing that? Didn't you ever wonder why all X11 window managers and toolkits and applications suck? When you build bookshelves out of mashed potatoes, the ants will come. If you've brainwashed yourself to believe X-Windows doesn't suck, you might as well be enjoying Microsoft Windows 3.1 -- you're self delusional enough to fool yourself into anything!
I've landed some interesting jobs programming Forth (like a summer internship at Sun in 1987), and used it for many projects (although not recently). Today I use Python instead of Forth, for many of the same reasons, but without most of the problems.
It was based on Langston and Perry's Forth83, and developed by Mitch Bradley at Sun, who is a major Forth guru and hardware guy. When you hit L1-A on a Sun, it dumps you into the Forth boot monitor, which let you do all kinds of things to the hardware and nvram configuration.
The point to having a cross platform bytecode dialect of Forth in firmware, is so hardware devices can have drivers, diagnostics and configuration interfaces in ROM that will execute on any system, no matter what the processor. That was implemented long before Java was ever invented.
Forgot to mention, here's the PizzaTool source code in case anyone's still running NeWS or wants to see an example of an interactive PostScript user interface. It was a NeWS Toolkit programming example, so it's heavily commented. They forced me to remove the faxing code for the OpenWindows release, because Warren Teitleman was afraid that "it might give away Sun's multimedia strategy", as if they ever had one.
Pizzatool used the NeWSPrint PostScript to Fax server that Sun was running for a while.
I believe Ross Thompson at Adobe wrote a shell script called "burrito" a year or so later. It faxed orders to La Costania, but it was a command line tool without a graphical user interface and PostScript preview window like PizzaTool. (You could actually spin the pizza preview with the mouse.)
The first time I faxed a PostScript picture of a pizza to Tony and Alba's, they were quite confused and didn't know what to think, because I had neglected to list the toppings out as text, they were just rendered graphically. So they had to look at the black and white faxed rendering of a pizza, to decypher which toppings I ordered. I took a bug report and fixed the problem by adding the text so they could figure out the subsequent orders.
Here's a video that includes a demo of the spinning pizza in pizzatool (as well as lots of other weird inexplicable stuff)...
Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.
If you will read the documents that the links point to, you'll realize that pie menus ARE focused on usability, and are not just "bells and whistles".
They are provably faster and more reliable than linear menus, and you can run this experiment and prove it to yourself if you don't believe me or any of the research papers that have been published over the years:
Fasteroids is a free game that lets you compare pie menus with linear menus. Take the pie menu challange! Fasteroids tracks your selection speed and error rate, so you can compare pie menus and linear menus for yourself.
Adaptive user interfaces have their own problems: instability, unpredictability, violating the principle of least astonishment.
Generally it's not a good idea to change user interface properties like the slice width, direction or order out from under the user, because that interferes with the training effect of muscle memory. It's much more important that the user be able to learn the menus and mouse-ahead reliably, than having menus automatically adapt to the user's usage patterns.
Computers are notoriously stupid and often make the wrong decisions about adapting, introducing changes that hurt more than they help. Adaptability is really an AI problem.
Certain directions (the primary ones up/down/left/right, depending on the input device and handedness of the user) are easier to select than others (like the diagonals). So it's a good idea for the menu designer to use those for the most important items. But it depends heavily on the meanings and functions of them items and the usage patterns of the users. And the computer is incapable of making such high level decisions and aesthetic judgement calls.
Giving the user the ability to easily edit the menus themselves is a much more reasonable approach than automatically and unpredictably rearranging the menu behind the scenes without the consent of the user (the so called "adaptive" approach).
No, we tried to convince Sun to make it freely available for years before they finally canceled it, and lost the source code.
I've still got a copy that runs on my old SparcStation 2, but unless somebody's created a good SparcStation 2 emulator that runs on Linux, you can only run it on a Sparc with an old version of the operating system.
There have been rumors from time to time about somebody trying to talk Sun into open-sourcing NeWS (and I send them a copy of my source code to help make that possible), but nothing has come of it. And there have been rumors of people planning on reimplementing NeWS from scratch, but don't hold your breath.
It would be much better to spend your time working on something new, since technology has advanced so much, and not many of the design desisions and tradeoffs made during the 1980's really apply any more.
I'm much happier with Python, SWIG, PyNumeric, Python Imaging Library, OpenGL, Zope, the XML libraries, and all the other great, free, well designed and supported Python modules that anyone can easily put together and easily do much more than NeWS ever dreamed of.
But if you really want to suffer needlessly from pointless complexity, backwards compatibility nightmares, and obsolete design compromises, you should just use Perl instead of trying to resurrect NeWS!
I'm currently working on recasting SimCity as a Python module, for educational uses. There's also the possibility of re-releasing multi player X11 SimCity for Linux as a commercial product, if I can figure out a good way to distribute and support it. But the Curse of the Loki Legacy makes it difficult to find investors who are willing to take the idea of a Linux game seriously.
Well, since you specifically mention Nielson by name and nobody else, I should point out that Jakob Nielson has pretty much ignored pie menus and has very little to say about them on his web site, but for a brief mention in his CHI'88 trip report. Maybe he talks about them in some of his seminars, but I've never heard of him evangelizing the use of pie menus or developing products with them.
On the other hand, Gordon Kurtenbach and Bill Buxton have done a huge amount of valuable emperical research and commercial product development with pie menus, gesture recognition and other topics. They designed the Alias|Wavefront Maya user interface, so it's no surprise that it uses marking menus (which they call their gestural modifications to pie menus).
And of course Ben Shneiderman also talks about pie menus a lot, and writes about them in his books.
Perl is like the castle built by the king in Monty Python and the Holy Grail, that fell over and sank into the swamp. So he built another one. And that fell over and sank into the swamp too. And then he built another and another, and they all fell over and sank into the swamp. Then finally, he built a really big one, and that burned down, fell over, and sank into the swamp.
-Don
Re:Steve Jobs thinks pie menus suck
on
Pie-Menus in Mozilla
·
· Score: 5, Informative
Under the NeWS window system that I was demonstrating to Jobs, it was straightforward to replace the global default linear menu class with pie menus, so all applications used pie menus.
The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.
One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.
For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.
The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.
Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).
For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.
Pie menus are useful in many but certainly not all situations. One major reason they haven't caught on is that most widely available window systems and toolkits don't offer pie menus as a default component, so it's orders of magnitude harder for developers to use pie menus than linear menus. And since most people are understaffed on a tight schedule, they use linear menus instead. I guess you would call that inertia.
Games are naturally one of the best ways to overcome this inertia, because it's acceptable to experiment with new user interface designs. Often, the whole user interface is part of the game, and designed and coded by hand instead of being built out of off-the-shelf components (like MFC or the Mac Toolbox).
The pie menus in The Sims required integrating the 2d overlay gui toolkit for the text labels, with the 3d character animation renderer for the head in the center, with real time image processing effects for the shadow. No off-the-shelf software could have possibly supported that, but it wasn't an issue since the entire user interface was custom designed and coded anyway.
Component software offers a way out of this catch-22 for other more normal applications than games, but it's only starting to catch on, and has its own host of problems and compatibility issues. Nobody can agree on which standards to use, and the standards that aren't obsolete and abandoned just keep changing faster than anyone can keep up.
It's impossible to design the perfect pie menu component for all applications, because every application has its own unique set of demands. But fortunately it's quite easy to code up special purpose custom pie menus for any particular application, since the algorithm is so simple, especially compared to gesture recognition.
But pie menus require the application designer to take a lot more care in arranging the menus, than just dumping a bunch of commands into linear menus. Menus with too many items are a bad idea in general, but pie menus with too many items are horrible. So if you're going to use pie menus with a large number of dynamically generated items, the user should be able to scroll through the menus in groups of 8 or so, instead of being faced with a giant pie menus with lots of extremely thin slices.
Pie menus are quite useful with systems that enable the user to easily customize their own menus. Maya is a great example of an extremely complex system with thousands of commands, that's used in many different specialized ideosynchratic ways by artist for hours on end.
So it's extremely important that the artists and tool developers be able to design and edit their own menus, so their own personal most commonly used commands are close at hand. Each user uses the same tool in extremely different ways, so they need to be able to customize the interface and build their own menus.
However, most users aren't trained in interface design, and it would not immediately occur to them to use an even number of items, or that left, right, up and down are faster to select than the diagonal directions. So it's good if the pie menu editor can automatically (unobtrusively and without animated paperclips) assist the user in designing easy-to-use pie menus.
For example, ActiveX pie menus support features like automatically raising the number of menu items up to 4 or 8 to keep them even, limiting the number of active items to 8 and allowing scrolling, and laying out the items in left-to-right, top-to-bottom reading order instead of circular clockwise or counterclockwise order. There are many other possibly useful features and heuristics to be discovered and implemented.
The most obviously beneficial applications of pie menus are the window manager and the browser, two applications that users struggle with constantly. Anything that can be done to make such commonly used interfaces quicker and easier will add up to a lot of saved effort over time.
In the late 80's, we developed a hypermedia browser and authoring tool named "HyperTies" which used pie menus and tabbed windows, at the University of Maryland Human Computer Interaction Lab, under the direction of Ben Shneiderman.
The authoring tool was based on UniPress Emacs with tabbed windows, implemented in NeWS. Emacs, the NeWS window manager and the HyperTIES browser all used pie menus. The browser had a pie menu with left and right for scrolling to the previous and next pages, up going to the index, and down to the table of contents. The pie menu on links let you get a defintion without following the link, follow the link in the current page, or open it up in another page (to the left or the right).
HyperTIES authors could define their own pie menus with links as well as scripts to control applets written in PostScript. For example, we had a text editor applet and a font selection pie menu that used the distance to smoothly select the font size. (This was years before Java, using Gosling's previous scripting language PostScript in NeWS, and his other previous scriptiong language MockLisp in Emacs).
The NeWS window manager with pie menus and tab windows was quite satisfying to use, so I redesigned and rewrote it several times in different versions of NeWS. Since Sun cancled NeWS it's not available any more. But here's a streaming Quicktime movie of a demo from around 1992, running on a SparcStation 2:
Pie Menu Tab Window Demo.
Slashdot Mirror
-Don
"E) Make
I don't know what you're doing to make using make so hard. Automake is tough, but for a single project, which you dont intend to be porting to other systems, a Makefile containing the targets, the sourcefiles, and the commands to compile each takes about 30-60 seconds of typing per target (especially with copy and paste and variables for compiler options), assuming you know how your source files fit together. If you want to do fancy stuff, buy a book. (See B. Not all wisdom is oral.)"
The very existence of make is a dire threat to our very American way of life.
You should be ashamed of yourself, apologizing for make. Sadam Hussein is more deserving of such an analinguistically adept rim job that your flattering words give to the daemon-spawn make. Does your mother's mother know you've sunken so low?
There's a challenging job opening in Iraq for a new Minister of Information, to which you should consider applying your considerable anal-oral wisdom and reality distortion skills.
America: Love it or leave it. And to love America means to reject all forms of Makefiles!
Pick a window, you're leaving.
-Don
http://catalog.com/hopkins/text/head.html
Would you rather smoke tobacco or marijuana?
And Oregon Graduate Institute's CSLU Toolkit extends Festival with an implementation of Sable: an XML format that lets you mark up text with arbitrary timing, pitch and volume envelopes.
An of course there's Dictionaraoke!
Main Entry: dictionaraoke Pronunciation: 'dik-sh&-"ner-A-O-ke Definition: Audio clips from online dictionaries sing the hits of yesterday and today. The fun of karaoke meets the word power of the dictionary.
-Don
We were hoping AT&T would do a better job than IBM at supporting their voice synthesizer. IBM pulled the Linux version of ViaVoice off the market without so much as a peep to their adoring fans on Slashdot, and wiped all mention of the Linux version from their web server. (Goggle isn't even allowed to cache it.) After IBM milked the slashdot linux fanboy publicity for all it was worth, they appearently didn't see any purpose in actually SUPPORTING the product -- so once their libraries stopped working against the latest Gnu/Linux libraries (happy birthday RMS!), they dropped their Linux voice synthesizer product like a hot potato instead of bothering to recompile it and issue an update.
So we hoped AT&T would show more comittment to the promises they made on their web site about their flagship voice synthesizer product, but...
Has anyone actually tried buying a single user copy of Natural Voices from AT&T? YOU CAN'T ANYMORE! They used to sell the synthesizer for workstations and voices for competitive prices (in the 100s of dollars range). So we bought a few voices to evaluate, and sent some simple technical questions into the email address they provided for support, never receiving a reply.
After several weeks they never answered any of our questions, but we decided to buy some more voices to evaluate anyway. But by then, AT&T had pulled the consumer single user version of Natural Voices off of the market (and it took weeks of phone tag to find that out because they don't give out "technical" information on the phone, and they never answer their email support address).
Now if you want to buy a Natural Voice from AT&T, you have to buy the server edition for tens of thousands of dollars. Had their support not absolutely sucked, it might have been worth us paying such a high price, but no way we'd ever consider going with AT&T, after they demonstrated such horrible unresponsive service.
Actually it's a good thing we didn't go with AT&T's voice synthesizer, because we need support for voice authoring tools, and AT&T is incompetent in that regard, since they refuse to give out technical information over the phone, and never answer their email. No support whatsoever. Zilch. Nada. Forget about it.
Fortunately we found some excellent open source software that works together (and whose authors are MUCH more responsive than IBM or AT&T): the Festival Speech Synthesis System, the FestVox voice authoring tools, the small fast Flite runtime speech engine, the Edinburgh Speech Tools, the CSLU speech tools, the OGI Festival tools, and the MBROLA Multilingual Speech Project. This is state of the art research software, where IBM and AT&T got their ideas.
The quality of the commercial voices comes more from throwing lots of time and money into the production process -- the commercial software is not any more advanced than the open source research projects -- in fact the research projects inspired the commercial products!
-A speech synthesizer user who's been jerked around by AT&T and IBM, and is now happy to have no other choice but to use excellent open source software.
From: Don Hopkins <don@brillig.umd.edu>
To: weiland@bensun.cs.umd.edu, plaisant@bensun.cs.umd.edu
Cc: don@brillig.umd.edu
Subject: NeWS front end
I've implemented a window with space for a control panel at the bottom and appropriate methods for handling it (no scroll bars), taught the formatter about .startcontrols and .endcontrols, and made classes of
control buttons, so now you can describe the control panel as a
storyboard file. (This seems to me to be a good idea.) I've also given
the formatter a good working over, and it's a lot nicer now. It will
not run off the bottom of the page any more. It makes sure there's
room before putting anything down. It handles the line height
correctly now. (i.e. before, if you were in a tall font, then did a
newline, then switch to a short font, the new line would be as tall as
the font you were in at the start of the line, even though there are
no words in that font on the line. Now the line will only be as tall
as the tallest text or displayable actually drawn on it. It will put a
piece of text or graphics onto the next line if it won't fit on the
current line, unless the cursor is at the beginning of the line (so no
unnecessary blank lines). It will put it on the next page if it won't
fit on the current page, unless the cursor is at the top of the page
(so no unnecessary blank pages). While it's laying out the stuff and
building the display list, it draws rectangles on the page to show
where it's at. (i.e. the bounding box of the last line it completed)
When it finishes each page, it erase the rectangles and draws the
stuff it just layed down. It handles damage to the pages correctly
now, by repainting them, so it's not necessary to retain the images of
obscured canvases. (They will be repainted from their display list
when exposed.) So it should run OK in color, but that still needs to
be tested. When you format a multi-page document, you see the first
page being layed out (rectangles), and when it's done, it's painted
and the touchables become active. At the same time, the rest of the
pages are being formatted underneath the first page on top. You can
flip through the pages and touch the touchables while the formatting
is going on. (No callbacks to the client can happen till it's done
formatting, though.)
Do you want me to write a real storyboard parser? I'm still using Forth right now.
Some more things I still need to do: Magic back and next buttons that dissappear when they're not applicable. Title and page number in the frame label. The formatter should aggregate adjacent strings on a line into one.
-Don
-Don
"Consider whether chewing on glass might have more of a payoff than what you're about to go through."
- Jamie Zawinski, quoted in The X-Windows Disaster
One of the most widespread contemporary uses of Forth is the Open Firmware boot ROMs used in Suns, Macs and even Linux. It's even defined by IEEE standard 1275-1994.
It was based on Langston and Perry's Forth83, and developed by Mitch Bradley at Sun, who is a major Forth guru and hardware guy. When you hit L1-A on a Sun, it dumps you into the Forth boot monitor, which let you do all kinds of things to the hardware and nvram configuration.
The point to having a cross platform bytecode dialect of Forth in firmware, is so hardware devices can have drivers, diagnostics and configuration interfaces in ROM that will execute on any system, no matter what the processor. That was implemented long before Java was ever invented.
-Don
In standard Forth-83, the joke would be:
forth ?use if unemployed then
But in your case:
forth ?know not if up shut then
Isn't that how the Cat Detector Van in the Monty Python skit works? It picks up on the local oscilators in your unlicensed cat.
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool
-Don
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool.6
Pizzatool used the NeWSPrint PostScript to Fax server that Sun was running for a while.
I believe Ross Thompson at Adobe wrote a shell script called "burrito" a year or so later. It faxed orders to La Costania, but it was a command line tool without a graphical user interface and PostScript preview window like PizzaTool. (You could actually spin the pizza preview with the mouse.)
http://www.netfunny.com/rhf/jokes/94q1/burritopgm. html
The first time I faxed a PostScript picture of a pizza to Tony and Alba's, they were quite confused and didn't know what to think, because I had neglected to list the toppings out as text, they were just rendered graphically. So they had to look at the black and white faxed rendering of a pizza, to decypher which toppings I ordered. I took a bug report and fixed the problem by adding the text so they could figure out the subsequent orders.
Here's a video that includes a demo of the spinning pizza in pizzatool (as well as lots of other weird inexplicable stuff)...
Streaming: HyperLook SimCity Demo
Download: HyperLook SimCity Demo
Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.
-Don
They are provably faster and more reliable than linear menus, and you can run this experiment and prove it to yourself if you don't believe me or any of the research papers that have been published over the years:
Fasteroids is a free game that lets you compare pie menus with linear menus. Take the pie menu challange! Fasteroids tracks your selection speed and error rate, so you can compare pie menus and linear menus for yourself.
-Don
Adaptive user interfaces have their own problems: instability, unpredictability, violating the principle of least astonishment.
Generally it's not a good idea to change user interface properties like the slice width, direction or order out from under the user, because that interferes with the training effect of muscle memory. It's much more important that the user be able to learn the menus and mouse-ahead reliably, than having menus automatically adapt to the user's usage patterns.
Computers are notoriously stupid and often make the wrong decisions about adapting, introducing changes that hurt more than they help. Adaptability is really an AI problem.
Certain directions (the primary ones up/down/left/right, depending on the input device and handedness of the user) are easier to select than others (like the diagonals). So it's a good idea for the menu designer to use those for the most important items. But it depends heavily on the meanings and functions of them items and the usage patterns of the users. And the computer is incapable of making such high level decisions and aesthetic judgement calls.
Giving the user the ability to easily edit the menus themselves is a much more reasonable approach than automatically and unpredictably rearranging the menu behind the scenes without the consent of the user (the so called "adaptive" approach).
-Don
There have been rumors from time to time about somebody trying to talk Sun into open-sourcing NeWS (and I send them a copy of my source code to help make that possible), but nothing has come of it. And there have been rumors of people planning on reimplementing NeWS from scratch, but don't hold your breath.
It would be much better to spend your time working on something new, since technology has advanced so much, and not many of the design desisions and tradeoffs made during the 1980's really apply any more.
I'm much happier with Python, SWIG, PyNumeric, Python Imaging Library, OpenGL, Zope, the XML libraries, and all the other great, free, well designed and supported Python modules that anyone can easily put together and easily do much more than NeWS ever dreamed of.
But if you really want to suffer needlessly from pointless complexity, backwards compatibility nightmares, and obsolete design compromises, you should just use Perl instead of trying to resurrect NeWS!
-Don
-Don
Streaming: X11 SimCity Demo
Download: X11 SimCity Demo
I'm currently working on recasting SimCity as a Python module, for educational uses. There's also the possibility of re-releasing multi player X11 SimCity for Linux as a commercial product, if I can figure out a good way to distribute and support it. But the Curse of the Loki Legacy makes it difficult to find investors who are willing to take the idea of a Linux game seriously.
Streaming: Linux SimCityNet Demo
Download: Linux SimCityNet Demo
-Don
On the other hand, Gordon Kurtenbach and Bill Buxton have done a huge amount of valuable emperical research and commercial product development with pie menus, gesture recognition and other topics. They designed the Alias|Wavefront Maya user interface, so it's no surprise that it uses marking menus (which they call their gestural modifications to pie menus).
And of course Ben Shneiderman also talks about pie menus a lot, and writes about them in his books.
-Don
-Don
The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.
One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.
For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.
The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.
I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.
Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).
For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.
-Don
Streaming: Pie Menu Tab Window Demo.
Download: Pie Menu Tab Window Demo.
Here are some earlier demos of tab windows and pie menus in UniPress Emacs and HyperTIES at the University of Maryland HCIL.
Streaming: NeMACS (NeWS Emacs) Demo
Download: NeMACS (NeWS Emacs) Demo
This is a HyperTIES demo, showing embeded graphical links with pop-up images.
Streaming: HyperTIES Demo
Download: HyperTIES Demo
Here's just the pie menus from "All The Widgets", CHI'90 Special Isssue #57 ACM SIGGRAPH Video Review. Tape produced and narrated by Brad Meyers.
Streaming: Just The Pie Menus from All The Widgets
Download: Just The Pie Menus from All The Widgets
-Don
Games are naturally one of the best ways to overcome this inertia, because it's acceptable to experiment with new user interface designs. Often, the whole user interface is part of the game, and designed and coded by hand instead of being built out of off-the-shelf components (like MFC or the Mac Toolbox).
The pie menus in The Sims required integrating the 2d overlay gui toolkit for the text labels, with the 3d character animation renderer for the head in the center, with real time image processing effects for the shadow. No off-the-shelf software could have possibly supported that, but it wasn't an issue since the entire user interface was custom designed and coded anyway.
Component software offers a way out of this catch-22 for other more normal applications than games, but it's only starting to catch on, and has its own host of problems and compatibility issues. Nobody can agree on which standards to use, and the standards that aren't obsolete and abandoned just keep changing faster than anyone can keep up.
It's impossible to design the perfect pie menu component for all applications, because every application has its own unique set of demands. But fortunately it's quite easy to code up special purpose custom pie menus for any particular application, since the algorithm is so simple, especially compared to gesture recognition.
But pie menus require the application designer to take a lot more care in arranging the menus, than just dumping a bunch of commands into linear menus. Menus with too many items are a bad idea in general, but pie menus with too many items are horrible. So if you're going to use pie menus with a large number of dynamically generated items, the user should be able to scroll through the menus in groups of 8 or so, instead of being faced with a giant pie menus with lots of extremely thin slices.
Pie menus are quite useful with systems that enable the user to easily customize their own menus. Maya is a great example of an extremely complex system with thousands of commands, that's used in many different specialized ideosynchratic ways by artist for hours on end.
So it's extremely important that the artists and tool developers be able to design and edit their own menus, so their own personal most commonly used commands are close at hand. Each user uses the same tool in extremely different ways, so they need to be able to customize the interface and build their own menus.
However, most users aren't trained in interface design, and it would not immediately occur to them to use an even number of items, or that left, right, up and down are faster to select than the diagonal directions. So it's good if the pie menu editor can automatically (unobtrusively and without animated paperclips) assist the user in designing easy-to-use pie menus.
For example, ActiveX pie menus support features like automatically raising the number of menu items up to 4 or 8 to keep them even, limiting the number of active items to 8 and allowing scrolling, and laying out the items in left-to-right, top-to-bottom reading order instead of circular clockwise or counterclockwise order. There are many other possibly useful features and heuristics to be discovered and implemented.
The most obviously beneficial applications of pie menus are the window manager and the browser, two applications that users struggle with constantly. Anything that can be done to make such commonly used interfaces quicker and easier will add up to a lot of saved effort over time.
In the late 80's, we developed a hypermedia browser and authoring tool named "HyperTies" which used pie menus and tabbed windows, at the University of Maryland Human Computer Interaction Lab, under the direction of Ben Shneiderman.
The authoring tool was based on UniPress Emacs with tabbed windows, implemented in NeWS. Emacs, the NeWS window manager and the HyperTIES browser all used pie menus. The browser had a pie menu with left and right for scrolling to the previous and next pages, up going to the index, and down to the table of contents. The pie menu on links let you get a defintion without following the link, follow the link in the current page, or open it up in another page (to the left or the right).
HyperTIES authors could define their own pie menus with links as well as scripts to control applets written in PostScript. For example, we had a text editor applet and a font selection pie menu that used the distance to smoothly select the font size. (This was years before Java, using Gosling's previous scripting language PostScript in NeWS, and his other previous scriptiong language MockLisp in Emacs).
The NeWS window manager with pie menus and tab windows was quite satisfying to use, so I redesigned and rewrote it several times in different versions of NeWS. Since Sun cancled NeWS it's not available any more. But here's a streaming Quicktime movie of a demo from around 1992, running on a SparcStation 2: Pie Menu Tab Window Demo.
-Don