Why isn't your user name visible? How did you do that???
914 karma · joined September 12, 2010
As a matter of fact, by deploying one of those the beginning of the macro, one in the middle, and one at the end, you can set up what's called a "trifor(;;);ce field", an anti-anti-pattern that is documented on the c2 wiki thusly:
The trifor(;;);ce has the power to grant the wish of whomever touches it, and molds the Sacred Realm to reflect that person's heart. The trifor(;;);ce does not discriminate between "good" or "evil". However, if a person without an equal balance of power, wisdom, and courage makes a wish, the trifor(;;);ce will split into its three separate parts: the piece that best personifies the wish-maker will be the only piece to remain in hand, whilst the other two will take residence in whosoever most personifies them. Reassembly is then required for such a person's wish to be granted, but does not exclude another from making the attempt.
No, I'm just joking and making shit up. Don't anyone ever do that! As bitchy and pedantic as gcc and clang are about other things, I'm disappointed they don't complain about that.
And that fact that this bug and terrible coding style was in the publicly available source code for so long totally disproves ESR's "many eyes make all bugs shallow" myth. Thanks for the false sense of security, Eric. The chickens have come home to roost again.
If "many eyes make all bugs shallow" were true, somebody would have raised the flag "Hey everybody, these Bozos are actually omitting brackets in their SSL code! Somebody could carelessly insert a statement and accidentally (or maliciously) introduce a hard to see bug some day!"
Hardly anybody actually bothers to read code in the real world. So there aren't "many" eyes, and even if there were, many bugs aren't shallow even to expert eyes, and "all" bugs will never be shallow to most eyes.
That's why it's important to pay competent security professionals to actually take the time and effort to audit source code, which is difficult work that requires much time and effort that takes them away from other valuable, high paying, less tedious and mind numbing work.
Whoever wrote that code even before it had the bug was an incompetent cowboy hotshot who wanted to show off how pedantically he knew and could surf the nuances of syntax and optimize the code to have the smallest source file size by penny pinching brackets.
"ALWAYS USE BRACKETS" is one of the oldest and wisest rules in the book, and this shows why. Anyone who actually writes security related code like that, blatantly ignoring important coding practices in the name of "aesthetic beauty" or however they rationalize omitting brackets, should be fired.
I bet they're the same cowboys who fanatically prosthelytize JavaScript automatic semicolon insertion too, because that's another outlet for their obsession with showing off how clever they are to write code that requires them to deeply understand and consider every nuance of the syntax at every keystroke, instead of facing the fact that they or somebody who comes later might actually make a mistake, and coding defensively.
Maybe they really are fucking geniuses who never make mistakes, but that's not true about everyone else who has to read and modify the code.
Apple should go through all their code and fix it, and dock the salary of anyone caught not using brackets.
I'll bet he remembers, and tells people about your look and feel that he saw and felt!
For example, TomTom had a big emotional investment in some 1990's-style proprietary remote procedure call protocol that one of the automotive companies they bought had developed. It had its own interface definition language and rpc stub compiler, which seemed revolutionary in 1988 when some clever student came up with the same idea to make it easier to write C wrappers for SunRPC protocols so you didn't have to write them by hand.
More rational heads were pushing to just use modern off-the-shelf technologies like http/rest/json/etc, but the jobs of some people in some department depended on them being perceived as having been doing productive work on their own proprietary message bus for the past three years or so, and that was what they delivered, so that was what they were damn well going to use.
Smartphones are a huge threat to companies that make their own little boxes that are hard to convince people who have smartphones to buy, so they weren't exactly enthusiastic about embracing and supporting smartphones and tablets.
When a company that operates at glacial automotive development speeds has been working on their own proprietary solution to a problem that modern technology has made trivial to solve in a standard way, they're often reluctant to throw out the proprietary solution they've developed, and just use standard off-the-shelf protocols that would enable third party developers to plug into their systems and make their expensive products superfluous.
You may think it's a great idea for your car to simply be running a web server on a TCP/IP network that you can just connect to with bluetooth or wifi, but that's a terrifying concept to companies that are trying to lock you into systems they developed years or decades ago...
Even after they finally bit the bullet and decided to use WebKit in the TomTom device to implement the user interface, they still insisted on plugging their silly RPC protocol into the web browser via an old school NSAPI plug-in adaptor to talk to their fancy proprietary protocol library, instead of just talking http between everything. They wouldn't listen to reason, or technological arguments, because the political arguments had already been made and the decisions had been set in stone that they were going to use their proprietary technology for a long time. And no way were they ever going to offer third party developers access to their silly RPC protocol, which they were clinging to because they actually perceived open standards as a threat, not a blessing. People's jobs depended on it!
They knew and gave lip service to the idea that they had to think "out of the box" to survive against the onslaught of google and cheap android phones, but hell if they were going to go through that particular door, like trying to force a cat out a window it refuses to go through.
You may recall how TomTom for WinCE used to have an SDK that let you hook into the TomTom Navigator app in a few unsatisfying ways -- it was extremely sub-optimal: you would write files out into a directory and stick your thumb up your ass until the app noticed the file, read it, did something, and wrote another file with a reply, that you had to keep polling for. Instead of developing that into a real API for integrating with TomTom Navigator, they just kind of took it out back and suffocated it with a pillow -- a step in the wrong direction if you ask me! It would have been so straightforward to simply expose an http service, but that dog won't hunt in a company like that.
Gordon Kurtenbach and Bill Buxton did an experiment that varied the number of menu items and measured the selection time and error rate. They expected the selection time to be monotonically increasing as they added more items. To their surprise, that was almost true, except for the transition from seven to eight items. It was quicker to select from an eight item menu, then from a seven item menu!
That, I believe, was because of the effect of the cognitive bottleneck of associating the items with which direction to move, not the physical difficulty of moving in those directions. While the slices of the seven item menus were wider and had more area than the slices of the eight item menus, and Fitts' Law would predict that seven item menus were faster than eight item menus, Fitts' Law does not take into account the time it takes for users to map their intended command to the direction of that command, and how the mental framework in which users remember and relate the directions to each other affects selection time.
Eight item menus have all of their items in well known directions, each of which is associated with a very familiar concept, which come in nice pairs, and the pairs come in convenient orthogonal groups, like up/down, left/right, vertical/horizontal/diagonal, like compass directions.
Twelve item menus like a clock face also work well, especially for circular sets of items like hours, months, zodiac signs, etc. But the effect going from 11 to 12 is not as dramatic as from 7 to 8. But still the 12 item menu has a nice familiar aesthetically pleasing cognitive framework (including opposite and orthogonal pairs, first tier vertical/horizontal axes and second tier in-betweens) that you can often exploit, depending on the content.
Three item menus are still slightly faster than four item menus, because the effect of the proportional difference in target area overwhelms the difference in the number of items, and two of three triangular directions are well known concepts that are pretty easy to remember, compared to six of seven directions.
An eight item menu optimally exploits that effect, while a seven item is unfortunately sub-optimal with mostly difficult to remember directions. There's no word or concept in the English language for six out of seven of those directions -- they're all just kind of slanted differently, similar to but not quite like the well known compass directions, and there are no nice symmetries, opposite or orthogonal groupings to exploit, by arranging complementary items in opposite directions, independent pairs along orthogonal axes, etc.
So if you're designing a pie menu with seven items (or even eleven), it's better to just throw another item in to bring it up to eight (or twelve)! I gave an example in the DDJ article of a "seven days a week" menu with an additional "today" item thrown in at the bottom to bring it up to eight, with the weekend and today in the lower part of the menu, and Wednesday at the top. See, I don't even have to link to a picture or enumerate every item for you to easily visualize and remember it!
There are both good and bad reasons for this. But the important point is that automotive interfaces are designed to be built into cars at the factory, and used for many years without requiring any updates. Even if updates are possible, most people don't get them. So it's a completely different mindset and approach and time scale than people from the Silicon Valley dot-com startup industry have.
Another factor is that the devices built into cars have a very long design and production lead time, and by the time the car comes out, the built in hardware and software is already quite obsolete compared to the smartphone the driver probably owns.
Factoring the problem out of the car to run in a smartphone or tablet itself also has its own frustrating problems, because when you're designing an automotive computer system, you can't predict what kind of technology and standards will be available or popular by the time it ships.
It's a very difficult problem space, and the stakes are extremely high, not just financially, but also because cars are weapons of mass destruction that kill more people and destroy more property than all terrorists combined could possibly dream of.
SimCity has a tool pallet of various building and editing tools, which are related to each other in various ways, and have different costs, functions and properties. I tried to arrange them into a set of submenus that made those relationships and differences more obvious and easier to learn. I also arranged the static tool palette on the screen to reflect the layout of the pie menus and submenus, to serve as a kind of map to the pie menus (which foreshadowed the spatial map design I explored with Method of Loci, described in another posting).
Here is a screen dump of the multi player version of SimCity running on a Sun workstation on TCL/Tk/X11: http://www.donhopkins.com/home/catalog/simcity/SimCity-Sun.g...
The top level menu includes: magic marker and eraser (for drawing on the map), roads and rails, power lines and a bulldozer, and submenus for common zones and bigger buildings. The zone submenu includes residential, commercial and industrial zones, police and fire stations, and a query tool. The building submenu includes a stadium, park and seaport, coal and nuclear power plants, and an airport.
As you can see, the size of the icon reflects the cost of the tool. The borders of the icons are color coded to reflect the cursor you see on the map that shows where the tool will affect. (That was useful for multi player mode, so you could see which tools the other players had selected, so the tool palette served as a legend for the cursors on the screen.) And the tool palette looks kind of like a totem pole, which is vertically asymmetrical, differentiating different kinds of tools and making them look unique, and horizontally symmetrical, reflecting pairs of similar tools and making it look aesthetically pleasing.
If all the tools were the same sized squares arranged in a regular grid, it would be much harder to differentiate them and quickly select the one you want. Instead, they're arranged more like a bouquet of unique flowers that each have their own special features that make them easily recognizable and memorable, while telling you something about themselves.
Designing user interfaces this way is a artistic balancing act, highly dependent on the set of commands, and requiring a lot of iteration, testing and measurement, as well as willingness to explore and experiment with many different alternatives. It is not easy, and there is never a best solution, or even always a good one. It's not something you can expect end-users to be able to do with their own custom built menus. But it's worth the effort to try, and I think it's also worth the effort to train designers and even users to promote a literacy in interface design.
One idea I've had is to develop a game called "PieCraft", that has user-editable pie menus that are first-order in-game player craftable artifacts. World of Warcraft and its rich ecosystem of user interface extensions supports a wide range of player customizable user interfaces, because there are so many different commands, spells, buffs, weapons, armor, etc, and each role of each character of each player requires a totally different set of them in different situations. The more casual MMPORG "Glitch" had bags that users could arrange in hierarchies and put their items inside, which were surfaced on the user interface as buttons they could press and objects they could drag in and out of the world and other bags. How well you arrange your items in WoW and Glitch had a significant effect on gameplay.
PieCraft could take this further, to train players in user interface design literacy (much like "Code Hero" aims to train players in computer programming). You could find empty or pre-populated pie menus in the world, pick them up and make them your own, and edit them by moving items around, putting them inside of other menus, and modifying them as you leveled up and earned more powerful menu editing skills and resources. The capacity and layout and allowed contents of some menus could be restricted, to constrain the ways you used them, forcing you to figure out which were your most important items, and giving them front row seats so they were easiest to select.
To put further pressure on players to design efficient menus, your menus could be vulnerable to attack from warriors and theft from pickpockets while they were popped up, and only be able to take a limited amount of damage, before they would break open and spill their contents out all over the world! Then you (and your enemies) would scramble to pick up all the pieces, and you would be compelled to arrange your most important items so you could find and select them as quickly and easily as possible, so you could "mouse ahead" swiftly during combat and in crowded public settings, to avoid damage from attack and loss from thieves.
It's best if the menus can provide real time in-world feedback, like applying the effect of the interaction immediately as the menu is tracking. That makes it feel more like immersive "direct manipulation" than indirect "menu selection". It's important that pie menus support "reselection", which makes them much more forgiving and differentiates them from traditional blind gesture recognition, so you at any time during tracking you can change the selection to any item you desire.
Pie menus completely saturate the entire possible gesture space with usable and accessible commands: there is no such thing as a syntax error, and you can always correct any gesture to select what you want, no matter how bad it started out, or cancel the menu, by moving around to the desired item or back to the center to cancel.
Handwriting and gesture recognition does not have this property, and it can be quite frustrating because you can't correct or cancel mistakes, and dangerous because mistakes can be misinterpreted as the wrong command. Most gestures are syntax errors. Blind gesture recognition doesn't have a good way to prompt and train you with the possible gestures, which only cover a tiny fraction of the possible gesture space. All the rest of the space of possible gestures is wasted, and interpreted as a syntax error (or worse, misinterpreted as the wrong gesture), instead of enabling the user to correct mistakes and reselect different gestures.
Even "fuzzy matching" of gestures trades off gestural precision with making it even harder to cancel or correct a gesture, without accidentally being misinterpreted as the wrong gesture. That's not the kind of an interface you would want to use in a mission critical application such as a car or airplane.
Another way to reframe the gestural, self revealing and reselectable qualities of pie menus is as navigation through a map, as opposed to climbing up a hierarchical menu tree. Instead of laboriously climbing up a tree of submenus, you simply navigate around a map of "sibmenus" -- sibling menus that you can easily move back and forth between by moving in opposite directions.
This demo of an iPhone app I developed called "iLoci" demonstrates the idea, enabling users to create their own memorable maps of "locations" instead of "menus", which they can edit by dragging around, that are related to each other by two-way reversible links. It exploits the "Method of Loci," an ancient memorization technique from the time before iPhones when people had to use their own brains to remember things, in order to leverage your spatial navigation memory and make it easy to learn your way around. http://vimeo.com/2419009
https://en.wikipedia.org/wiki/Method_of_loci "The Method of loci (plural of Latin locus for place or location), also called the memory palace, is a mnemonic device introduced in ancient Roman and Greek rhetorical treatises (in the anonymous Rhetorica ad Herennium, Cicero's De Oratore, and Quintilian's Institutio Oratoria). In basic terms, it is a method of memory enhancement which uses visualization to organize and recall information. Many memory contest champions claim to use this technique to recall faces, digits, and lists of words. These champions’ successes have little to do with brain structure or intelligence, but more to do with their technique of using regions of their brain that have to do with spatial learning."
I like the idea of moving away from hierarchal menu navigation, towards spatial map navigation. It elegantly addresses the problem of personalized user created menus, by making linking and unlinking locations as easy as dragging and dropping objects around and bumping them together to connect and disconnect them. (Compare that to the complexity of a tree or outline editor, which doesn't make the directions explicit.) And it eliminates the need to a special command to move back up in the menu hierarchy, by guaranteeing that every navigation is obviously reversible by moving in the opposite direction. I believe maps are a lot more natural and easier for people to remember than hierarchies, and the interface naturally exploits "mouse ahead" (or "swipe ahead") and is obviously self revealing.
Here is another video demonstrating a prototype exploring this interface that I developed in Unity3D for Will Wright. It shows both an "iLoci" map editing interface, as well as traditional pop-up pie menus using "pull-out" distance parameters with real time in-world feedback to preview the effect of the selection (plus it also has cellular automata, at Will's request!): http://www.DonHopkins.com/home/StupidFunClub/MediaGraphDemo1...
An Empirical Comparison of Pie vs. Linear Menus, Jack Callahan, Don Hopkins, Mark Weiser and Ben Shneiderman. Computer Science Department University of Maryland College Park, Maryland 20742. Presented at ACM CHI'88 Conference, Washington DC, 1988. http://www.donhopkins.com/drupal/node/100
I've applied pie menus to various applications including tools like window managers and text editors, and games like SimCity and The Sims, which uses pie menus for controlling the lives of the simulated people. https://en.wikipedia.org/wiki/Pie_menu
Since the direction of motion, which selects the pie menu item, is independent from the distance of motion, you can use the distance as a parameter. Here's a demo and an article showing various kinds of pie menus I've developed:
Pie menus from "All The Widgets" CHI'90 Special Isssue #57 ACM SIGGRAPH Video Review. Including Doug Engelbart's NLS demo and the credits. Tape produced by and narrated by Brad Meyers. Research performed under the direction of Mark Weiser and Ben Shneiderman. Pie menus developed and demonstrated by Don Hopkins. http://www.donhopkins.com/home/movies/AllTheWidgets.mov
The Design and Implementation of Pie Menus -- Dr. Dobb's Journal, Dec. 1991. There're Fast, Easy, and Self-Revealing. Copyright (C) 1991 by Don Hopkins. Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue. http://www.donhopkins.com/drupal/node/98
Here's a more modern implementation in Unity3D: http://www.youtube.com/watch?v=sMN1LQ7qx9g
The multi finger interface is obviously a very nice touch that this interface brings to the tablet (if you'll pardon the pun ;). I like to call touch screen pie menus "finger pies", in a nod to the Liverpool slang term from the Beatles' "Penny Lane": "a four of fish and finger pie". ;) http://www.songfacts.com/detail.php?id=115
"ConnectedTV" is a finger controlled Palm app that David Levitt and I developed more than a decade ago for the Palm (without multitouch of course): a handheld personalized TV guide integrated with a universal remote control, which you could reliably operate with your fingers instead of the stylus that most Palm apps required at the time. Here is a review than mentions the single handed finger touching and stroking interface:
ConnectedTV: TV Guide + Remote Control, Geoff Walker, 2/2/02. http://www.pencomputing.com/palm/Pen44/connectedTV.html
"On the Palm, the application user interface is simple. The application checks the clock on the Palm and displays the names of all the TV programs for the current 15-minute window. The program buttons are large enough to easily hit with your finger. For easy identification of programs that are about to start, one corner of the button is clipped. To tune the TV to a selected program, you just tap the button. To display more information about a program (i.e., the blurb from the guide), you do a downstroke on the button. The downstroke is a result of the program menu buttons being implemented via "pie menus" (see www.piemenu.com), which makes it very easy to use the application with one hand."
"For instant access to frequently used functions, the application remaps the Palm’s hardware buttons to Power, Mute, Volume Up/Down, Next and Back. At initial release, the program will include support for TiVo and some brands & models of VCR, as well as the ability to program it for other brands. Management of "Favorites" (e.g., flagging favorite programs with their first run/rerun status) is planned but may not make the first release."
Most Palm apps required a stylus to operate, because their interfaces required a lot of precision and visual feedback. But it was quite easy to accidentally lose your stylus in the couch cushions in the dark living room, so pie menus made it possible to control the Palm in a dark room with your fingers, which was unusual at the time (long before the iPhone).
ConnectedTV used big multi-purpose buttons that you could reliably operate with your finger, supporting up to five complementary functions for taps and strokes up, down left and right, with immediate audio and visual feedback during tracking.
The directional strokes worked very nicely with complementary sets of commands that remote controls tend to use like changing volume up and down, changing channels next and previous, liking and ignoring programs, paging up and down, moving forwards and backwards in time, etc.
David Levitt wrote up a summary of how it worked:
iPhone Lovefest - How Don and I Invented Stroking vs Poking https://www.facebook.com/note.php?note_id=106220169912
On a recent Sunday, journalist Steven Levy hosted an iPhone Lovefest at Sylvia Paull's Berkeley Salon, and more than a hundred of us showed up. I realized some of us had quietly helped invent something historic, and I spoke briefly about it that day, but first I did a little demo.
More than a dozen developers brought iPhone applications to show off; a camera and projector showed the crowd each little screen. I went up last, commenting that with its sensor, the iPhone had the same motion sensitivity as the Wii's legendary game controller, and tapped mine on the table. As it tumbled from my hand there was a nasty cracking noise and the audience saw this: Gasps and shrieks were soon followed by laughter, a woman shouting "I have version 1.0 of that!", and relieved applause. I explained that the iPhone application draft I was showing was called iBustedIt, the cracking sound and image were triggered by motion, and Levity Novelty aimed to make it available by April Fool's Day. Only it turns out Apple considers this kind of trick an impersonation of its fine software and doesn't allow it in the App Store - so my apologies to those of you who planned to trick and shock your friends with iBustedIt. (Eventually I learned Ms "I have 1.0!" is Ann Greenberg, whose iPhone glass is actually cracked that way and still works fine.)
As the laughs died down, I noted how easily we can miss major technology transitions, not realizing what's actually new. When I developed software for the Palm in 2002, every handheld application required a stylus: to operate the tiny on-screen buttons you had to use both hands and poke them with a little stick. Remember?
Back when my old company ConnectedMedia created ConnectedTV - a Palm app showing personal TV listings that let you change the TV channel by touching the screen - I considered the poking interface unacceptable. Requiring a stylus would mean a nerds-only experience no consumer could love. Unless you could operate it with a thumb - and with one hand - it could never compete with a remote control.
So the on-screen buttons had to be much larger, with each screen elegant and simple. Only, most screen space was needed for TV listings and show descriptions. My ingenious friend and partner Don Hopkins realized that we could repurpose the Palm OS screen 'stroke' detection capability - previously used only as a way of entering characters - into a kind of short cut: if you stroked the button, its label would change with a click, and then if you lifted your finger it would perform the function shown. Since you could easily stroke up|down|left|right, we could stash up to 4 helpful shortcuts under each finger-sized screen button.
To prevent accidental channel changes, we also required you to stroke down on the TV show name or description to watch it. It worked perfectly. Of course, this is a predecessor of the swipe today's iPhone needs so it can't be unlocked accidentally as you carry it.
Users adored ConnectedTV, calling it "addictive". Handheld Computing called it "one of the most impressive Palm OS applications we've ever seen." It was more responsive, more personalized (stroke to set a Favorite show), and less obtrusive for browsing than the TV's on-screen guide.
Sony paid us to make custom 'skins' for their sweet CLIÉ line of Palms for cable TV trade shows, and then offered to bundle ConnectedTV with the CLIÉs, pre-installed. However, soon Sony Japan dropped Palm OS and discontinued the whole CLIÉ line. Still, our stylus-free interface had provided a peek at the strokable handheld future.
Stroke replaces Poke Just a few years later, no popular handheld device uses a stylus. The iPhone has expanded the idea further to support animated scrolling and multi-touch pinching.
Is there really such a big difference between poking with a stick - occupying both hands - versus being able to stroke, rub, caress with a finger, and even pinch? Um, ask your mate. Such quiet GUI software innovations help us fully enjoy, literally embrace and yes, love our technology.
That's funny, since when the iPhone first came out, Apple claimed there wasn't gonna be a native SDK, and developers would just write all their apps in HTML.