I think that while you're definition may be an accepted definition, it's also wrong, and shortsighted. And probably not nearly subtle enough.
It is the definition the people who founded and birthed the field came up with; the definition that SFWA, in the Milford meetings, decided was the definition. Accordingly, I believe I'll stick with it, as opposed to a more recent re-casting. All it does is provides a factor to shelve and otherwise classify books by these days anyway. It isn't like fantasy is an inferior genre; it's just a different one.
Perhaps — as you seem so passionate about this — you should adopt the "speculative fiction" moniker that has lately surfaced; now you've got an "SF" that applies to fantasy and science fiction. And after all... that's why they ginned it up.
And why would I want to do that? Did you infer that I didn't enjoy fantasy from something I said? If so, what? I'm interested to hear why you have come up your fascinating statement. Do tell.
Fantasy is (and always has been) a subgenre of Science Fiction.
No. It hasn't. It has often been carried along as an interest of the same people; the magazine F&SF (Fantasy and Science Fiction) is a textbook example of how marketing both to the same audience works just fine, but that doesn't make one the child of the other.
Science fiction is defined by the valid or potentially valid science constraint. The idea was to wrap a story around science. Fantasy does not have such a constraint. Those stories can (and are) wrapped around anything the author would like to claim, with or without rationalization, justification, or supporting framework(s) in the real world.
Think of it as 'novels for nerds'.
I prefer to think of it as "fiction for the scientifically minded reader."
No. Heinlein puts his finger on it (no surprise there, either): "realistic speculation"
The Wikipedia article accurately notes that "an uneducated person will have different expectations about what science can do than a professional physicist." This is what causes people to mistake, for instance, Star Trek, Star Wars, and Battlestar Galactica as science fiction instead of the fantasies they really are. Those mistakes do not somehow mutate those artworks into SF; they simply identify the audience as not particularly informed consumers.
SF (which originally meant "science fiction", not "speculative fiction") was born of the idea that a story would be wrapped around one or more concepts that either were supportable using current science, or could reasonably be extrapolated from current science. Hence, the "science." This was the thing that differentiated the genre from, for instance, just anything you wanted to write about. The idea was to inflame the reader with "Wow! This could actually happen!"
The wikipedia article comes at this from precisely the wrong angle: It says SF is "not magical or supernatural" but that is not what SF is. SF is science derived, not "anything that isn't... whatever." SF was never defined by what it wasn't, or in other words, it was defined by what it was. As soon as it fails to be that — fails to be scientifically valid or scientifically possible — you have fantasy. And what does fantasy mean? It means using one's imagination without constraints. SF does have a constraint, and that constraint is science.
Our literature contains many examples of carefully applying these precise limits to stories, and sophisticated looks at how well this was done (for instance, see the critiques, "The Issue at Hand" and "More Issues at Hand.") Genre specialist publications (fanzines and author's self-publications from the 50's, 60's and 70's) went all through this and came down hard on the side of science. Publishers and the marketing side of the business (something I am intimately familiar with, as I own one of the oldest SF-specialized literary agencies in the world) are responsible for the blurring of the SF/fantasy line in the marketplace more than anything else.
Calling Dr. Who SF won't make it SF; the unrelenting use of fantasy elements tells the tale to any who care to look.
Terrorism is far less likely to kill you than so many other things, yet we don't have a "War on..." anything other than "Drugs".
Yes. And it is entirely worth noting that the "war on drugs" isn't working either. Drugs are less expensive than they have ever been (especially if you factor in inflation), more plentiful, there is a greater variety, new ones of various capabilities are appearing at a rate faster than they can be classified illegal, and more people are in jail over making a personal choice than are for committing violence against another person. Despite decades of intense "warfare."
I find the very idea that the recent legislation will actually do anything positive about terrorism to be black, black humor. Furthermore, I find the idea that we needed any additional legislation to be entirely specious.
Yes, it bloody well does. There are these magical devices, you see (we call them "computers", you probably call them "spawn of satan") that allow us to produce pre-formatted documents with the ability to fill in salient details from a large swath of canned possibilities. A skilled user of said device should be able to produce a completed document in under a minute, most of which is printing time.
However -- FISA is unconstitutional if applied to US citizens as the constitution specifically requires a warrant to be obtained prior to infringing on any person's rights; furthermore, as US court cases have specifically decided that those rights extend to non-citizens, FISA is unconstitutional with regard to foreigners as well.
The constitution is a document that is designed to constrain how the government operates. That is its one and only function. It does not constrain the behavior of citizens, nor could it possibly be construed to do so without a citizen actively taking an oath or signed a statement to that effect. Now that the government is ignoring the constitution wholesale, it has no remaining legal function. Which leaves us with nothing but the sorry collection of legislation coming from Washington.
That legislation required Bush to use FISA to tap calls; it gave him 72 hours and a very low standard to meet in terms of retroactively identifying who, what and where, and he did not bother. Violating the act is a crime; that makes Bush a criminal, even under our confused and manifestly unconstitutional legal system.
That is not in the least a valid analogy. Vision is both directional and maskable. Hearing is capable of very little of either. Light input to your eyes falls on distinct areas and is fed to your brain as separate data down separate nerves, into brain regions that have very wide data inputs; audio input to year ears mixes at the eardrum and comes in all pre-mixed and together — essentially, you have no means other than the abstract to separate mixed audio, while visual input is not mixed at all if it is in significantly disjoint regions unless you have physical perception problems in your optic nerves.
I suggest you try not to craft metaphors when you have a 3rd-grade understanding of how the elements work. Also, your quoting skills need work — this has nothing to do with the gross "neon green" error you made, or with monitor calibration.
And coincidentally, I am a pro sound engineer, as well as a musician. Been playing for 40 years and working the board side of the process for 25. Your lame attempt to use recording issues as a color correction metaphor caused much amusement around here; the whole shop is laughing at you right now.;-)
"LOL!" ? "puppy?" ? "Cuz" ? "A-ha video" ? What are you, 12 or 13 years old?
Such a complete inability to address the arguments; such a complete inability to bring facts to the table; such a lame attempt at replacing balanced discussion with writing that a 7th grader would be ashamed of.
Unless, of course, you are a 7th grader. In which case, I apologize. In that case, you're acting just as one might expect.
Ok. First, Searle's argument boils down to "rule based responses from humans and computers could be indistinguishable, but rule based responses aren't particularly intelligent, therefore, computers aren't intelligent."
That's fine, as far as it goes. Which isn't very far. The fact is, "rule-based" AI isn't what anyone serious is working on. Neural networks, random weightings, input of and from time, knowledge, current senses, all of these things result in a stacked set of steering forces which will be variously weighted at any one time that give one (of possible many) answers, and that's the sort of thing that a mind -- any mind -- does. The first thing one recognizes is that a human could not, consciously at least, follow such a set of rules at any speed sufficient to mimic any behavior that might possible be mistaken as human. So the "appearance" of strong AI in the Turing test sense is not possible with any imaginable un-augmented human with todays gene and social pools to draw upon.
The second thing one recognizes is that to the extent that a human can actually do this, meaning, someone who actually knows Chinese (ni hao!) and can react at human speeds to both reading and writing Chinese, the human may in fact be doing exactly what the computer is being "accused" of doing by Searle. That is, following a set of learned and hard-wired rules, rules that we cannot, at least thus far, characterize.
Searle's argument depends upon, at its root, the idea that human cognition is not rule based in any sense; meaning, chemical rules, electrical rules, quantum rules, logical rules, timewise rules. But the fact is, this has not been established, and to the contrary, everything we learn about physics and the world around us brings us more and more confidence that this is probably exactly how the brain works, simply because this is how everything else works.
Most "humans are special (or thinkers in general, if we include the animal kingdom, which I would be inclined to do)" arguments derive from either religion, which uses axioms not in evidence to claim that humans are special, or various doubtful thought experiments that arrive at the idea(!) that humans are special. I am unaware of any scientific experiments that support either view, nor -- and we're back to IMHO now -- do I expect to see any such thing come to pass, though I would be fascinated if it did.
When Block argues (quoting you, though) "Human intelligence is innately biological, and non-reproducible with hardware and software" he is, at least according to all the evidence so far, being disingenuous. Why? Because biology is, as far as anyone knows, and to an extremely high degree of confidence, hardware and software. It is structures (atoms, molecules, cell components, cells, larger structures, collectively "hardware") following rules (molecular and chemical cues, electrical cues, quantum cues... collectively, "rules")
Now, I am not saying it is impossible that biological systems transcend hardware and software. What I am saying is that nothing else has been shown to do so, and the only reason that we have been given to incline us to think along those lines thus far is the essential statement "we don't know how we work, so we must work differently" which I find to be lacking in quality underpinnings, to put it kindly. Should we come up with actual scientific reasons to think this is actually so, again, I'll be fascinated; but so far, no joy. So again, we're back to presuming that the rules that govern the entire rest of the known universe probably govern our minds as well.
Presuming otherwise at this juncture in our knowledge is akin to watching billions of cars pass on a highway, opening the hood of every one, finding a gasoline engine in them, then finding one of the hoods is stuck, and presuming (without ever having properly gotten inside to look) that particular car is powered by antigravity, without evidence that antigravity is even possible.
We'll first understand how our minds work, and then we'll be able to create strong AI.
I don't think so. While — as an independent AI researcher — I would not absolutely rule out a "we programmed it" solution, I really don't think that's what we're looking at. No more than we were "programmed" to be intelligent, in any case.
What is needed is a hardware and probably somewhat software (at least as a serious secondary effort after pure software simulation uncovers what we need to do) system that can learn; not something that is complete, out of the box. The latter can be created by state replication once one or more AI have been built; but from my point of view, what you're looking at is an evolutionary process, which when fruitful, will yield something we can teach, and which can teach itself, and which we should be very careful to build in such a way as to be able to replicate both its hardware and the state of its hardware.
You and your instructor are quite right that we do not understand our own (or animal) intelligence. The error in the subsequent thinking here is, I think, that you are both assuming we need to understand it well, or perfectly, to create it. That does not necessarily follow.
For my part, I remain very confident that we are well past the point where we can make the right hardware; what we are missing is the right configuration. From a technical standpoint, it does not matter how large, or how slow, the initial success is; once the problem begins to resolve itself, we can apply our usual skills at shrinking and speeding up systems -- or even, making them remote via telepresence, if large is initially unavoidable -- until we have something we're satisfied with, and from there, of course, we can hand the task of making something better off to the AI itself.
As an interesting side note, there are many interesting knowledge base projects going on right now which, while not likely (in my view, again, this is all IMHO) to yield an actual AI, will be a great resource for an AI; knowledge that can be tapped using straightforward rules and methods.
I personally think we'll see strong, probably very strong, AI within a decade at most. I'm excited about it; I hope to contribute (my area is associative knowledge and the process of melding emotional and other modifying concepts to knowledge.) But I'll be delighted no matter where the results come from, as long as they come!
The early S-100 systems (Altair, Imsai, Poly, Northstar) used linear supplies and ran unregulated DC on the S-100 bus
It was unregulated in the precision sense, but it was filtered. SS-50 buss systems did(do) this too; there were +12 and -12 vdc supplies at a few amperes, and typically one +8 vdc supply at as many amperes as you could afford. 5 vdc regulators (7805's and their brethren) were used on each PCB.
I still have my GIMIX SS-50 system, though I sold both an Altair 8080 and an Altair 680 when the offering prices became more than a new car, each.:-) The SS-50 is running a 6809 and TSC Flex in 64k(!) of RAM, 4 disk drives, custom graphics and sound cards from my video game (arcade) development days.
Since mice and humans share more than 90 percent of genes, the Allen Brain Atlas has enormous potential for understanding human neurological diseases and disorders affecting more than 50 million Americans each year
Well, Mr. Smith, I have goods news — and I have bad news. The good news is because of the Allen Brain Atlas, we have been able to determine exactly what is wrong with you and precisely how to put you back together.
The bad news is when the procedure is complete, your name will be "Algernon."
Look, I have nothing to gain by convincing you, unless you consider consulting for free a gain
I consider consulting a process where the nominal consultant doesn't hold opinions they can't back up with facts, and where there is production of value to which I can respond with compensation, a benefit which I am well able to produce. Otherwise, it isn't consulting — it's just someone's opinions, and as you know... we all have them. I didn't ask for your opinion, remember. You just threw them out there, and as a courtesy, I responded with my thoughts on what you had to say. If you don't want that to happen... don't comment, I suppose. I reserve the right to inflict my opinion on you if you inflict yours on me, that's all. It's Slashdot, right?
Oh, and I think you need to consider just how complex something like Maya or 3dsmax is even without plugins...
...and I think you should realize that among other things, WinImages contains a full-bore, general purpose, animated, splined, tweened, ray-tracer that does all manner of really, really cool things... even without plugins. Also a landscape pre-rendering system, not ray-traced. Including some ray-tracing features Maya and 3dsMax don't, such as integrated scripting with a complete image manipulation system, from morphing and warping (not dependent upon identical number of vertices) through multi-scene sensitive dynamic range normalization right down to CMYK separations. Though I was only referring to image manipulation in the original comment, because that's where the GUI is exposed. How does your comment planning go again? Ready, fire, aim?
There is no usability gain (or loss) with fat bevels
Disagree completely. Distinct bevels provide strong confirmation that your mouse click is being taken for what you meant it to be taken for. They reverse on press, as is typical, giving the visual cue of "depression", the appropriate visual metaphor for a button.
...make[s] your app look like it was designed for Windows 3.1.
It was. And prior to that, for AmigaDOS. What is your problem with that? Do you want to get work done, or do you want to sit in front of your monitor, drooling over the latest and greatest 2006 icon styles? We have a finite amount of manpower, and always will. Should we spend it adding features that manipulate (or facilitate manipulating) images, or should we spend our efforts just trying to make the app look like it conforms to the latest UI fad? What benefits our customers the most?
Windows users have been identifying the state of borderless buttons on toolbars for a decade. Don't try to bullshit us into accepting an aesthetic choice as anything but.
Not aesthetic, but rather a time and functionality choice. Functionally, when you scale the icons, as they get smaller, the borders help keep selection clear. When MS went to borderless buttons, we were already years past product launch. They changed; we didn't. We just kept on adding features. We'll keep doing so. I don't see any reason to change the borders of the buttons. You (as near as I can tell) object to them because they're not the same as, for instance, access or excel. If you have a concrete objection that is based upon some rational metric, by all means, state it. Otherwise, I remain unconvinced.
Another point, re look and feel. We write all our own UI above the most basic window level. Toolbars, treeviews, dialogs, etc. This allows us to remain immune to Microsoft's unfortunate tendency to break things left and right, which reduces crashes and unexpected, not to mention unpredictable, behaviors. It also, should a bug be found, allows us to fix it immediately instead of waiting for MS to fix it, which as any Windows developer can tell you, may involve waiting forever. It also allows us to keep the application from bloating. We pack more functionality (and a faster application overall, not just load time) into 4 megabytes of high-speed executable than you'll find, for instance, within the many more megabytes Photoshop consumes when you load it into memory. And of course, porting (Mac, Linux) is a lot easier in principle because we have far fewer dependencies upon the OS than one would if one used the system libraries for toolbars and treeviews and so on.
These are very significant up-sides. Down-sides (perhaps) include not having the toolbars follow the latest behaviors that are defined in MS's libraries, and the fact that if we want such changes, we have code to write and/or modify, consequently there is what we could call "UI inertia" in the product. Another is for those people who are, for whatever reason, sensitive to how currently fashionable the UI looks, the interface can give the incorrect impression of not providing the latest and greatest program functionality, simply because it doesn't provide the latest and greatest UI appearance as defined by MS and its hordes of sycophants. I recognize this issue, but I have to admit, on behalf of those who are so focused on form over function, I just don't get too excited. This is a tool (well, — many tools — a toolkit.) We are all about power, function, flexibility, speed, performance, solving tough imaging problems and optimizing efficiency. We offer many features you can't find elsewhere. I think that is 100% appropriate as a product focus for the developers, that is to say, us/me. Excessive time spent on "pretty" seems like a waste to me. The GUI is there, and the fact is, it works fine. If there is a functional reason to change i
...until you spend hours swearing at the machine until you convince it that you need it
Well, if that was actually an issue, that's fine, but in point of fact, it's inaccurate, at least in our case.
First, any operation is two left clicks away on the toolbar, worst case. One click makes it visible, the next selects it. Any operation within the current group (geometric, compositional, plasma, etc.) is already visible, and is one left click away, presuming you are running in somewhat modern screen resolutions and have not scaled the icons up so far they no longer fit (the UI works just fine in low-res like 640x480, but you do end up scrolling the toolbar more often than not... it is worth noting that the menu system is pretty tight in 640x480 also, as windows scrolls menu contents as well when menus are too long for the screen height.) Turning the icon text labels on and off can also change how many icons fit across the display at one time.
Second, in addition to the context sensitive toolbar, which moves and offers the complete set of tools, we provide a standard menu system, which is static and also offers the complete set of tools.
Third, we provide user configurable NxN toolboxes ("op[eration] caddies") within which you can collect any arbitrary group of tools you like, of any size up to 8x8 tools, 256 total. So if your work flow is, for instance, that of someone who fixes old photos, you can collect color correction, geometric adjustments, noise filters, dynamic range tools, and so forth. You can save any number of these toolboxes and open the one that fits your current workflow at any time, or simply build one on the fly (just drag and drop icons from the toolbar into the toolbox and they're ready to go; if no toolbox is open, dropping a tool on the backdrop window will open one.) You can rearrange the icons within the toolbox, delete them, etc. A typical caddy size for me is 4x8 for 32 tools, given any one workflow. I actually do spend a lot of time fixing old photos, as I maintain my family's genealogical web site, which has a couple hundred megabytes of web stuff, timelines, images, etc. I also (as a hobby) like to mess around with landscape generation and ray tracing, and I have caddies optimized for those workflows as well — heightfield processing, crater generation, erosion, texturing, that sort of thing. So I use a different op caddy for that.
Op caddies are static, unless you change them, so you can develop the same kind of visual and placement-level familiarity with them that menus offer; but because you set them up, they offer the ability to match your focus, no matter how eclectic that might be. And finally, they're one-left-click in terms of UI speed and convenience, which is unbeatable. If you need something you didn't put in there in some odd circumstance, you have the option of one-timing it from the toolbar or the menu system, or you can drag it in and save the new caddy configuration, and you'll have it from now on (unless you take it back out.)
Back to GUI: menus always have their commands on the same place, so if you have got some kind of experience with your application, you will instantly find back a command. With the smart menus (the collapsing menus) in Office etc., you won't find your menu commands back as fast. Ribbons make things even worse: things move around even when selecting a different object. It would drive me nuts!
I think this is a very valid point, and it is the underlying rationale as to why we also have a full menu interface that allows you to get at the available tools. Likewise, although we have a faster area selection methodology than, for instance, Photoshop does, we provide a "compatible" operating mode so that those whose habits overwhelm their ability to learn new ways of working can still be effective.
However: If you and I sit down in front of the software, and you, being intimately familiar with the menu structure (very similar to Photoshop's... menu for op classes, submenus for specific ops, non-modal dialogs if needed) were to "race" me to get a particular task done, I'd get done first, every time, using the chapter/verse toolbar because it requires considerably fewer UI actions (mouse moves, clicks, keystrokes) to get to any particular operation and get it running.
Similarly, if you were attempting to use the Photoshop compatible mode of area selection (select, pick an op, let the op run, repeat) and I was using ours (pick an op, select(autorun), select(autorun), select(autorun)...), again, I'd finish way ahead of you, and the more areas, layers and images that need to be worked on, the more ahead I'd get.
This continuously aggregating time savings is a benefit of the new methodologies that I get because I am willing to use them, and which you don't. The questions are: How much is your time worth, and would working with a narrowed interval between actual image processing operations benefit your focus?
I do not for a moment discount either that familiarity has its uses or that time is not always a critical factor; I know for a fact that many of our customers use the menus and/or the PS compatible selection mode, and they're perfectly happy. However, on the other side of the coin, some customers are looking for the most streamlined workflow, and they make the (incontestable) point that time, for them, is money. They're intent enough on this to invest a little time up front to learn new ways of working in order to save larger cumulative amounts of time over many jobs. I work this way myself. I am not particularly comfortable within Photoshop, for instance, because actual production use of it is so much slower; Often, I know I could be doing the same thing with less UI interaction, and that makes me want to go do so. It isn't just the discomfort — time is definitely money at work, and when it isn't money, it could have been time with my family.
Think of it in terms of functionality. Every element in a GUI serves a function, intentionally or otherwise. You don't want your tools to interfere with what you're working on unless they're doing exactly what they're intended to do and nothing more
I really think you need to read what I wrote in response to your original point, instead of making up your own agenda. As I have clearly said, the colors do have specific function within the interface, just as a color-coded set of wrenches uses color to cue you as to what to grab next, so the colors on these tools cue you as to function. You (and the other two posters upstream), on the other hand, have not offered any reasonable postulate as to why color would actually degrade the workflow. In contrast, I have specifically outlined for you precisely what the colors do for the user within the context of the interface itself.
It seems to me that if you want to make your argument, then you're going to have to offer some good reason — and I'm not talking about a claim that color anywhere but on the image disturbs your "wa"... otherwise, as I told the other poster, every time your golden retriever comes in the room, you'd be tinting your images orange. Certainly I wouldn't be considering inconveniencing the majority of our customers simply because your work habits are influenced by contextually irrelevant, physically distinct, functionally disjoint elements in your cone of vision.
If you have a another point, by all means make it. I'm not going to rule your continuing objections out just because you haven't convinced me yet. I can be convinced, but not by crystal gazing or hand waving. Bring me some facts. Remember, I have made my living (and the livings of quite a few other people) based on how the software works now, and by listening to our customers over more than a decade (who, by the way, suggested the colors — we actually had a pure grey interface, way back when we first shipped the core engine in the very early 1990's.)
Perhaps something else for you to consider is that this software is far more complex than anything else you've used, unless you're using some proprietary solution no one's ever heard of. In terms of the number of operations, controls for those operations, and the multiplying factors of time, area selection techniques and layer interactivity, every usability cue we can give the customer that keeps them out of the documentation can be expected to have a real time benefit. If you want to argue the colors out of the interface, you have to provide a counterweight to that functionality. We could even let you create your own icons, if you could make the case that something like that would actually be useful, as opposed to a waste of our (and your) time. We use scalable images for them anyway, nothing earthshaking would be required to let you cobble up your own set. Added complexity has to justify its own weight, though.
Yeah, as a professional retoucher, why would I mind all that neon green on screen while I'm doing color correction?
In the same spirit in which your comment was offered:
If you're a "professional retoucher", I'm sure that somehow, you can come to terms with ignoring colored areas of your display that aren't part of the image. Otherwise, you'd be accidentally tinting your image neutral all the time, accidentally drawing little icons in your picture, and window bars, sizing gadgets, and menus, because, why after all, there they are!
The very idea that your "professional" senses would be "disturbed" by elements of the display not actually on your image is ludicrous. Because I am not a "professional retoucher" and I am, according to you, better at it than you are -- because I only consider the image when I adjust the image... not elements outside of the image area. Maybe you should learn to do that. Then you wouldn't be tinting your work orange when your golden retriever comes into the room... There isn't any color in your office, is there? And you wear neutral colors when you color correct, right? And if you've got a window, you only color correct when it's a neutral grey overcast, right? And your secretary (as a professional, I assume you have one), you make her dress in neutral grey and forgo makeup and powder up in grey so you don't tint your images flesh tone.... right? I knew there were reasons I wasn't a professional retoucher...:-)
And, if you're doing color correction, you wouldn't be looking at green anyway; the green set is for filters. The standard operations group is grey and blue, and that's what would be up (remember, the tools are grouped by context.) Not to mention that as a "professional retoucher", you'd be able to differentiate "neon green" from fairly mundane leafy colors. Maybe you should calibrate your monitor.
No; your analogy is inaccurate. The use of the GUI involves several things.
Recognition: This is enhanced by clearly delineating the button's edges, by use of color to cue the operation class and type, by icons that hopefully provide a cue to the actual operation, and by the ability to scale the icons within the interface.
Targeting and confirmation: by clear indication when pressed (which is also enhanced by a more pronounced border changing state on click / activation.)
Intended functionality: The tool has to do what it is supposed to do as well as possible.
These are the operational issues. I do not agree that the color of the icon, or the depth of the colors / contrast, will affect the usability of the tool, barring actual neuroses or fetish (and in which case, I am unconcerned.)
The issues here -- color, contrast -- won't affect the ability of the program, or the user, in a negative way, and in fact, are a help (just as a color-coded set of wrenches are a help.) So again, I don't buy the position.
you should use neutral colors in the GUI where ever possible unless you've got a very good reason not to.
...and indeed we do. The colors on the toolbox icons differentiate tools from tool modifiers; the colors on the toolbar group functions together when you are scrolling past the boundary of one (or more) contexts; the green dots on the toolbar icons indicate that those operations can be run non-destructively within a warp layer; the colors on both sets of icons also provide visual cues for timelines where you can stack keyframes for operations, images, animations, and area selections both in depth and in time.
The overuse of wide high-contrast bevels is a problem
I'm sorry, I just can't take that remark seriously. I make software to operate on images. I'm not selling bevels, or looks. I'm selling functionality. If you want to do some serious image manipulation, I have something to offer, and I can make a case for that very well. If you want great artwork, I would simply suggest that it is not appropriate to buy a hammer based on how well the handle is engraved. What you want to know is how well it hammers things. Decoration is irrelevant to serious tool users.
I'd say gaining complexity is perhaps the definition of evolution
My product an image manipulation system, has had contextual, ribbon-based selection of tools since 1990. We use a chapter/verse metaphor (click on one level of the toolbar to select the chapter, such as filters or geometric tramsforms, the next level slides into view which contains individual tools such as sharpness and feature removal, or ripples and rotations.)
This layout, like MS's "new contextual ribbon" puts what you need in front of you, and buries everything else until you need it. Our chapters function exactly like MS's "tabs" and our verses function as accessors for sets of tools -- basically, there are three levels to the GUI. We don't put the third level in the toolbar, because there are far too many controls for some tools (as many as 70 sliders, buttons, drop-downs) and it is (we think) a poor decision to always take large amounts of vertical space in an image-processing application. Dialogs let you move all that tool-consuming real-estate around. They aren't modal, though, so you can keep working.
This really is a better and more evolved way to work, and I commend MS on finally getting the point (although I note with some humor that they certainly didn't invent this methodology.) Of course I'm partial to it, having been building and using such an interface for well over a decade now.
The thing that seems to stick in user's craws isn't the difficulty (or "increase in complexity, as you put it) of such a layout, because there isn't any, really... but simply that it is "different." Change is a force for user discomfort, especially UI change. I'm not saying that UI's can't get more complex, they certainly can, but contextual ribbons are a simplifying factor, count on it.
Slashdot Mirror
It is the definition the people who founded and birthed the field came up with; the definition that SFWA, in the Milford meetings, decided was the definition. Accordingly, I believe I'll stick with it, as opposed to a more recent re-casting. All it does is provides a factor to shelve and otherwise classify books by these days anyway. It isn't like fantasy is an inferior genre; it's just a different one.
Perhaps — as you seem so passionate about this — you should adopt the "speculative fiction" moniker that has lately surfaced; now you've got an "SF" that applies to fantasy and science fiction. And after all... that's why they ginned it up.Well, if that is the case, then he would simply be wrong. :-)
And why would I want to do that? Did you infer that I didn't enjoy fantasy from something I said? If so, what? I'm interested to hear why you have come up your fascinating statement. Do tell.
No. It hasn't. It has often been carried along as an interest of the same people; the magazine F&SF (Fantasy and Science Fiction) is a textbook example of how marketing both to the same audience works just fine, but that doesn't make one the child of the other.
Science fiction is defined by the valid or potentially valid science constraint. The idea was to wrap a story around science. Fantasy does not have such a constraint. Those stories can (and are) wrapped around anything the author would like to claim, with or without rationalization, justification, or supporting framework(s) in the real world.
I prefer to think of it as "fiction for the scientifically minded reader."
No. Heinlein puts his finger on it (no surprise there, either): "realistic speculation"
The Wikipedia article accurately notes that "an uneducated person will have different expectations about what science can do than a professional physicist." This is what causes people to mistake, for instance, Star Trek, Star Wars, and Battlestar Galactica as science fiction instead of the fantasies they really are. Those mistakes do not somehow mutate those artworks into SF; they simply identify the audience as not particularly informed consumers.
SF (which originally meant "science fiction", not "speculative fiction") was born of the idea that a story would be wrapped around one or more concepts that either were supportable using current science, or could reasonably be extrapolated from current science. Hence, the "science." This was the thing that differentiated the genre from, for instance, just anything you wanted to write about. The idea was to inflame the reader with "Wow! This could actually happen!"
The wikipedia article comes at this from precisely the wrong angle: It says SF is "not magical or supernatural" but that is not what SF is. SF is science derived, not "anything that isn't... whatever." SF was never defined by what it wasn't, or in other words, it was defined by what it was. As soon as it fails to be that — fails to be scientifically valid or scientifically possible — you have fantasy. And what does fantasy mean? It means using one's imagination without constraints. SF does have a constraint, and that constraint is science.
Our literature contains many examples of carefully applying these precise limits to stories, and sophisticated looks at how well this was done (for instance, see the critiques, "The Issue at Hand" and "More Issues at Hand.") Genre specialist publications (fanzines and author's self-publications from the 50's, 60's and 70's) went all through this and came down hard on the side of science. Publishers and the marketing side of the business (something I am intimately familiar with, as I own one of the oldest SF-specialized literary agencies in the world) are responsible for the blurring of the SF/fantasy line in the marketplace more than anything else.
Calling Dr. Who SF won't make it SF; the unrelenting use of fantasy elements tells the tale to any who care to look.
Perhaps so — as a matter of opinion — but it isn't science fiction, it is fantasy, and hence the GBoWR got it wrong.
Yes. And it is entirely worth noting that the "war on drugs" isn't working either. Drugs are less expensive than they have ever been (especially if you factor in inflation), more plentiful, there is a greater variety, new ones of various capabilities are appearing at a rate faster than they can be classified illegal, and more people are in jail over making a personal choice than are for committing violence against another person. Despite decades of intense "warfare."
I find the very idea that the recent legislation will actually do anything positive about terrorism to be black, black humor. Furthermore, I find the idea that we needed any additional legislation to be entirely specious.
<pedantic>
Pardon me, "Oversite" s/b "Oversight." A "site" is a place; "Sight" is to see something.
</pedantic>
Otherwise, great post.
Yes, it bloody well does. There are these magical devices, you see (we call them "computers", you probably call them "spawn of satan") that allow us to produce pre-formatted documents with the ability to fill in salient details from a large swath of canned possibilities. A skilled user of said device should be able to produce a completed document in under a minute, most of which is printing time.
However -- FISA is unconstitutional if applied to US citizens as the constitution specifically requires a warrant to be obtained prior to infringing on any person's rights; furthermore, as US court cases have specifically decided that those rights extend to non-citizens, FISA is unconstitutional with regard to foreigners as well.
The constitution is a document that is designed to constrain how the government operates. That is its one and only function. It does not constrain the behavior of citizens, nor could it possibly be construed to do so without a citizen actively taking an oath or signed a statement to that effect. Now that the government is ignoring the constitution wholesale, it has no remaining legal function. Which leaves us with nothing but the sorry collection of legislation coming from Washington.
That legislation required Bush to use FISA to tap calls; it gave him 72 hours and a very low standard to meet in terms of retroactively identifying who, what and where, and he did not bother. Violating the act is a crime; that makes Bush a criminal, even under our confused and manifestly unconstitutional legal system.
That is not in the least a valid analogy. Vision is both directional and maskable. Hearing is capable of very little of either. Light input to your eyes falls on distinct areas and is fed to your brain as separate data down separate nerves, into brain regions that have very wide data inputs; audio input to year ears mixes at the eardrum and comes in all pre-mixed and together — essentially, you have no means other than the abstract to separate mixed audio, while visual input is not mixed at all if it is in significantly disjoint regions unless you have physical perception problems in your optic nerves.
I suggest you try not to craft metaphors when you have a 3rd-grade understanding of how the elements work. Also, your quoting skills need work — this has nothing to do with the gross "neon green" error you made, or with monitor calibration.
And coincidentally, I am a pro sound engineer, as well as a musician. Been playing for 40 years and working the board side of the process for 25. Your lame attempt to use recording issues as a color correction metaphor caused much amusement around here; the whole shop is laughing at you right now. ;-)
"LOL!" ? "puppy?" ? "Cuz" ? "A-ha video" ? What are you, 12 or 13 years old?
Such a complete inability to address the arguments; such a complete inability to bring facts to the table; such a lame attempt at replacing balanced discussion with writing that a 7th grader would be ashamed of.
Unless, of course, you are a 7th grader. In which case, I apologize. In that case, you're acting just as one might expect.
Ok. First, Searle's argument boils down to "rule based responses from humans and computers could be indistinguishable, but rule based responses aren't particularly intelligent, therefore, computers aren't intelligent."
That's fine, as far as it goes. Which isn't very far. The fact is, "rule-based" AI isn't what anyone serious is working on. Neural networks, random weightings, input of and from time, knowledge, current senses, all of these things result in a stacked set of steering forces which will be variously weighted at any one time that give one (of possible many) answers, and that's the sort of thing that a mind -- any mind -- does. The first thing one recognizes is that a human could not, consciously at least, follow such a set of rules at any speed sufficient to mimic any behavior that might possible be mistaken as human. So the "appearance" of strong AI in the Turing test sense is not possible with any imaginable un-augmented human with todays gene and social pools to draw upon.
The second thing one recognizes is that to the extent that a human can actually do this, meaning, someone who actually knows Chinese (ni hao!) and can react at human speeds to both reading and writing Chinese, the human may in fact be doing exactly what the computer is being "accused" of doing by Searle. That is, following a set of learned and hard-wired rules, rules that we cannot, at least thus far, characterize.
Searle's argument depends upon, at its root, the idea that human cognition is not rule based in any sense; meaning, chemical rules, electrical rules, quantum rules, logical rules, timewise rules. But the fact is, this has not been established, and to the contrary, everything we learn about physics and the world around us brings us more and more confidence that this is probably exactly how the brain works, simply because this is how everything else works.
Most "humans are special (or thinkers in general, if we include the animal kingdom, which I would be inclined to do)" arguments derive from either religion, which uses axioms not in evidence to claim that humans are special, or various doubtful thought experiments that arrive at the idea(!) that humans are special. I am unaware of any scientific experiments that support either view, nor -- and we're back to IMHO now -- do I expect to see any such thing come to pass, though I would be fascinated if it did.
When Block argues (quoting you, though) "Human intelligence is innately biological, and non-reproducible with hardware and software" he is, at least according to all the evidence so far, being disingenuous. Why? Because biology is, as far as anyone knows, and to an extremely high degree of confidence, hardware and software. It is structures (atoms, molecules, cell components, cells, larger structures, collectively "hardware") following rules (molecular and chemical cues, electrical cues, quantum cues... collectively, "rules")
Now, I am not saying it is impossible that biological systems transcend hardware and software. What I am saying is that nothing else has been shown to do so, and the only reason that we have been given to incline us to think along those lines thus far is the essential statement "we don't know how we work, so we must work differently" which I find to be lacking in quality underpinnings, to put it kindly. Should we come up with actual scientific reasons to think this is actually so, again, I'll be fascinated; but so far, no joy. So again, we're back to presuming that the rules that govern the entire rest of the known universe probably govern our minds as well.
Presuming otherwise at this juncture in our knowledge is akin to watching billions of cars pass on a highway, opening the hood of every one, finding a gasoline engine in them, then finding one of the hoods is stuck, and presuming (without ever having properly gotten inside to look) that particular car is powered by antigravity, without evidence that antigravity is even possible.
I don't think so. While — as an independent AI researcher — I would not absolutely rule out a "we programmed it" solution, I really don't think that's what we're looking at. No more than we were "programmed" to be intelligent, in any case.
What is needed is a hardware and probably somewhat software (at least as a serious secondary effort after pure software simulation uncovers what we need to do) system that can learn; not something that is complete, out of the box. The latter can be created by state replication once one or more AI have been built; but from my point of view, what you're looking at is an evolutionary process, which when fruitful, will yield something we can teach, and which can teach itself, and which we should be very careful to build in such a way as to be able to replicate both its hardware and the state of its hardware.
You and your instructor are quite right that we do not understand our own (or animal) intelligence. The error in the subsequent thinking here is, I think, that you are both assuming we need to understand it well, or perfectly, to create it. That does not necessarily follow.
For my part, I remain very confident that we are well past the point where we can make the right hardware; what we are missing is the right configuration. From a technical standpoint, it does not matter how large, or how slow, the initial success is; once the problem begins to resolve itself, we can apply our usual skills at shrinking and speeding up systems -- or even, making them remote via telepresence, if large is initially unavoidable -- until we have something we're satisfied with, and from there, of course, we can hand the task of making something better off to the AI itself.
As an interesting side note, there are many interesting knowledge base projects going on right now which, while not likely (in my view, again, this is all IMHO) to yield an actual AI, will be a great resource for an AI; knowledge that can be tapped using straightforward rules and methods.
I personally think we'll see strong, probably very strong, AI within a decade at most. I'm excited about it; I hope to contribute (my area is associative knowledge and the process of melding emotional and other modifying concepts to knowledge.) But I'll be delighted no matter where the results come from, as long as they come!
It was unregulated in the precision sense, but it was filtered. SS-50 buss systems did(do) this too; there were +12 and -12 vdc supplies at a few amperes, and typically one +8 vdc supply at as many amperes as you could afford. 5 vdc regulators (7805's and their brethren) were used on each PCB.
I still have my GIMIX SS-50 system, though I sold both an Altair 8080 and an Altair 680 when the offering prices became more than a new car, each. :-) The SS-50 is running a 6809 and TSC Flex in 64k(!) of RAM, 4 disk drives, custom graphics and sound cards from my video game (arcade) development days.
Well, Mr. Smith, I have goods news — and I have bad news. The good news is because of the Allen Brain Atlas, we have been able to determine exactly what is wrong with you and precisely how to put you back together.
The bad news is when the procedure is complete, your name will be "Algernon."
I agree — and that's the way we supply the software. You want a custom toolset/caddy, you make it. Everything else is standard across all shipments.
I consider consulting a process where the nominal consultant doesn't hold opinions they can't back up with facts, and where there is production of value to which I can respond with compensation, a benefit which I am well able to produce. Otherwise, it isn't consulting — it's just someone's opinions, and as you know... we all have them. I didn't ask for your opinion, remember. You just threw them out there, and as a courtesy, I responded with my thoughts on what you had to say. If you don't want that to happen... don't comment, I suppose. I reserve the right to inflict my opinion on you if you inflict yours on me, that's all. It's Slashdot, right?
Disagree completely. Distinct bevels provide strong confirmation that your mouse click is being taken for what you meant it to be taken for. They reverse on press, as is typical, giving the visual cue of "depression", the appropriate visual metaphor for a button.
It was. And prior to that, for AmigaDOS. What is your problem with that? Do you want to get work done, or do you want to sit in front of your monitor, drooling over the latest and greatest 2006 icon styles? We have a finite amount of manpower, and always will. Should we spend it adding features that manipulate (or facilitate manipulating) images, or should we spend our efforts just trying to make the app look like it conforms to the latest UI fad? What benefits our customers the most?
Not aesthetic, but rather a time and functionality choice. Functionally, when you scale the icons, as they get smaller, the borders help keep selection clear. When MS went to borderless buttons, we were already years past product launch. They changed; we didn't. We just kept on adding features. We'll keep doing so. I don't see any reason to change the borders of the buttons. You (as near as I can tell) object to them because they're not the same as, for instance, access or excel. If you have a concrete objection that is based upon some rational metric, by all means, state it. Otherwise, I remain unconvinced.
Another point, re look and feel. We write all our own UI above the most basic window level. Toolbars, treeviews, dialogs, etc. This allows us to remain immune to Microsoft's unfortunate tendency to break things left and right, which reduces crashes and unexpected, not to mention unpredictable, behaviors. It also, should a bug be found, allows us to fix it immediately instead of waiting for MS to fix it, which as any Windows developer can tell you, may involve waiting forever. It also allows us to keep the application from bloating. We pack more functionality (and a faster application overall, not just load time) into 4 megabytes of high-speed executable than you'll find, for instance, within the many more megabytes Photoshop consumes when you load it into memory. And of course, porting (Mac, Linux) is a lot easier in principle because we have far fewer dependencies upon the OS than one would if one used the system libraries for toolbars and treeviews and so on.
These are very significant up-sides. Down-sides (perhaps) include not having the toolbars follow the latest behaviors that are defined in MS's libraries, and the fact that if we want such changes, we have code to write and/or modify, consequently there is what we could call "UI inertia" in the product. Another is for those people who are, for whatever reason, sensitive to how currently fashionable the UI looks, the interface can give the incorrect impression of not providing the latest and greatest program functionality, simply because it doesn't provide the latest and greatest UI appearance as defined by MS and its hordes of sycophants. I recognize this issue, but I have to admit, on behalf of those who are so focused on form over function, I just don't get too excited. This is a tool (well, — many tools — a toolkit.) We are all about power, function, flexibility, speed, performance, solving tough imaging problems and optimizing efficiency. We offer many features you can't find elsewhere. I think that is 100% appropriate as a product focus for the developers, that is to say, us/me. Excessive time spent on "pretty" seems like a waste to me. The GUI is there, and the fact is, it works fine. If there is a functional reason to change i
Well, if that was actually an issue, that's fine, but in point of fact, it's inaccurate, at least in our case.
First, any operation is two left clicks away on the toolbar, worst case. One click makes it visible, the next selects it. Any operation within the current group (geometric, compositional, plasma, etc.) is already visible, and is one left click away, presuming you are running in somewhat modern screen resolutions and have not scaled the icons up so far they no longer fit (the UI works just fine in low-res like 640x480, but you do end up scrolling the toolbar more often than not... it is worth noting that the menu system is pretty tight in 640x480 also, as windows scrolls menu contents as well when menus are too long for the screen height.) Turning the icon text labels on and off can also change how many icons fit across the display at one time.
Second, in addition to the context sensitive toolbar, which moves and offers the complete set of tools, we provide a standard menu system, which is static and also offers the complete set of tools.
Third, we provide user configurable NxN toolboxes ("op[eration] caddies") within which you can collect any arbitrary group of tools you like, of any size up to 8x8 tools, 256 total. So if your work flow is, for instance, that of someone who fixes old photos, you can collect color correction, geometric adjustments, noise filters, dynamic range tools, and so forth. You can save any number of these toolboxes and open the one that fits your current workflow at any time, or simply build one on the fly (just drag and drop icons from the toolbar into the toolbox and they're ready to go; if no toolbox is open, dropping a tool on the backdrop window will open one.) You can rearrange the icons within the toolbox, delete them, etc. A typical caddy size for me is 4x8 for 32 tools, given any one workflow. I actually do spend a lot of time fixing old photos, as I maintain my family's genealogical web site, which has a couple hundred megabytes of web stuff, timelines, images, etc. I also (as a hobby) like to mess around with landscape generation and ray tracing, and I have caddies optimized for those workflows as well — heightfield processing, crater generation, erosion, texturing, that sort of thing. So I use a different op caddy for that.
Op caddies are static, unless you change them, so you can develop the same kind of visual and placement-level familiarity with them that menus offer; but because you set them up, they offer the ability to match your focus, no matter how eclectic that might be. And finally, they're one-left-click in terms of UI speed and convenience, which is unbeatable. If you need something you didn't put in there in some odd circumstance, you have the option of one-timing it from the toolbar or the menu system, or you can drag it in and save the new caddy configuration, and you'll have it from now on (unless you take it back out.)
I think this is a very valid point, and it is the underlying rationale as to why we also have a full menu interface that allows you to get at the available tools. Likewise, although we have a faster area selection methodology than, for instance, Photoshop does, we provide a "compatible" operating mode so that those whose habits overwhelm their ability to learn new ways of working can still be effective.
However: If you and I sit down in front of the software, and you, being intimately familiar with the menu structure (very similar to Photoshop's... menu for op classes, submenus for specific ops, non-modal dialogs if needed) were to "race" me to get a particular task done, I'd get done first, every time, using the chapter/verse toolbar because it requires considerably fewer UI actions (mouse moves, clicks, keystrokes) to get to any particular operation and get it running.
Similarly, if you were attempting to use the Photoshop compatible mode of area selection (select, pick an op, let the op run, repeat) and I was using ours (pick an op, select(autorun), select(autorun), select(autorun)...), again, I'd finish way ahead of you, and the more areas, layers and images that need to be worked on, the more ahead I'd get.
This continuously aggregating time savings is a benefit of the new methodologies that I get because I am willing to use them, and which you don't. The questions are: How much is your time worth, and would working with a narrowed interval between actual image processing operations benefit your focus?
I do not for a moment discount either that familiarity has its uses or that time is not always a critical factor; I know for a fact that many of our customers use the menus and/or the PS compatible selection mode, and they're perfectly happy. However, on the other side of the coin, some customers are looking for the most streamlined workflow, and they make the (incontestable) point that time, for them, is money. They're intent enough on this to invest a little time up front to learn new ways of working in order to save larger cumulative amounts of time over many jobs. I work this way myself. I am not particularly comfortable within Photoshop, for instance, because actual production use of it is so much slower; Often, I know I could be doing the same thing with less UI interaction, and that makes me want to go do so. It isn't just the discomfort — time is definitely money at work, and when it isn't money, it could have been time with my family.
I really think you need to read what I wrote in response to your original point, instead of making up your own agenda. As I have clearly said, the colors do have specific function within the interface, just as a color-coded set of wrenches uses color to cue you as to what to grab next, so the colors on these tools cue you as to function. You (and the other two posters upstream), on the other hand, have not offered any reasonable postulate as to why color would actually degrade the workflow. In contrast, I have specifically outlined for you precisely what the colors do for the user within the context of the interface itself.
It seems to me that if you want to make your argument, then you're going to have to offer some good reason — and I'm not talking about a claim that color anywhere but on the image disturbs your "wa"... otherwise, as I told the other poster, every time your golden retriever comes in the room, you'd be tinting your images orange. Certainly I wouldn't be considering inconveniencing the majority of our customers simply because your work habits are influenced by contextually irrelevant, physically distinct, functionally disjoint elements in your cone of vision.
If you have a another point, by all means make it. I'm not going to rule your continuing objections out just because you haven't convinced me yet. I can be convinced, but not by crystal gazing or hand waving. Bring me some facts. Remember, I have made my living (and the livings of quite a few other people) based on how the software works now, and by listening to our customers over more than a decade (who, by the way, suggested the colors — we actually had a pure grey interface, way back when we first shipped the core engine in the very early 1990's.)
Perhaps something else for you to consider is that this software is far more complex than anything else you've used, unless you're using some proprietary solution no one's ever heard of. In terms of the number of operations, controls for those operations, and the multiplying factors of time, area selection techniques and layer interactivity, every usability cue we can give the customer that keeps them out of the documentation can be expected to have a real time benefit. If you want to argue the colors out of the interface, you have to provide a counterweight to that functionality. We could even let you create your own icons, if you could make the case that something like that would actually be useful, as opposed to a waste of our (and your) time. We use scalable images for them anyway, nothing earthshaking would be required to let you cobble up your own set. Added complexity has to justify its own weight, though.
In the same spirit in which your comment was offered:
If you're a "professional retoucher", I'm sure that somehow, you can come to terms with ignoring colored areas of your display that aren't part of the image. Otherwise, you'd be accidentally tinting your image neutral all the time, accidentally drawing little icons in your picture, and window bars, sizing gadgets, and menus, because, why after all, there they are!
The very idea that your "professional" senses would be "disturbed" by elements of the display not actually on your image is ludicrous. Because I am not a "professional retoucher" and I am, according to you, better at it than you are -- because I only consider the image when I adjust the image... not elements outside of the image area. Maybe you should learn to do that. Then you wouldn't be tinting your work orange when your golden retriever comes into the room... There isn't any color in your office, is there? And you wear neutral colors when you color correct, right? And if you've got a window, you only color correct when it's a neutral grey overcast, right? And your secretary (as a professional, I assume you have one), you make her dress in neutral grey and forgo makeup and powder up in grey so you don't tint your images flesh tone.... right? I knew there were reasons I wasn't a professional retoucher... :-)
And, if you're doing color correction, you wouldn't be looking at green anyway; the green set is for filters. The standard operations group is grey and blue, and that's what would be up (remember, the tools are grouped by context.) Not to mention that as a "professional retoucher", you'd be able to differentiate "neon green" from fairly mundane leafy colors. Maybe you should calibrate your monitor.
No; your analogy is inaccurate. The use of the GUI involves several things.
Recognition: This is enhanced by clearly delineating the button's edges, by use of color to cue the operation class and type, by icons that hopefully provide a cue to the actual operation, and by the ability to scale the icons within the interface.
Targeting and confirmation: by clear indication when pressed (which is also enhanced by a more pronounced border changing state on click / activation.)
Intended functionality: The tool has to do what it is supposed to do as well as possible.
These are the operational issues. I do not agree that the color of the icon, or the depth of the colors / contrast, will affect the usability of the tool, barring actual neuroses or fetish (and in which case, I am unconcerned.)
The issues here -- color, contrast -- won't affect the ability of the program, or the user, in a negative way, and in fact, are a help (just as a color-coded set of wrenches are a help.) So again, I don't buy the position.
I'm sorry, I just can't take that remark seriously. I make software to operate on images. I'm not selling bevels, or looks. I'm selling functionality. If you want to do some serious image manipulation, I have something to offer, and I can make a case for that very well. If you want great artwork, I would simply suggest that it is not appropriate to buy a hammer based on how well the handle is engraved. What you want to know is how well it hammers things. Decoration is irrelevant to serious tool users.
My product an image manipulation system, has had contextual, ribbon-based selection of tools since 1990. We use a chapter/verse metaphor (click on one level of the toolbar to select the chapter, such as filters or geometric tramsforms, the next level slides into view which contains individual tools such as sharpness and feature removal, or ripples and rotations.)
This layout, like MS's "new contextual ribbon" puts what you need in front of you, and buries everything else until you need it. Our chapters function exactly like MS's "tabs" and our verses function as accessors for sets of tools -- basically, there are three levels to the GUI. We don't put the third level in the toolbar, because there are far too many controls for some tools (as many as 70 sliders, buttons, drop-downs) and it is (we think) a poor decision to always take large amounts of vertical space in an image-processing application. Dialogs let you move all that tool-consuming real-estate around. They aren't modal, though, so you can keep working.
This really is a better and more evolved way to work, and I commend MS on finally getting the point (although I note with some humor that they certainly didn't invent this methodology.) Of course I'm partial to it, having been building and using such an interface for well over a decade now.
The thing that seems to stick in user's craws isn't the difficulty (or "increase in complexity, as you put it) of such a layout, because there isn't any, really... but simply that it is "different." Change is a force for user discomfort, especially UI change. I'm not saying that UI's can't get more complex, they certainly can, but contextual ribbons are a simplifying factor, count on it.