Or part 18,274 of Programmers Are Incompetent Morons. As if the fact that 90% of all software projects fail weren't damning enough. Never mind the damning fact that C++ and Smalltalk-- (aka Java) are popular.
Let's look at the context menu of a thumbnailed video element in Opera. (And for all you Firefox fanboys, I have only this to say - shut the fuck up.)
- Open
- Open In New Tab
- Open In Background Tab
---------- - Open In New Window
- Open In Background Window
---------- - Bookmark Link
- Copy Link Address
- Save Linked Content As...
- Save to Download Folder
---------- - Open Image
- Reload Image
- Copy Image Address
---------- - Save Image
- Copy Image
---------- - Inspect Element
- Element Properties
That's 16 different functions in 6 different sections.
The last two elements are only there for purposes of debugging. Debugging is a meta-level operation and shouldn't be confused in the UI with domain-level operations like display. What kind of retarded moron puts programmer debugging functions at the same level and in the same mode as everyday user display functionality? Answer: an incompetent retarded moron.
Save Image and Copy Image simply shouldn't exist. The definition of 'element' includes the property indivisible. A web browser displays elements, it doesn't provide tools to smash atoms into quarks. That's what a particle accelerator is for.
The proper place for this functionality is when the element (the video in this case) has the user's entire attention (because it is zoomed into). Then it becomes more obvious that the element is actually composed of subatomic parts. Then it becomes proper to display those subparts as separate elements.
For the same reason, Open Image and Copy Image Address shouldn't be there. Reload Image is a technical matter and should be done automatically as resources are available, not manually. Handling these pesky details is what the web browser is FOR in the first place.
Bookmark Link shouldn't be there. Bookmark page is quite sufficient, and has better functionality. And in design, any and all extra functions should never exist. Each function carries a cost for the user that has to learn it. "Extra" functions thus carry a cost penalty and no benefit. For every user that claims there's a benefit, there's 99 users that get shafted with the penalty.
Save Linked Content As... and Save to Download Folder both suck ass. They should be replaced by the simple GRAB. Not Grab in the sense of Drag and Drop which is unusable ridiculous shit. But in the sense of PickUp.
The exact same way as grabbing something with your hand doesn't stop you from moving & navigating, or grabbing more stuff, or seeing what you've grabbed. So Save Linked Content As... ought to be simply Grab. And there should always be visible someplace in the UI, someplace discreet and out of the way, that you can see what you've grabbed, instantly.
Save to Download Folder ought to be a custom, user-defined, function in the menu (since menus ought to be editable by the user) named Grab And Drop To [Location 1]. Obviously there should be Grab And Drop To [Location 2], [3], [4] and so on. 4 is a convenient number. Needless to say [Location 1] should actually say the name of the folder you're dropping things to. Not just "Download folder" whatever the fuck that is.
Copy Link Address also should not exist. The reason why is because it's a C++ ism. In Smalltalk, it's impossible to get the memory address of an object. And who the fuck would want to! In C++ you can and you play all sorts of nasty games like "pointer arithmetic". URLs are basically human-readable pointers. Or human-readable capabilities. Needless to say, they should be treated with caution and specially since they break the paradigm. Flinging them around everywhere is about as distasteful as flinging around excrement.
Let me emphasize for the slow-witted: URLs are meta-level and outside the web object paradigm.
The difference between Open In New Window and Open In New Background Window simply should not exist. This is what's called "user choice" and as all enlightened designers know, CHOICES ARE BAD. Choices means you're imposing a cost on users to decide what they want. Most of the time, the user won't give a fuck between Choice A or Near Identical Choice B, but you're still telling them "STOP, You. Must. Decide. Between. Green Hats. And. Red Hats."
Guess what? The users don't want to do that. They want to get on with their work. They want to make MEANINGFUL CHOICES ONLY. Not bullshit choices between brand names. Do you know why people are loyal to their brands? Because they refuse to make the same arbitrary choices over and over again.
Not only that, but the entire Open In New Window function simply should not exist. What there should be instead is a cheap and easy way to 1) grab the item, 2) create a new window (ctrl-N), 3) drop the item into the new window. And guess what? There isn't.
The same thing goes for Linked Windows by the way. Instead of that crap, there should be a simple and easy way to select and grab multiple tabs (objects) simultaneously. And there isn't. Instead of easy to understand functionality that fits the object paradigm, you're left with this unusable imperative modal "linked windows" shit from the dinosaur age.
The same considerations apply to Open In New Tab vs Open In New Window, which is why the latter simply shouldn't exist. And FINALLY, the same considerations apply to Open vs Open In New Tab. Instead of this stupid function, there should be a simply way to Duplicate Tab and Erase Its History.
So you don't Open In New Window, what you do is you follow the link (none of that "opening" shit, what the fuck is actually being opened you moronic retards?!) then you zoom out to see the browser object (actually, a Self Modifying Document, not a "browser") as a whole. Then you Duplicate The SMD, then you erase the history of the new SMD, then you grab the new SMD and move it to a new group / folder.
Voila, in four easy steps (each of which should be trivial) the user has performed this little used and complicated action. Without learning anything new! Because each of the steps is something the user has already learned and done in other contexts for their own purposes. They've just now chained them all together into what you retarded morons mistakenly think is a unified "operation".
And if it costs more time to perform the four steps rather than to perform a single operation then it doesn't matter. After all, I have never used this operation in my life. And I bet plenty of other people haven't also. So why the fuck is it cluttering up my context menu?! It's imposing a cost on me every single fucking time I open this menu, and has never provided any benefit!
A designer cares about these issues. Programmers obviously don't since they are incompetent fuckwits incapable of judging whether something's good or bad, useful or useless, unless there's an already established objective metric they can use. That's right, programmers do evil because like all purely analytic people incapable of synthesis they are incapable of judging good vs evil.
So to recap, there should in this context menu be exactly 6 items.
- Follow Link
---------- - Grab Object
---------- - Grab And Drop to 1
- Grab And Drop to 2
- Grab And Drop to 3
- Grab And Drop to 4
And ideally they should be arranged geometrically in an OctoRadialMenu with Follow Link at the East position, Grab Object at Northeast, and the rest going counterclockwise from North.
What that means is you should be able to hit Ctrl-D to Follow Link, Ctrl-E to Grab Object, and the rest should be either Ctrl-WQAZ going counterclockwise from Ctrl-S.
Now let's count them, yes that's six, six, different functions, in 3 different sections. Not only is it cleaner and more elegant, but 99% of users would be vastly happier with this arrangement as it would be vastly more useful and save them time. More power to the users with one third as much "functionality".
But that would assume programmers aren't incompetent moronic retards, or that they are brought to heel by competent systems designers. The former isn't ever going to happen until we have neurosurgery. And the latter is going to fail due to politics - due to the fact programmers don't want to see themselves as mentally handicapped.
The web is now 20+ years old and still we have these ridiculous web "browsers" that are utter design disasters. And as the fate of Smalltalk shows, it can only get worse as more mainstream (ie, stupider, less creative) programmers and engineers (like at google) get involved in the game.
Posts
2 comments:
Note, menus should never be editable from within themselves because that would be confusing the level and the meta-level. Context menus are ABOUT another object, never about themselves.
So menus should be objects and as objects they can be selected and have contextual menus on them. These 2nd degree menus allow you to edit the 1st degree menus.
Also, I've only just noticed that Opera has continuous transitions between dissimilarly sized popups. This is good. On the other hand, it is also superficial. So meh.
For 'context' menus, I've always felt that users should have more precise control over context.
The 'hand vs. pointer' concept had me thinking about how inventories provide context in games - i.e. if you approach a door, the options presented to you may differ based on whether you carry the key. The options for 'Grab and Drop To' could be replaced with a set of options based on the current hand.
I would not want the interaction between locations and links to be hard-coded.
The idea that 'a location can receive a link' must, of course, be encoded somewhere. I can think of four possibilities: the link, the location, the 'hand object' itself, or a distinct 'tooling object' stored in the hand. Encoding how to join objects at the location or link is too rigid, and users shouldn't deal with methods in the hand object. So I favor the notion that we carry 'tools' in our hand.
opts = new List
foreach tool in hand
opts.add(tool.getContextOpts(hand,target))
The ‘GrabDropLocation’ tool would be part of the hand. We automatically get recursion, in the sense that a toolbox is also a tool. If users overload their hands and there are too many options, we could use multi-level menus (distasteful, IMO, but workable with a radial menu) or use a multi-ring option cycled with extra key presses.
The disadvantage of this mechanism: users have an inconsistent menu based on a seemingly modal property (tools and objects in hand). This can be alleviated a bit by allowing tools the option of reporting ‘disabled’ options, and by ensuring the menu is at least deterministic. The advantage: every presented option is meaningful in context, and users have a higher level of programmable access to their UI (just grab your favorite wrench...).
I imagine users could have a few different hands, which they can access by pressing a few dedicated buttons (e.g. F1..F4). Different hands could have different toolsets and contexts (to help users multi-task between vastly different activities). Locations shared between hands could serve as bags for anything that needs to relate from one hand to another. Hands also serve as navigable locations (e.g. double-tap the hand button), which allows meta-level editing when we want it.
Post a Comment